Re: draft-fielding-uri-rfc2396bis-03

Roy,


>
>> Please note that all issues have been fixed or closed.  If you'd
>> like to raise a new issue or reopen an old one, please do so
>> within the next two weeks.

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.

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.

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.

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

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''
or
  ``Use of that access mechanism to perform an action on the URI's 
resource is a "dereferencing" of the URI''

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.)

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/

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."


___________________________________ That's all for now _________________

timbl

Received on Monday, 16 June 2003 16:13:22 UTC