RE: Using fragment identifiers with URNs

At 10:04 PM 2001-09-26 , Stephen Cranefield wrote:
>Roy Fielding wrote:
>> The notion of retrieval is not in any way specific to the URI 
>> scheme -- there is a paragraph in RFC 2396 that says exactly
>> that, regardless of whether it is a locator or a name. 
>
>Could you identify this paragraph?  I can only find paragraphs
>that contradict this, e.g.:
>
>  This paper describes a "superset" of operations that can be applied  
>  to URI.  ...  Some of the functionality described is not applicable
>  to all URI schemes ...
>
>  Not all resources are network "retrievable"; e.g., human beings,
>  corporations, and bound books in a library can also be considered
>  resources. ...
>
>  A fragment identifier is only meaningful when a URI reference [sic]
>  is intended for retrieval and the result of that retrieval is a document
>  for which the identified fragment is consistently defined.
>
>  [I presume this last paragraph should really say "... when a URI
>  is intended for retrieval ..." as a *URI reference* is always intended
>  for retrieval according to the definition in Section 4.1.]

AG::

No, you are not following why it says that.  The #fragment that appears in a
URI-reference is not part of the URI.  So it can only say "A fragment
identifier is only meaningful when a URI-reference..." because a fragment
identifier is only _present_ in the context of a URI-reference.  In the
context
of a URI, it simply isn't there.  You set aside the fragment identifier,
and if
you recover the resource associated with the URI that was left on removal of
#fragment, you can then, in the light of the type you ascertain from the
recovered resource, use the #fragment in that context.

I would submit that you are correct that recovery is not part of all schemes. 
The mailto: scheme has a PUT method and no GET method.  So it is unlikely that
mailto:me@example.com#fragment would ever yield a use for the fragment
identifier.  But it was not contemplated at the time of forging the common
syntax document, for which Roy went through a lot of pain to achieve a
mutually
agreed work, that URNs would be excluded from the concept of recovering some
instantiation of the resource more than the resource indication itself.  Just
that http: was in practice tightly bound to HTTP and ftp: tightly bound to FTP
the protocol, and the URN developers were keen to have a namespace without the
appearance of being tied to a communication mechanism.  Dereferencing a
resource indication does not imply communication or any other mechanism, it
just state an end result.  

Of course we have the WYSIWYG URL scheme, too, called data:.

>
>These paragraphs clearly imply that not all URI schemes have a notion
>of retrieval defined.
>

No, they do not imply anything of the sort.  They allow it.  But that is not
what was meant.

Functionality such as relative URI references is not applicable to cid: and
data: URLs.

Authorization information is not appliable to all schemes.

There are lots of things.  But despite the hyperbole about the toadstool as a
resource, recovering the resource was considered to apply for the purposes of
interaction with #fragment usage across URNs as well as URLs.


>> The retrieval mechanism is defined by the application, in all cases,
>> regardless of URI scheme.
>
>This is not true.  The retrieval mechanism for http URLs is defined by
>the HTTP protocol, not any particular application.  

AG:: Negatory.  Applications routinely recover these objects from a search
list
of mechanisms starting with local cache and extending out through HTTP as
required.  And other applications don't use such a cache.  The application
knows that it can try HTTP and will often succeed, but that is custom and not
definition.

>A client does not
>need to know how a Web server is set up in order to access an http URL.
>It just uses a standard protocol that is associated with that URI scheme.
>
>> The syntax applies to names already -- I doubt that it can 
>> get any broader.
>
>It certainly seems to be considered that way in common usage.  However,
>RFC 2396 implies the opposite.  

Not at all.  There is nothing in there that says the discussion of #fragment
does not apply to URNs.

And there is nothing in there, despite your inference from the heuristic
remarks about "can't retrieve a person over the network [Which of course is
false:  "Mr. Watson, come here!"] that says retrieving a resource as indicated
in the discussion of the application of #fragment is _mechanism specific_ such
as is abjured by URNs.

>I don't know if the intent of RFC2396 was
>different, but as a specification, it's the wording that counts.

The wording of the specfication may fall short as far as making the intent
patently clear.

On the other hand it also falls far short of disproving what Roy said,
which is
IIRC what the intention of the group was as he was editing it on their behalf.

Al

>
>- Stephen
>

Received on Wednesday, 26 September 2001 23:11:43 UTC