Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn-16: q-component and resolution

From: [email-masked] (Henry S. Thompson)
Date: Thu, 05 May 2016 12:26:01 +0100

Section 2.3.1, para 2

 "If a URN resolves to a URL, the q-component from the URN is copied
  verbatim to the query component of the URL."

"is copied"?  By whom?  Under what circumstances?  Is this meant as a
MUST or a SHOULD wrt conformant resolution services?  Or advice to user
agents that if they get a URL in response (with what response code?) to
a resolution request for a (URN with a q-component), they should do such
a copy?

I suggest that either there needs to be rather more explanation here, or
this sentence should just be removed.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 May 2016 15:39:42 -0400

--On Thursday, May 05, 2016 12:26 +0100 "Henry S. Thompson"
<[email-masked]> wrote:

> Section 2.3.1, para 2
> 
>  "If a URN resolves to a URL, the q-component from the URN is
> copied   verbatim to the query component of the URL."
> 
> "is copied"?  By whom?  Under what circumstances?  Is this
> meant as a MUST or a SHOULD wrt conformant resolution
> services?  Or advice to user agents that if they get a URL in
> response (with what response code?) to a resolution request
> for a (URN with a q-component), they should do such a copy?
> 
> I suggest that either there needs to be rather more
> explanation here, or this sentence should just be removed.

Per earlier note, this material has been rewritten in -17.   The
rewrite also makes the prose clearly agree with the ABNF that
the q-component does not include the (two-character) delimiter
that introduces it nor any delimiters that terminate it.

 john

---

From: Julian Reschke <[email-masked]>
Date: Fri, 6 May 2016 08:42:00 +0200

On 2016-05-05 21:39, John C Klensin wrote:
>  ..., or this sentence should just be removed.
>
> ...

There's no -17 yet, as far as I can tell. Is there an editor's copy 
somewhere that we should look at?

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 May 2016 08:57:56 -0400

--On Friday, May 06, 2016 08:42 +0200 Julian Reschke
<[email-masked]> wrote:

>> Per earlier note, this material has been rewritten in -17.
>> The rewrite also makes the prose clearly agree with the ABNF
>> that the q-component does not include the (two-character)
>> delimiter that introduces it nor any delimiters that
>> terminate it. ...
> 
> There's no -17 yet, as far as I can tell. Is there an editor's
> copy somewhere that we should look at?

There is not.  My editor's copies contain assorted personal and
placeholder notes, pointers to things I want Peter to
cross-check, may not actually compile with XML2RFC, etc.
Touching off potentially-heated discussions of text that is far
from settled or consistent just does not seem to me to be a
productive use of time, nor does having people make parallel
comments on multiple versions.  

While a successful appeal to the WG Co-chairs will get any given
next draft posted immediately, the time it would take to get it
together does slow down progress on other proposed changes.

However, since this material appears to be of particular
interest, I took the 15 minutes required to verify the XML and
prepare a text form of the relevant section.  For those who want
to look at it, it is attached, in Wdiff form from -16.  Note
that other sections that are in the process of being changed
have not been included.  Comments welcome (I'm particularly
interested in whether "verbatim" contributes anything).

best,
    john

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 06 May 2016 17:51:22 +0100

> interested in whether "verbatim" contributes anything).

I don't have an opinion about 'verbatim'.

None of the edits address my question, so I'll repeat it:

ht

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 May 2016 14:42:43 -0400

--On Friday, May 06, 2016 17:51 +0100 "Henry S. Thompson"
<[email-masked]> wrote:

>> prepare a text form of the relevant section.  For those who
>> want to look at it, it is attached, in Wdiff form from -16.
>> Note that other sections that are in the process of being
>> changed have not been included.  Comments welcome (I'm
>> particularly interested in whether "verbatim" contributes
>> anything).
> 

Sorry.  Didn't understand the question in the context of other
comments about that text.

> explanation here, or this sentence should just be removed.

As a bit of history, we started the q-component discussion (in
2141bis -10 in March 2015 or earlier) with the sentence out.
Versions of 2141bis through -12 (2015-06-13, esp Section 3.3.1)
didn't say what to do with the q-component but instead indicated
that its semantics might not be the same as those of a 3986
query and essentially left the question of what to do with it as
per-namespace.  -12 even included an example and discussion of
passing q-component values to resolvers rather than resource
objects (see below).

Some WG participants insisted that interpretation and gross
semantics of q-components not be per-namespace and others seemed
to agree, so, for -13 (2015-09-14) the present text was
included.  There was, IIR, WG discussion of the text itself both
before and after -13 was posted and the text continued unchanged
through -15.  The change in -16 was made in response to concerns
about URNs that do not map to URLs, but, while the scope of the
text was changed, the basic "is copied..." text is circa 14
months old.

Now, I think Peter wrote those "is copied" words rather than my
doing so, but remember that RFC 2119 says those MUST/ SHOULD/
etc., words are about interoperability, not about conformance
(part of a long and, IMO, tedious, discussion on the IETF list).
In this case, whether that exact ("verbatim") copying is an
interoperability requirement (given narrow interpretations of
that term) or not depends on the namespace and how the
resolvers, if any, for that namespace work.  Further, in this
context at least, "SHOULD" would require an explanation of when
not doing it is appropriate and either "SHOULD" or "MUST"
probably would require, as you suggest, enough of a
standardized, namespace-independent, URN processing model to be
able to specify "by whom or what".

So, while I understand your argument / position and have some
sympathy for it, I'd like to hear from others in the WG about
whether the change is worthwhile, whether it should be to SHOULD
or MUST, and whether we are willing to spend the time and effort
(and accept the restrictions on possible behavior) to nail the
processing model down and, if we go for SHOULD, whether we are
ready to spend the energy to discuss and settle on some wording
about "when not".

Especially given the history, I don't feel comfortable treating
this as an editorial comment and just changing the text without
either that input or instructions from the co-chairs.
 
   best,
     john

---

From: Sean Leonard <[email-masked]>
Date: Fri, 6 May 2016 13:19:34 -0700

> interested in whether "verbatim" contributes anything).

Please provide an example URN that resolves to this HTTP URL:

https://weatherapp.example?op=map&lat=39.56
&lon=-104.85&desc=Santa?+or+Claus
&datetime=1969-07-21T02:56:15Z

Sean

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 May 2016 21:43:41 -0400

> &datetime=1969-07-21T02:56:15Z

Please locate the text in 2141bis that requires that there be a
URN corresponding to every URL.    I am guessing that the
developers of every sensible namespace from which URNs resolve
to URLs will have at least some control over the way those URLs
are constructed.  As my physician says when I complain that some
unreasonable activity causes pain and ask for a cure, "don't do
that". 

If you are trying to make a point about quoting or escaping,
remember that we tried to construct such text and were told by
the 3986 community that it wasn't necessary and that all the
rules were clear and worked.  If you think there is a problem,
convince them and tell us what to put in the document.
Otherwise, again, if a particular URL construction causes pain,
use a different construction.  In particular with the example
above, there would be no problem without the "?" following
"Santa".  That "?" doesn't really seem necessary to any
realistic example I can construct, so I'd suggest that a better
URL for a real case would be

	https://weatherapp.example?op=map&lat=39.56
		&lon=-104.85&desc=Santa+or+Claus
		&datetime=1969-07-21T02:56:15Z

and that is easily represented in a URN should one decide to do
that.

   john

---

From: Sean Leonard <[email-masked]>
Date: Fri, 6 May 2016 22:43:18 -0700

On 5/6/2016 6:43 PM, John C Klensin wrote:
> URN corresponding to every URL.

It does not exist; your point is irrelevant. The issue is that the 
q-component is copied "verbatim" into the query component (appended? 
prepended? randomly interspersed?) of the URL. In any event, the text 
itself says that the so-called q-component is not part of the "URN" and 
does not affect "URN equivalence".

> I am guessing that the
> are constructed.

This assumes that "developers of namespaces" get to dictate 
unequivocally how URNs get put together, which is contradicted by the 
text (Section 6.4.6), and by common sense. "URN resolvers"--not 
namespace developers--do the conversion from URNs to URLs.

>    As my physician says when I complain that some

Yeah, don't use q-components: that's the unreasonable activity. Your 
physician doesn't write software. Software does what it is programmed to 
do, whether the designer understands it or not.

> rules were clear and worked.
Cite the conversation and cite the section of the draft. I never heard 
such a thing from the "3986 community". I don't even know who they are.

The rules for %-encoding are "clear and worked", but you have to say 
that you are doing them, under what circumstances, and why. In this 
case, if your contention is that ? should be %-encoded, then it has to 
be %-decoded when put into the URL--it can't be "copied verbatim". But 
that means that ? (or ?+ or whatever) *always* have to be %-encoded, 
which means that a q-component that contains ? (or ?+ or whatever) is 
syntactically invalid, which is expressly contradicted by the ABNF.

At present, the character sequence ?+ is potentially under the control 
of an attacking party, and can't be represented in the output safely, 
consistently, or deterministically.

>    If you think there is a problem,

Don't know who I'm talking to. See above for text.

> and that is easily represented in a URN should one decide to do

Wrong. Who gets to decide the parameters? Obviously, a *user* (in the 
very broad sense of the term) is deciding the parameters. Who is 
generating lat=39.56 and lon=-104.85? It's not some namespace designer 
hiding behind a desk at some 30-acre office campus. It's software, and 
it can be manipulated. A *user* can just as easily specify name=foo or 
name=bar or name=Santa?+Claus. And that is the point: you have an 
in-band signaling problem, also known as a "phreaking" problem. 
Everything past the ?+ is going to get (possibly) interpreted 
incorrectly as r-component.

Exploits of a Mom
https://xkcd.com/327/

As written, Section 8 of draft-16 is materially deficient. Section 8 
(Security and Privacy Considerations) needs to say: "?+ cannot safely be 
represented in q-component. URN composing software must filter out such 
sequences, which means that ?+ can never be part of the query of a URL 
resolved from a URN."

Sean

---

From: John C Klensin <[email-masked]>
Date: Sat, 07 May 2016 15:31:18 -0400

Sean,

Reply inline.  I've removed parts that don't seem to be leading
in a constructive direction and, for the same reason, comments
quite narrowly on some text.  Others may, of course, have
comments on them.

It is probably worth reading through the "personal observations"
note I just posted before reading this one.

--On Friday, May 06, 2016 22:43 -0700 Sean Leonard
<[email-masked]> wrote:

>...
> It does not exist; your point is irrelevant. The issue is that
> the q-component is copied "verbatim" into the query component
> (appended? prepended? randomly interspersed?) of the URL. In
> any event, the text itself says that the so-called q-component
> is not part of the "URN" and does not affect "URN equivalence".

I will look at the "not part of the URN" text.  Independent of
questions of equivalence (see other subthread) if q-components
are not somehow part of the URN, then they are out of scope for
2141bis and we should be saying "here is the syntax, content
undefined" as the text more or less did before we had the
discussion about namespace independence   I don't think we can
go there without reopening the namespace independence question
as well as the notion of discussing escaping in the text, but
you are welcome to try to convince the WG Chairs otherwise.

>> to URLs will have at least some control over the way those
>> URLs are constructed.
> 
> unequivocally how URNs get put together, which is contradicted
> by the text (Section 6.4.6), and by common sense. "URN
> resolvers"--not namespace developers--do the conversion from
> URNs to URLs.

However, absent a standard for resolvers specified as part of
the URN (see comments about what what is or is not part of a
URN) as you suggested earlier, the choice of resolvers for a
namespace is a function of the namespace definition.   Certainly
someone defining or registering a namespace could pick a
resolver (or mechanism for finding one) that would not work well
with the requirements of that namespace, but I don't see
protecting people from their own stupidity as a design
requirement.  YMMD.

> Cite the conversation and cite the section of the draft. I
> never heard such a thing from the "3986 community". I don't
> even know who they are.
> 
> The rules for %-encoding are "clear and worked", but you have
> to say that you are doing them, under what circumstances, and
> why.

We tried doing that and were basically told that those rules
were a property of RFC 3986 and we didn't need to try to address
them.

>...
> At present, the character sequence ?+ is potentially under the
> control of an attacking party, and can't be represented in the
> output safely, consistently, or deterministically.

I guess I'm less excited about that than you are because I see
so many other things about URIs that are "under the control of
an attacking party" that this one pales into insignificance.
The most obvious (and perhaps most heavily exercised) involve a
URI of http://www.mybank.com/ being written by an attacker (for
selection by a user) as http://www.mybank.com.badguy.example/ or
as http://www.mуbank.com/.  We've developed all sorts of
mechanisms to help defend against such attacks, and maybe the
urn scheme, will need similar mechanisms, but we don't assume
that the URI spec, or even the HTTP scheme spec, should bear all
of the burden of defending against them, much less that a URI
must be attack-proof.

>...
> As written, Section 8 of draft-16 is materially deficient.
> Section 8 (Security and Privacy Considerations) needs to say:
> "?+ cannot safely be represented in q-component. URN composing
> software must filter out such sequences, which means that ?+
> can never be part of the query of a URL resolved from a URN."

I'll let those who believe that the escaping mechanisms of 3986
are all that is necessary and sufficient to deal with this issue
speak up (again) before trying to change the text (again).

    john

---

From: [email-masked] (Henry S. Thompson)
Date: Sun, 08 May 2016 12:04:37 +0100

John C Klensin writes:

> As a bit of history ...

I agree that some material at a URN-generic level is appropriate here.

> ['is' vs. 'MUST' vs. 'SHOULD']

Sorry to be difficult again, but my main concern was not the language,
but the addressee:

>> "is copied"?  By whom?  Under what circumstances?  [directed at]
>> conformant resolution services?  Or advice to user agents that if
>> they get a URL in response (with what response code?) to a resolution
>> request for a (URN with a q-component), they should do such a copy?

Stipulate we're talking about conformance, the question of "by whom"
seems important, but not addressed.

Would it work to simply treat this as a kind of in-principle example, by
reordering the paragraph?  That is, along the lines of

   The URN q-component has the same syntax as the URI query component,
   but is introduced by "?=", not the "?" alone.  For URNs which may be
   resolved to a URL, the semantics of the q-component are identical to
   those for queries to the resource located via that URL.  So URN
   resolvers returning a URL for a URN with a q-component do this by
   copying the q-component from the URN verbatim to the query component
   of the URL.  If the URN does not resolve to a URL the interpretation
   of the q-component is undefined by this specification.

[I've kept some wording I find awkward to minimise the difference with
the existing text -- other things being equal I'd also prefer

  those for queries to the resource located via that URL
 ==>
  those for the query component of that URL

]

ht

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 May 2016 11:21:24 -0400

--On Sunday, May 08, 2016 12:04 +0100 "Henry S. Thompson"
<[email-masked]> wrote:

>...
> Would it work to simply treat this as a kind of in-principle
> example, by reordering the paragraph?  That is, along the
> lines of
> 
>    The URN q-component has the same syntax as the URI query
> component,    but is introduced by "?=", not the "?" alone.
> For URNs which may be    resolved to a URL, the semantics of
> the q-component are identical to    those for queries to the
> resource located via that URL.  So URN    resolvers returning
> a URL for a URN with a q-component do this by    copying the
> q-component from the URN verbatim to the query component    of
> the URL.  If the URN does not resolve to a URL the
> interpretation    of the q-component is undefined by this
> specification.
> 
> [I've kept some wording I find awkward to minimise the
> difference with the existing text -- other things being equal
> I'd also prefer
> 

Wfm, including the latter.  Would others please comment,
especially if they have objections, before I change the text?

    john

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 13 May 2016 02:21:36 +0000

Hello Henry; all, 

comments below. 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Henry S. Thompson
> Sent: 6. toukokuuta 2016 19:51
> To: John C Klensin <[email-masked]>
> Cc: Julian Reschke <[email-masked]>; [email-masked]
> Subject: Re: [urn] q-component copied verbatim
> > 
> agents that if they get a URL in response (with what response code?) to a
> resolution request for a (URN with a q-component), they should do such a
> copy?

The q-component will usually be copied by a URN resolver when it maps the URN into one or more URLs. 

An example below is of a use case in which a user wants Dublin Core metadata about the resource: 

Original URN is URN:ISBN:0888543433

In the user interface of the client the user has at hand, the user ticks the relevant options: Dublin Core metadata, 1 to 10 records. The user does not need to know the target database(s) that will be able to respond; resolver will take care of that.  

Behind the screens, the client produces a URN with an appropriate q component, which in this case is based on the SRU protocol that is widely supported in library systems. 

URN:ISBN:0888543433?=version=1.1&operation=searchRetrieve&startRecord=1&maximumRecords=10&recordSchema=dc&query=0888543433 

As there is no global resolver discovery service in place yet, this is expressed as HTTP URI, for instance 

http://urn.fi/URN:ISBN:0888543433?=version=1.1&operation=searchRetrieve&startRecord=1&maximumRecords=10&recordSchema=dc&query=0888543433

The resolver creates a URL needed to pass the request to the SRU server in the Bibsys database in Norway: 

http://sru.bibsys.no/search/biblio?version=1.1&operation=searchRetrieve&startRecord=1&maximumRecords=10&recordSchema=dc&query=0888543433

If Norway makes the decision to close the national union catalogue and replace it with some other, possibly international system (similar change of the guards has just been done in New Zealand) the resolver is instructed to resolve the URN into a different URL. Query syntax, because it is standard based, should not change. 

Query syntax will change if and when SRU is updated. Then client applications and resolvers need to modernized. ISBN of course does not change, and since the URN + q-component does not identify the retrieved record / records, these changes have no impact on that level. Bibliographic records, by the way, are never identified with ISBN but other systems such as LCCN, Library of Congress Catalog Number. 

> 
> I suggest that either there needs to be rather more explanation here, or this
> sentence should just be removed.

I hope this helps. Removing the sentence would not be an improvement. 

Juha

>                        URL: http://www.ltg.ed.ac.uk/~ht/  [mail from me _always_
> has a .sig like this -- mail without it is forged spam]
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 13 May 2016 10:14:21 +0100

> comments below. 

Thanks -- I did understand the intent, I just wasn't sure the prose
adequately conveyed it.  See my subsequent message in this thread for a
proposed rewording, and then John's request for comment on _that_.

ht

---

From: Sean Leonard <[email-masked]>
Date: Sun, 15 May 2016 01:37:15 -0700

Thanks for the concrete example, Juha.

> On May 12, 2016, at 7:21 PM, Hakala, Juha E <[email-masked]> wrote:
> 
> Hello Henry; all, 
> 
> comments below. 
> 

In your very useful example, you are saying that the URN resolver is going to see the q-component, and put it in the resulting URL(s).

But in prior discussions, a motivator for the q-component was “privacy”, namely, that resolvers can see the r-component but not the q-component. The implication was that URN client applications would take the results of the resolver and do their own merging on the client side.

This example supports the premise that URN resolvers see the entire query production (q-component and r-component), and are expected to return complete URLs to a URN client, with the q-component folded into the URLs. Consequently, we have a distinction without a difference between q-component and r-component. They should be merged into one (i.e., query === r-component).

(This distinction is where Henry Thompson expresses his concern about “is copied”? By whom? Under what circumstances?)

> Query syntax will change if and when SRU is updated. Then client applications and resolvers need to modernized. ISBN of course does not change, and since the URN + q-component does not identify the…

Great example.

In this formulation, urn:isbn:0888543433?=version=1.1&...
is not annotated with any kind of information that identifies the query format as SRU. This is a problem because, as you say, all other components need to be changed if the syntax changes.

It would be far more durable to have a formulation like:

urn:isbn:0888543433?sru:version=1.1&operation=searchRetrieve...

I.e., the query component of the URN is structured so that it first identifies the format of the rest of the query component, followed by a delimiter (“:”), followed by arbitrary data. Then the URN resolver can take the identifier (“sru”) and do the right thing with it, or forward it to another component that knows what to do with it, or ignore it, or reject it, etc.

The example provided here is fine for HTTP/HTTPS URLs, but it fails on everything else. Try copying the URN q-component “verbatim” into the following URI schemes:
data
ldap
ftp
gopher
magnet
ni
mid
mailto
dns
file
news
vnc

...and none of them work the way you want them to (except, perhaps, Gopher, and that is a stretch because there are all of 70 servers left).

Making the URN resolver map the query production to the resulting URL provides much more flexibility and protocol independence. For example, the URN resolver can break out the components (version, operation, startRecord, etc.) and reassemble them into the scheme-specific string, such as something like <ldap:///cn=book,serialNumber=0888543433??version=1.1,operation=searchRetrieve>.

Regards,

Sean

---

From: John C Klensin <[email-masked]>
Date: Sun, 15 May 2016 07:57:35 -0400

--On Sunday, May 15, 2016 01:37 -0700 Sean Leonard
<[email-masked]> wrote:

>...
> In your very useful example, you are saying that the URN
> resolver is going to see the q-component, and put it in the
> resulting URL(s).
> 
> But in prior discussions, a motivator for the q-component was
> "privacy", namely, that resolvers can see the r-component
> but not the q-component. The implication was that URN client
> applications would take the results of the resolver and do
> their own merging on the client side.

I don't recall that discussion, certainly not that a privacy
claim of that sort was dominant in the q-component discussion.
AFAICT, it is not reflected in 2141bis in any way, especially
because I've tried to carefully guard against (over Juha's
objections btw) turning the architectural description of the
pieces and components associated into URNs for a requirement
about a particular implementation model.  

> This example supports the premise that URN resolvers see the
> entire query production (q-component and r-component), and are
> expected to return complete URLs to a URN client, with the
> q-component folded into the URLs. Consequently, we have a
> distinction without a difference between q-component and
> r-component. They should be merged into one (i.e., query ===
> r-component).

No.  There is still a difference.  The WG has discussed it at
great length.  Just as we should not constrain that
implementation model out of existence by the language of the
spec, we should not require it.  Put differently, Juha gave an
example of a situation and implementation strategy.  He did not
claim it was the only possible one.

>...
> The example provided here is fine for HTTP/HTTPS URLs, but it
> fails on everything else. Try copying the URN q-component
> "verbatim" into the following URI schemes: 
> data
> ldap
> ftp

First, the text says that the q-component relationships,
including the "copied" sentence, applies only to URLs, so
arbitrary URI schedules are not relevant here.  If you are
making a case that scope statement should really say "HTTP or
HTTPPS URLs" and there is sympathy for that in the WG, the scope
sentence is easily changed.   However, it appears to me that,
for URLs including at least most of those you have listed, the
non-specific language in 3986 about what URI (really URL)
processors (or "resources" are supposed to do with queries they
don't understand would seem to cover the situations.

>...
> ...and none of them work the way you want them to (except,
> perhaps, Gopher, and that is a stretch because there are all
> of 70 servers left).

I won't comment here on what I think a criterion of "there are
only 70 servers, therefore the protocol or scheme doesn't count"
would, if generalized, mean to the Internet.

> Making the URN resolver map the query production to the
> resulting URL provides much more flexibility and protocol
> independence. For example, the URN resolver can break out the
> components (version, operation, startRecord, etc.) and
> reassemble them into the scheme-specific string, such as
> something like
> <ldap:///cn=book,serialNumber=0888543433??version=1.1,operatio
> n=searchRetrieve>.

Speaking personally, I've argued all along for allowing (but not
requiring) that sort of implementation model.  I believe that
the WG decided rather firmly against it during the discussion of
whether q-component handling was a function of the namespace
(much less the namespace and specific component string or
intermediate resource).  AFAICT, the WG decided that q-component
handling should be strictly a function of the URN scheme and
Peter reflected that in 2141bis in the only way that reflected
that WG discussion and made sense, i.e., by direct and
uncritical copying.   I am still not convinced that was the
right decision, but, as long as we allow some implemention
flexibility, don't see sufficient justification for reopening
the question.

If you do, please take it up with the co-chairs.

     john