W3C home > Mailing lists > Public > uri@w3.org > February 2004

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

From: by way of Martin Duerst <klensin@jck.com>
Date: Wed, 11 Feb 2004 11:56:48 -0500
Message-Id: <4.2.0.58.J.20040211115639.03b785e8@localhost>
To: uri@w3.org




Thanks for both changes.  I look forward to seeing the complete draft.

And, yes, I will try to explain to the IESG why this represents significant 
forward progress.   I don't have nearly the leverage I did a few years ago, 
of course, but I can try.

Our other interesting problem is going to be to either harmonize this with 
the IRI effort, or to make parts of that one go away. But maybe we can push 
this through and _then_ address that issue, rather than getting the two 
intertwined.

best,
     john


--On Tuesday, 10 February, 2004 15:49 -0800 "Roy T. Fielding" 
<fielding@gbiv.com> wrote:

>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 Wednesday, 11 February 2004 14:40:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:07 UTC