Subject: Re: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris)

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Wed, 03 Sep 2014 11:25:23 -0400

[Re-sending from the address that is actually subscribed to the list...]

Hi,

Thank you for updating the document, and in such short order after the 
WG meeting!

I read through it, and I feel I am being a little dense, or maybe caught 
between a couple of known edit disconnects.

Reading through it, it seems to me that there are 2 problems to solve:

+ identify, agree and articulate how the URN syntax relates to URI 
syntax, as captured in RFC3986.  This is Section 6 in the document.

+ ensure that there are persistent identifiers, presumably URIs, that
"meet the needs of the Library, Museum, Publisher, and Informational 
Sciences communities and other users".   Some of the requirements for 
this are captured in the Appendices.

The first ought to happen, no matter what, and is in fact the focus of 
this WG's charter.  It could actually happen without addressing the 
second problem, at least from a strictly logical perspective.

I realize that would not be very satisfying -- as the latter was what 
provided the motivation for the working group in the first place, and 
I'm not actually suggesting we do that.

In fact, I thought where we landed in Toronto was that we should first 
focus on figuring out how to address those issues -- ensure URI 
persistent identifiers that meet the requirements and _then_ see whether 
such persistent URIs were, or could be, URNs as defined by the IETF 
(i.e., solving the first problem by applying the results of the discussion).

In terms of the document, here are a couple of the things that make me 
wonder about disconnects:

1/ The abstract addresses the second problem, but couches it in terms of 
the first:

    "Experience has shown that identifiers associated with persistent
    names have properties and requirements that may be somewhat different
    from identifiers associated with the locations of objects.  This is
    especially true when such names are expected to be stable for a very
    long time or when they identify large and complex entities.  In order
    to allow Uniform Resource Names (URNs) to evolve to meet the needs of
    the Library, Museum, Publisher, and Informational Sciences
    communities and other users, this specification separates URNs from
    the semantic constraints that many people believe are part of the
    specification for Uniform Resource Identifiers (URIs) specified in
    RFC 3986, updating that document accordingly.  The syntax of URNs is
    still constrained to that of RFC 3986, so generic URI parsers are
    unaffected by this change.

For a different document (one addressing the persistent identifier 
issue), I might write the abstract very slightly differently:

    Experience has shown that identifiers associated with persistent
    names have properties and requirements that may be somewhat different
    from identifiers associated with the locations of objects.  This is
    especially true when such names are expected to be stable for a very
    long time or when they identify large and complex entities.  In order
    to allow Uniform Resource Identifiers (URIs) to meet the needs of
    the Library, Museum, Publisher, and Informational Sciences
    communities and other users, this specification outlines the
    specification of a persistent identifier scheme which is separate
    from the semantic constraints that many people believe are part of
    the specification for Uniform Resource Identifiers (URIs) specified
    in RFC 3986.  The syntax of these identifiers is still constrained
    to that of RFC 3986, so generic URI parsers are unaffected by this
    change.

2/ For historic reasons, I have a lot of heartburn with this para:

    IETF in RFC 1738 [RFC1738] -- as an embodiment of the locator concept
    and Uniform Resource Names (URNs), specifically those using the "urn"
    scheme [RFC2141], as an embodiment of the names that do not directly
    provide for resource location.  This specification is concerned only
    about URNs of the variety described in RFC 2141 [RFC2141] (i.e.,
    those that use the "urn" scheme).  URLs, other types of names, and
    any URI types that may not fall into one of the above categories are
    out of its scope and unaffected by it.

RFC2141 defines the syntax for URNs, period.  Not "the URN: URI scheme". 
  For URNs.    I don't take exception to people hating that approach to 
URNs :-)  but insofar as the IETF defines standards, it defined the 
standard for URNs once.

There can be (and already are) any number of other approaches to 
persistent identifiers that are more or less URN-like, but they are 
persistent identifiers, Persistent Resource Names, Uniform Persistent 
Identifiers, whatever.

If the IETF starts talking about multiple possible specifications for 
URNs, we're in trouble, IMO.

Leslie.

On 8/25/14 8:08 PM, John C Klensin wrote:
> Hi.
>
> I've posted the replacement for
> draft-ietf-urnbis-urns-are-not-uris-01 as
> draft-ietf-urnbis-semantics-clarif-00.  It is now awaiting
> Andy's approval which I thought was given shortly after Toronto.
>
> Some of you know that my intention was to immediately follow it
> with a trimmed-down -01 because -00 contains a lot of material
> we probably won't want long-term.  As a preview, exclusive of
> references (some of them cited from the appendices) and
> appendices, -00 is only 8 pages long; with them, twice that.
> I've deferred trying to get -01 out both because -00 took much
> longer than expected and because I continued to review both the
> post-Toronto mailing list comments and a number of private
> communications and concluded that the current draft may not be
> stable enough to start pulling text out of.  I'd also like to
> have a better idea of what Peter expected to do with 2141bis (or
> what the WG wants him to do).
>
> I'm aware that some text is redundant, especially the repeated
> comments about zero effect on generic URI parsing systems.  That
> is partially intentional (to be sure those statements didn't get
> lost when we start removing sections) and partially just
> temporarily running out of energy.
>
> Note too that this draft contains, in Section 6, my cut at the
> list Andy requested of alternatives with which the WG will need
> to deal.
>
> In the spirit of the discussions in Toronto, this document  is
> intended more as the basis for focusing discussions than as a
> final piece to be published.  To paraphrase what Andy said
> there, we need to make decisions about what we want to do and
> only then figure out how much of this, if any, is worth having
> in an officially-permanent document.
>
> While some of the discussion in this -00 draft gets fairly far
> into "how to do this", I personally concur with something Andy,
> Henry, and several others have said in different ways: in the
> short run, we are much more likely to end up with the results we
> want if we can talk about functionality and not where to put it
> or what syntax to use.  While the I-D uses "query" and
> "fragment" terminology, it may even be useful to thinks of parts
> of the URI syntax as "path-stuff", "?-stuff", and "#-stuff",
> remembering that the connotations of words like "query" and
> "fragment" are themselves semantics.  I expect that we will
> return to URI terminology before the version of 2141bis that
> reflects these issues is posted but, for thinking right now it
> again may be useful to break loose from historical concepts.
>
> Some of the above has almost certainly influenced what I've
> written and how I've written it.  That doesn't mean the text is
> right, but I hope we can be clear about what we are talking
> about before we get into trouble.
>
> Happy reading,
>      john
>
>
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Sep 2014 15:16:18 -0400

--On Wednesday, September 03, 2014 11:25 -0400 "Leslie Daigle
(TCE)" <[email-masked]> wrote:

> Thank you for updating the document, and in such short order
> after the WG meeting!
> 
> I read through it, and I feel I am being a little dense, or
> maybe caught between a couple of known edit disconnects.

Or a strategic question or three.  More explanation below but
remember that this particular -00 version of this draft was
intended to be a placeholder for two classes of things that are
probably not part of it long term:

	(i) Things that really belong in 2141bis or perhaps
	3406bis or some other document.
	
	(ii) Things, like Section 6 that were included (at
	Andy's request) purely in the hope of framing the next
	round of discussions in the WG and moving them forward.

In some ways, it would have been better to simply wait for
2141bis (at least), but there was a little bit of a
chicken-and-egg problem relative to an expired version of that
document and Peter's trying to catch up.

Remember too what Andy said in Toronto.  To paraphrase, this
document is a tool to help the WG advance its work.  We don't
need to make a decision now as to whether it will ever be
published and, if it is, with what content.

> + identify, agree and articulate how the URN syntax relates to
> URI syntax, as captured in RFC3986.  This is Section 6 in the
> document.

Actually, the core of that is Section 4 of this document.   The
rest is either explanation or, in the case of Section 6, an
outline of decisions to be made by the WG and presumably
recorded somewhere.  That "somewhere" could be a future version
of this document, part of 2141bis, or something else.

> "meet the needs of the Library, Museum, Publisher, and
> Informational Sciences communities and other users".   Some of
> the requirements for this are captured in the Appendices.

Yes.  Partially for legacy reasons to avoid loss of that text
should we need it somewhere else.  It fairly clearly belonged in
the "URNs are not URIs" draft but, since the WG wants to keep
URNs as part of the URI family although not necessary following
what some people have construed as the generic URI semantics and
related restrictions, it is somewhat orphaned now.  At the same
time, people regularly ask "what are those requirements" and/or
"what is that perspective", it seems helpful to keep it around.

> The first ought to happen, no matter what, and is in fact the
> focus of this WG's charter.  It could actually happen without
> addressing the second problem, at least from a strictly
> logical perspective.

Yes.  Were the WG to get through some of the issues in Section 6
and then decide that its process and/or convenience would be
better served by breaking the material more closely related to
the second topic into yet another document, I'd be happy to do
that.  But, again, I think Peter might reasonably want to
incorporate some of it into 2141bis -- if he does, I'll send him
the text and drop it out of this document.  And, fwiw, I really
don't want to spend much time reorganizing material from one
document to another without clear direction from the WG.  Put
differently, let's try to figure out what we want to do, then
what we want to say, and then how to say it and where... more or
less in that order.

> I realize that would not be very satisfying -- as the latter
> was what provided the motivation for the working group in the
> first place, and I'm not actually suggesting we do that.
> 
> In fact, I thought where we landed in Toronto was that we
> should first focus on figuring out how to address those issues
> -- ensure URI persistent identifiers that meet the
> requirements and _then_ see whether such persistent URIs were,
> or could be, URNs as defined by the IETF (i.e., solving the
> first problem by applying the results of the discussion).

Andy needs to comment on this but my impression coming out of
Toronto (and the assumption on which this draft and its
predecessor are built) is that:

	(a) There is a strong conclusion that we want to
	accommodate the needs of that community and similar
	ones, i.e., "those issues" within the URN framework at
	defined (or to be defined) by the IETF if only because,
	if we can't, it is near-certain that we will see a
	forked standard.  Had the WG taken the position when it
	started that URNs were inappropriate for those needs and
	a different URI type (and scheme name) (or something
	different entirely) should be used, that might have been
	possible.  But, four years later, it is too late.
	
	(b) Accommodating those needs requires extending 2141 in
	the ways that it anticipated, i.e., adding the ability
	to express what we have recently called "service
	requests" as part (whatever that means) of the URN.
	
	(c) Because of the nature of persistent identifiers, at
	least some of which may lead to objects stored in
	multiple and non-persistent locations and others of
	which may never be resolved to content at all, some of
	what 3986 has to say is inconsistent with that
	evolution.   Those differences may be as trivial as
	statements in 3986 about the ultimate way to compare two
	URIs for equality involving retrieving content and
	comparing it to seemingly-string definitions and
	semantics in 3986 about, e.g., the applicability of
	fragments and their binding to media types.   The former
	example would merely require that URN specification say
	"don't try to make that kind of comparison where it
	makes no sense" with no change to 3986 required; the
	latter is believed by several people to require
	unbinding the syntax of 3968 from its semantics and
	binding post-2141 URNs only to the former.

Now, if we haven't gotten even that far, I need
advice/instructions because, if nothing else, this document is
premature even relative to your narrower goal above.  In
addition, there has been a fourth assumption:
	
	(d) Spending a lot of cycles getting the text of this
	I-D exactly right is not worth the trouble until we
	decide whether we intend to retain and publish it and
	will never make sense if we decide to not do that.   If
	I'm called upon to produce another I-D iteration before
	we make that decision, I'll make it much more explicit.

> In terms of the document, here are a couple of the things that
> make me wonder about disconnects:
> 
> 1/ The abstract addresses the second problem, but couches it
> in terms of the first:
>...

I am happy to spend time fussing with the abstract once we
determine what this document is about and, ideally, whether we
ultimately intend to keep or discard it.  In the interim, I have
recorded your proposed rewrite in my working copy so it doesn't
get lost.

> RFC2141 defines the syntax for URNs, period.  Not "the URN:
> URI scheme".   For URNs.    I don't take exception to people
> hating that approach to URNs :-)  but insofar as the IETF
> defines standards, it defined the standard for URNs once.

I want to agree with you.  But Section 1.1.3 appears to say that
the term "URN" refers to both the URN scheme (i.e., what 2141
defines) and lots of other things ("any other URI with the
properties of a name").   One of the non-accidental
characteristics of the "URNs are not URIs" approach is that it
would have nullified that text.  If we are going to pursue the
"separate only the semantics" approach (semantics that many
people believe either should not have been in 3986 in the first
place and others believe are illustrative rather than
normative), then something has to be done about 1.1.3.   The
paragraph to which you object was my attempt to remove the
current WG and its effort as much as possible from the more
general debate about 3986 without modifying 3986 itself.

That takes us back to a meta-question.  In some best of all
possible worlds, we would simply suspend work on URNs, get a
replacement/update for 3986 posted that would _at least_ clarify
what was normative, what was general guidance and advice, and
what was merely examples about how a scheme might do things, be
much more precise about the syntax (including strictly following
ABNF rather than incorporating RHS matching rules), get rid of
problematic statements like the one in 1.1.3, and so on, get
that document approved, and then come back to URNs.
Unfortunately, most people who have estimated the length of time
it would take to get consensus on such a revision have had
estimates measured in years (if not decades or eons).  

If we don't create a revised URN spec in that interval, someone
else will.
 
> There can be (and already are) any number of other approaches
> to persistent identifiers that are more or less URN-like, but
> they are persistent identifiers, Persistent Resource Names,
> Uniform Persistent Identifiers, whatever.

I would like that to be true.  Unfortunately, 3986, which is
still an Internet Standard, says otherwise.    There are, as far
as I can tell, four ways out of that problem:

	(i) Replace 3986 or create a document that "updates"
	such statements out of it.
	
	(ii) Remove URNs from the scope of generic URIs (and
	hence 3986) so that statements in 3986 about URNs are
	nullified.
	
	(iii) Try to work around problematic portions of 3986 so
	that we can get this WG's work done without engaging on
	those larger issues.

	(iv) Write an extremely short document deprecating every
	bit of 3986 except the syntax itself.   If that document
	were to incorporate the syntax (not hugely complex
	although see above), it could also make 3986 Historic.

The difficulties with (i) are discussed above.  (iv) would be
significantly less work but might show a "no consensus" status a
lot more quickly.   The WG asked for a draft corresponding to
(ii) during and after the London discussions and then decided it
didn't like the approach. I think the Toronto conclusion was to
pursue (iii).  This draft attempts the latter.   If it doesn't
work either, I hope someone has a proposal other than "give up,
close the WG, and let whomever is interested take over URN
definition" because it seems to me that is where we are headed.
  
> If the IETF starts talking about multiple possible
> specifications for URNs, we're in trouble, IMO.

We are, IMO, indeed in trouble.   The conditional does not
apply: we have been in that trouble at least since RFC 3986 was
approved very nearly a decade ago.  I'm trying to recognize that
trouble and help us dig out.  If you don't like the strategy,
please propose an alternative that still deals with 3986 as a
reality.  If the strategy is ok but the text is not, please
propose text -- I'm attached to absolutely nothing in this draft
other than whatever helps the WG move forward.
   
     john

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Thu, 04 Sep 2014 18:40:52 -0400

Okay, I think part of my disconnect is that, while I understand this 
document is a "support the WG" document that may not persist (and 
therefore should not steal too many cycles), some of the things I 
pointed at are ones I think could be misleading for someone joining the 
discussion late (say, after Toronto).   I'm _not_ concluding "and 
therefore I argue they should be fixed", I'm just framing my perspective :-)

Diving in to follow up some pieces:

On 9/3/14 3:16 PM, John C Klensin wrote:
[massive snip]
> 	requests" as part (whatever that means) of the URN.

I think we are in agreement.  The thought that did not get from my head 
to the keyboard in my earlier mail was:  we may focus first on finding 
solutions for that community (in ways that are not obviously inimical to 
existing URNs) and _then_ come back to 2141 updates if we have succeeded 
in compatibility (and the level at which we have to address 3986 might 
be more apparent then, too).

> 	binding post-2141 URNs only to the former.

*sigh*  I hear you.

> 	we make that decision, I'll make it much more explicit.

Agreed -- see opening comment.

> properties of a name").

Okay.  IMNSHO, that means RFC3986 is broken and that should have been 
caught at the time, but I appreciate the political sensitivities (then 
and now) and am willing to flag it as something to come back and fix if 
possible.

 > One of the non-accidental

I think this is "create a category of identifiers that are syntactically 
compatible with URIs but not semantically tied", because I argue that 
URNs are then not the only impacted persistent identifiers.

> reality.

I think we are agreed on strategy but differ in tactics.  If the text is 
confusing no one (else), then perhaps we don't have to worry about that 
:-)

At any rate, I would like discussion to:

1/ focus on the new bits that you added following Toronto, to launch the 
discussion of "what would we do with the ? and # and / syntax elements 
to address the overall requirements"

- and -

2/ not get stuck 6 months from now with claims from people (confused) 
that the other text is normative.

Leslie.

 >  If the strategy is ok but the text is not, please

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Sep 2014 21:42:12 -0400

--On Thursday, September 04, 2014 18:40 -0400 "Leslie Daigle
(TCE)" <[email-masked]> wrote:

> 
> Okay, I think part of my disconnect is that, while I
> understand this document is a "support the WG" document that
> may not persist (and therefore should not steal too many
> cycles), some of the things I pointed at are ones I think
> could be misleading for someone joining the discussion late
> (say, after Toronto).   I'm _not_ concluding "and therefore I
> argue they should be fixed", I'm just framing my perspective
> :-)

That is fair.  Suggested text, or specific pointers to what I
should fix, welcome... preferably after Peter has posted
2141bis-08.  More generally, I'm unlikely to want to do much
more (if anything) with this draft until after 2141bis-08 shows
up unless Peter is asking the questions or challenging or
confused by text.

> I think we are in agreement.  The thought that did not get
> from my head to the keyboard in my earlier mail was:  we may
> focus first on finding solutions for that community (in ways
> that are not obviously inimical to existing URNs) and _then_
> come back to 2141 updates if we have succeeded in
> compatibility (and the level at which we have to address 3986
> might be more apparent then, too).

I think we are in agreement too.   Let me, however, suggest a
different way of thinking about some of the issues that probably
doesn't come through in this semantics draft because I (mostly)
considered it out of scope.   IMO, there are two ways to proceed
from a design standpoint.  One is more or less what I understand
you to suggest -- we try to focus on accommodating the needs of
the community (or communities) that have been most articulate
about their requirements, then retrofit those extensions into
2141.   The other is that we try to push the "Service Request"
model a bit and see if we can do something that is _really_
general, testing its generality against both those expressed
requirements and whatever cases we can reasonably hypothesize.

In both cases, we more or less need to realize that we are
already very far down the path to multiple types and uses of
URNs and that they come with different requirements.  If there
were a collection of requirement spaces or subspaces, the "pure
identifier" or "indicator" uses might lie at one extreme and the
"URN instantiation of sundry well-established external standards
and management systems" (e.g., ISBNs and ISSNs) might lie
somewhat else (not necessarily at an extreme.  If we take the
first approach and get it wrong, we will almost certainly
discover that we've run out of extension room and that anything
else that comes along and belongs in the requirement space
needs, e.g., a URS (Uniform Resource Snafu), more or less along
the lines of the "new scheme" model proposed in Toronto.  Maybe
that would be an ok outcome.  But, if we want the URN umbrella
to cover as much of the requirements space as possible,
generality is probably our friend.

> Agreed -- see opening comment.

And, with a strong nod to your opening comment, I see a
considerable potential distance between "not add to the
confusion" and "getting the text exactly right".  If it is
confusing, we should, IMO, fix it.

>>> In terms of the document, here are a couple of the things
>>> that make me wonder about disconnects:
>...
>> I want to agree with you.  But Section 1.1.3 appears to say
>> that the term "URN" refers to both the URN scheme (i.e., what
>> 2141 defines) and lots of other things ("any other URI with
>> the properties of a name").
> 
> Okay.  IMNSHO, that means RFC3986 is broken and that should
> have been caught at the time, but I appreciate the political
> sensitivities (then and now) and am willing to flag it as
> something to come back and fix if possible.

While you conclude from this that 3986 is broken and I,
personally, agree with you, it was clear in Toronto (and on the
mailing list before and after) that the WG does not have
consensus on that point.

>> still an Internet Standard, says otherwise.    There are, as
>> far as I can tell, four ways out of that problem:
>> 
> I think this is "create a category of identifiers that are
> syntactically compatible with URIs but not semantically tied",
> because I argue that URNs are then not the only impacted
> persistent identifiers.

Yes, that is another possibility.  Unfortunately, 3986 also
contains language that moves it away from general URIs and,
instead, indicates that the only thinks out there are locators,
non-locator names, and mixtures of the two.  One can interpret
that as implying URLs, URNs, and something else, or one can
interpret it as broad categories in which URLs are part of the
first group and URNs are part of the second.  The most common
interpretation, as I understand it, has been the first.

>> apply: we have been in that trouble at least since RFC 3986
>> was approved very nearly a decade ago.  I'm trying to
>> recognize that trouble and help us dig out.  If you don't
>> like the strategy, please propose an alternative that still
>> deals with 3986 as a reality.
> 
> I think we are agreed on strategy but differ in tactics.  If
> the text is confusing no one (else), then perhaps we don't
> have to worry about that :-)

See above about confusion.

> 1/ focus on the new bits that you added following Toronto, to
> launch the discussion of "what would we do with the ? and #
> and / syntax elements to address the overall requirements"
> 
> - and -
> 
> 2/ not get stuck 6 months from now with claims from people
> (confused) that the other text is normative.

Wfm.   By the way, I intend to start pulling text out as soon as
the WG and Andy will let me.  That should not be before
2141bis-08 appears, but my goal was to get all of the text into
one document that people could look at and think about, then
remove everything that was not clearly relevant.  So, if it is
possible to make good progress from this point, I'd expect that
most of the text that might be confusing would have disappeared
before your six months are up.

     john

---

From: Andrew Newton <[email-masked]>
Date: Mon, 8 Sep 2014 10:42:32 -0400

> generality is probably our friend.

I think generality is a good thing, but I wonder if we have enough
people/bandwidth to do it.
(fyi, that's just me thinking aloud, not guidance)

> mailing list before and after) that the WG does not have

Even if we did have consensus on that (and we may), it is also
irrelevant. The AA serenity prayer comes to mind here.

> before your six months are up.

Rip it out! We always have the historical versions.

-andy

---

From: John C Klensin <[email-masked]>
Date: Mon, 08 Sep 2014 12:50:25 -0400

--On Monday, September 08, 2014 10:42 -0400 Andrew Newton
<[email-masked]> wrote:

>> were a collection of requirement spaces or subspaces, the
>> "pure identifier" or "indicator" uses might lie at one
>> extreme and the "URN instantiation of sundry well-established
>> external standards and management systems" (e.g., ISBNs and
>> ISSNs) might lie somewhat else (not necessarily at an
>> extreme.  If we take the first approach and get it wrong, we
>> will almost certainly discover that we've run out of
>> extension room and that anything else that comes along and
>> belongs in the requirement space needs, e.g., a URS (Uniform
>> Resource Snafu), more or less along the lines of the "new
>> scheme" model proposed in Toronto.  Maybe that would be an ok
>> outcome.  But, if we want the URN umbrella to cover as much
>> of the requirements space as possible, generality is probably
>> our friend.
> 
> I think generality is a good thing, but I wonder if we have
> enough people/bandwidth to do it.

Given the relatively small number of people who seem willing and
able to engage on the broad issues on an ongoing basis, as
distinct from focusing narrowly on some particular set of
applications and/or preserving the view of what URNs are able
that is reflected in RFC 3986, I think there is reason at this
point to believe that we do not.

On the other hand, if we don't go for the generality, I think
there is a real and serious question about whether the WG should
continue to work on developing a solution for which
counterexample to the hypothesis of adequacy are likely.   Put
differently, the IETF can cause, or contribute to, a fork by
doing a job that doesn't meet some needs or we can do it by
giving up.  The latter is obviously unattractive, but might be
less painful for those of us who seem to be doing a
disproportionate fraction of the work.

>>>> that the term "URN" refers to both the URN scheme (i.e.,
>>>> what 2141 defines) and lots of other things ("any other URI
>>>> with the properties of a name").
>>> 
>> personally, agree with you, it was clear in Toronto (and on
>> the mailing list before and after) that the WG does not have
>> consensus on that point.
> 

It isn't irrelevant if --as I think some people have suggested
(or nearly so)-- the WG decides to suspend work until 3986bis
can be completely and agreed to.  As I have said in response to
those suggestions before, I believe that, in practice, that
would be just a different way to give up, but that is just my
opinion.

>> Wfm.   By the way, I intend to start pulling text out as soon
>> as the WG and Andy will let me.  That should not be before
>> 2141bis-08 appears, but my goal was to get all of the text
>> into one document that people could look at and think about,
>> then remove everything that was not clearly relevant.  So, if
>> it is possible to make good progress from this point, I'd
>> expect that most of the text that might be confusing would
>> have disappeared before your six months are up.
> 

I'm on travel or otherwise out of pocket for almost 3/4 of this
month and October is unlikely to= be better. As a result you are
going to get at most one more draft in the next two or three
weeks and probably no more than one more in October.  So I will
tentatively start, but really would prefer to see 2141bis before
I post.  I'll go ahead and generate a stripped-down version
without it if Peter tells us that we shouldn't expect that draft
any time soon but, so far, I gather we are on schedule for the
next day or two.

    john