headers
Martin Duerst | 19 Aug 2004 10:10
Picon
Favicon

Comments on draft-saintandre-xmpp-uri-04.txt


Hello Pierre,

At the recent IETF, you asked me for (I18N) comments on
http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-uri-04.txt.
Here they are, including quite some comments of a more general nature.

I have copied both the xmppwg list (given in the draft) and the uri
list. I'm not subscribed to the xmppwg list, so please cc me.

>Network Working Group                                     P. Saint-Andre
>Internet-Draft                                Jabber Software Foundation
>Expires: February 11, 2005                               August 13, 2004
>
>
>
>      A Uniform Resource Identifier (URI) Scheme for the Extensible
>                  Messaging and Presence Protocol (XMPP)
>                       draft-saintandre-xmpp-uri-04
>
>
>Status of this Memo
>
>
>    By submitting this Internet-Draft, I certify that any applicable
>    patent or other IPR claims of which I am aware have been disclosed,
>    and any of which I become aware will be disclosed, in accordance with
>    RFC 3668.
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Elliotte Rusty Harold | 19 Aug 2004 13:15
Picon

Re: Relative URI or relative URI reference


At 11:50 PM -0400 8/18/04, John Cowan wrote:

>Do you think that stone lions, like the ones outside the New York
>Public Library, are lions?  They certainly don't belong to the
>species _Panthera leo_.

Well, now I suppose we're going to start arguing about Platonic 
forms, but yes; I think the stone lions do participate to some extent 
in the nature of "lion-ness".

Of course, this occurs in the fuzzy world of human language where 
context is critical for sorting these things out so it's a bit of a 
canard. In the domain of technical specifications we're operating in 
here, it's possible to be much more precise, unambiguous, and clear. 
Indeed it is critical to do so. The current draft fails to achieve 
this. It is unclear, ambiguous, and imprecise. It cannot be properly 
understood without being familiar with the discussions that went into 
it, and the intentions of its authors.

I am in the interesting position of straddling the line between the 
precise technical world of spec writing and the more imprecise world 
of human language. I often find myself trying to decide (and explain 
to copy editors) exactly when one should say "URI", "URL", "URL 
reference", "URI reference", "absolute URL", "absolute URI", etc. and 
explain the distinction to readers.

It is simply confusing to readers to say that "absolute URI" is a 
synonym for "URI" and that a "relative URI" is not in fact a "URI". 
It is very difficult to write about this in a precise fashion, and in
(Continue reading)

Permalink | Reply | 1 comment |
headers
Elliotte Rusty Harold | 19 Aug 2004 13:24
Picon

Re: Relative URI or relative URI reference


At 3:02 PM -0700 8/18/04, Roy T.Fielding wrote:
>>  Yes, there is. If it is confusing (as this blatantly is), then the 
>>confusingness should be noted in the spec. Not doing so makes the 
>>spec harder for the average person to understand.
>
>What confusion?  So far, the only thing that is confused is that
>some people believe use of the term relative URI cannot exist
>separately from the word "references".  Nobody seems to be confused
>about what a URI may be, nor are they confused about what a Relative URI
>may be, so the request to change all occurrences of "Relative URI" to
>"Relative URI Reference" and <relative-URI-reference> is both
>editorial in nature and fundamentally wrong.

You aren't listening to the same people I am then. Many people are 
very confused about what a relative URI is, and in most contexts 
outside the W3C (and some inside it) the claim that relative URIs are 
not in fact URIs would meet with puzzled stares. The common usage is 
that there are two kinds of URIs, relative and absolute (well, really 
the common usage is that there are two kinds of URLs, relative and 
absolute; and "URI" is just a funny spelling of "URL" you find in W3C 
specs). Honestly, I would prefer that this be the approach taken by 
2396bis and the whole notion of URI references be left in the dust, 
but that's been shot down in the past so I thought maybe we could at 
least be clearer about the distinction between a URI reference and a 
URI.

>That section is defining syntax.  <relative-URI> is a protocol element
>that is used by this specification and other Internet specifications
>as the means of syntactically distinguishing between a URI and a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjoern Hoehrmann | 19 Aug 2004 17:26
Picon

Re: Relative URI or relative URI reference


* Roy T. Fielding wrote:
>> Yes, there is. If it is confusing (as this blatantly is), then the 
>> confusingness should be noted in the spec. Not doing so makes the spec 
>> harder for the average person to understand.
>
>What confusion?  So far, the only thing that is confused is that
>some people believe use of the term relative URI cannot exist
>separately from the word "references".  Nobody seems to be confused
>about what a URI may be,

There is a lot of confusion about whether a "URI" must start with a
scheme and whether it may have fragment identifier. I've seen people
arguing for yes/yes, no/yes, yes/no, and no/no, I consider no/no the
most reasonable interpretation of RFC 2396 and no/yes the most common
interpretation. RFC2396bis seems to be saying yes/yes.

Do you agree that RFC2396bis says yes/yes?

Is whatever it says different from what RFC2396 said?

If it is different, how exactly and why?
Permalink | Reply | 6 comments |
headers
John Cowan | 19 Aug 2004 18:00
Favicon

Re: Relative URI or relative URI reference


Bjoern Hoehrmann scripsit:

> Is whatever it says different from what RFC2396 said?

RFC 2396 does not define the term "URI" formally.

--

-- 
With techies, I've generally found              John Cowan
If your arguments lose the first round          http://www.reutershealth.com
    Make it rhyme, make it scan                 http://www.ccil.org/~cowan
    Then you generally can                      jcowan <at> reutershealth.com
Make the same stupid point seem profound!           --Jonathan Robie
Permalink | Reply | 0 comments |
headers
Roy T. Fielding | 19 Aug 2004 21:31
Favicon
Gravatar

Re: Relative URI or relative URI reference


> There is a lot of confusion about whether a "URI" must start with a
> scheme and whether it may have fragment identifier. I've seen people
> arguing for yes/yes, no/yes, yes/no, and no/no, I consider no/no the
> most reasonable interpretation of RFC 2396 and no/yes the most common
> interpretation. RFC2396bis seems to be saying yes/yes.
>
> Do you agree that RFC2396bis says yes/yes?

Why don't you read the document that is being discussed, rather than
ask my interpretation of it?  The whole point of this review is to see
if you can understand the technology simply by reading the 
specification.

> Is whatever it says different from what RFC2396 said?

Yes.  As far as I can tell, this whole discussion is based on what
is in RFC 2396 and its associated hangover.  Anyone confused by what
is in rfc2396bis should look again and see how URI is defined.

....Roy
Permalink | Reply | 4 comments |
headers
Roy T. Fielding | 19 Aug 2004 21:54
Favicon
Gravatar

Re: Relative URI or relative URI reference


> Of course, this occurs in the fuzzy world of human language where 
> context is critical for sorting these things out so it's a bit of a 
> canard. In the domain of technical specifications we're operating in 
> here, it's possible to be much more precise, unambiguous, and clear. 
> Indeed it is critical to do so. The current draft fails to achieve 
> this. It is unclear, ambiguous, and imprecise. It cannot be properly 
> understood without being familiar with the discussions that went into 
> it, and the intentions of its authors.

On what basis do you come to that conclusion?  Because you don't like
the name of a section heading and one ABNF rule?  Allow me to quote:

Section 1:

    A URI is an identifier, consisting of a sequence of characters
    matching the syntax rule named <URI> in Section 3, that enables
    uniform identification of resources via a separately defined,
    extensible set of naming schemes (Section 3.1).

Section 1.1.1:

    Each URI begins with a scheme name, as defined in Section 3.1, that
    refers to a specification for assigning identifiers within that
    scheme.

Section 3:

    The generic URI syntax consists of a hierarchical sequence of
    components referred to as the scheme, authority, path, query, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 19 Aug 2004 21:54
Picon

Re: Relative URI or relative URI reference


There are active implementers on the IETF's Atompub WG who are 
confused about this. If that fact is not enough for you to want to 
clarify things, then I doubt I can convince you more.

One of the purposes of this revision was to clear up known 
misunderstandings. Please do so.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply | 5 comments |
headers
Roy T. Fielding | 19 Aug 2004 22:17
Favicon
Gravatar

Re: Relative URI or relative URI reference


> There are active implementers on the IETF's Atompub WG who are 
> confused about this. If that fact is not enough for you to want to 
> clarify things, then I doubt I can convince you more.

The only way that is possible is if there are Atompub WG members
who haven't read rfc2396bis.  Please show me what is confusing
and I will address it, since so far all you have done is express
disfavor of what was in RFC 2396.  The original comment was that
a section heading be changed to reflect the text, and the answer
is that the section heading reflects the ABNF and I am not going
to change the ABNF because that would break continuity with prior
specifications FOR NO GOOD REASON.  It is already clarified.

....Roy
Permalink | Reply | 4 comments |
headers
Larry Masinter | 19 Aug 2004 22:35
Picon
Favicon

RE: Relative URI or relative URI reference


> > There are active implementers on the IETF's Atompub WG who are 
> > confused about this. If that fact is not enough for you to want to 
> > clarify things, then I doubt I can convince you more.

I agree with Roy. At this point, we don't need second-hand
reports that "someone else is confused". What we need are
first-hand reports that "someone who has read RFC2396bis
feels that the wording in IT is still confusing."

So, can we please ask those active implementers in the IETF
Atompub WG to speak for themselves?

If you want to speak for yourself -- do you personally think the
wording in RFC2396bis is confusing? -- then that would be
fine, too. 

Thanks,

Larry
Permalink | Reply | 3 comments |

Gmane