Re: URI Generic Syntax doc (draft-fielding-uri-rfc2396bis-03)

On Saturday, February 7, 2004, at 02:31  PM, John C Klensin wrote:
> Thanks.  I think this is very good progress, and I look forward to 
> reading the new draft.   A few comments...
>
> (1) If specifying what must be specified in specific URI definitions 
> is "the role of RFC 2718 and BCP 35 (RFC 2717)...", which may be quite 
> reasonable, I think those docs should be crossreferenced in 2396bis.  
> A sentence like "There are specific requirements that these per-scheme 
> characteristics be defined for the schemes, see [RFC2718bis, 
> RFC2717bis]" may be a forward pointer but is not normative, since it 
> provides references for additional reading about a related topic, 
> rather than information needed to understand/implement 2396bis.

I have added a neutral pointer in the intro and definition of scheme.

> (2) The IPv6 syntax issue.  RFC 2821 does not provide a variant/ 
> different IPv6 syntax (although changes by the IPv6 folks may require 
> some slight retuning in 2821bis).  What it does is to specify that, if 
> the addressing scheme isn't IPv4, then the scheme must be tagged with 
> what it is, rather than deduced by heuristics on the address syntax 
> chosen.  Think of it as a wrapper around whatever the IPv6 folks 
> specify, rather than a different syntax.  On that basis, I think you 
> can do exactly the same thing and that a "no heuristics" or at least 
> "no heuristics if there is any possible alternative" principle will 
> generally serve URIs and the web well. If, due to other pressures and 
> considerations, you need to permit IPv6 addresses without any 
> qualification, it seems to me that it would be useful to identify an 
> identified/tagged form, make it normative, and then define the IPv6 
> address form without the tag as a permitted abbreviated syntax 
> variation.  That at least puts the right future stake in the ground.  
> That stake is necessary if we see URIs outliving the Internet as we 
> know it, and some of the other W3C-derived architecture documents and 
> public presentations clearly anticipate that.

Okay, I have added a version flag in the form of [v9.somefutureliteral]
where 9 can be any hex digit.  I also required that it not be used for
IPv4 and IPv6, since the existing syntax is already deployed and we 
don't
want two more ways of doing the same thing.

I am counting on you to help defend this to the IESG, if necessary. ;-)

....Roy

Received on Tuesday, 10 February 2004 18:58:57 UTC