Re: draft-fielding-uri-rfc2396bis-03

On Monday, June 16, 2003, at 01:13  PM, Tim Berners-Lee wrote:
> I have started another full read of this document.  here are my 
> comments.
>
> 1.1.1 This is good.
>
> 1.1.2  I think others have commented on the inconsistency between
>    'for ___ services" and "for ___ addresses".  Either talk vaguely
> about services  (eg email services) in each case, or define the things 
> identified
> (eg mailboxes) or the subclass of identifier (email address) in each 
> case.

I have removed the descriptions.

> 1.1.3  I thought a previous draft had words to the effect that "URL" 
> would not be
> used and was  deprecated as a term. I thought that was great. What 
> happened to it?
> I guess I haven't been following the list.

Someone requested that it be removed.  I have added a sentence that 
makes
it clear that the term URI should be used in the future.

> 1.2.2  para 1
>  "access to the resource"  maybe should be "access to the resource or 
> information
> about the resource" given the current discussions.

I don't think that adds value, since the sentence is already phrased
in the negative: "access to the resource is neither guaranteed nor
implied".  That is true regardless of the nature of the resource.

> 1.2.2 para 2
> I agree with Sandro, please remove "denote".

Okay, though I consider any verb to be an operation and I would hope
that any denoting that takes place is on the resource and not something
else that is transient.

> 1.2.2 para 2
> The English of the last sentence is wrong.  "derefernce" is a verb.
> So either
>  ``To use that access mechanism to perform an action on the URI's 
> resource is to "dereference" the URI''

Okay.

> 1.2.2 para 3
>
> s/along with the metadata describing those octets/along with the 
> metadata describing the resource and its relationship to those octets/
>
> (The metadata is about the resource, and anything about the octets is 
> only interesting in as much as it informs you about the resource.)

No, that sentence is only talking about representation metadata (e.g.,
content-type).  If that were about the resource, then content 
negotiation
would be impossible.  I have added a sentence on resource metadata to
make this clearer.

> 2.2 Reserved characters p2
> "Outside of the URI's origin" is confusing, not well specified.  It 
> isn't a question about where an operation is done, it is is a question 
> of what means what.  Forget notions of what happens inside the URI's 
> origin.  Those aren't operations on URIs.  Talk about equivalence.
>
> text change:
>
> s/Outside of the URI's origin ...resolution/URIs which differ in the 
> replacement of a reserved character with its percent-encoded form are 
> not equivalent: they generally identify different things/

Okay.

> 2.3 Unreserved characters para 2
>
> "fear of creating a conflict" and "counterproductive" are much too 
> vague for a foundational spec.
>
> Replace
>
> "Therefore, unreserved characters should not be escaped unless the URI 
> is being used in a context that does not allow the unescaped character 
> to appear. URI normalization processes may unescape sequences in the 
> ranges of ALPHA (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), 
> underscore (%5F), or tilde (%7E) without fear of creating a conflict, 
> but unescaping the other mark characters is usually > counterproductive."
>
> with:
>
> "URIs which differ only be the replacement of unreserved characters by 
> the percent-encoded strings are equivalent: they identify the same 
> resources.
> For the purposes of canonicalisation, it is recommended that 
> characters in ALPHA (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen 
> (%2D), underscore (%5F), or tilde (%7E) be unescaped, but other 
> characters in the mark set be escaped."

Done, but I have decided to follow John Klensin's comments and move the
unsafe mark characters to the reserved set, thereby clarifying all of
this stuff.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Saturday, 7 February 2004 04:09:23 UTC