- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 10 Feb 2004 15:49:50 -0800
- To: John C Klensin <klensin@jck.com>
- Cc: uri@w3.org
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