RE: Section 3.5. Passing fragment identifiers to other systems.

-----Original Message-----
From:	uri-request@w3.org on behalf of ext Roy T. Fielding
Sent:	Tue 2004-02-24 01:28
To:	Graham Klyne
Cc:	Williams, Stuart; uri@w3.org
Subject:	Re: Section 3.5. Passing fragment identifiers to other systems.



On Monday, February 23, 2004, at 08:20  AM, Graham Klyne wrote:
> At 15:02 23/02/04 +0000, Williams, Stuart wrote:
>
>> Roy et. al,
>>
>> RFC2396bis [1] Section 3.5 para 4 states: "As such, interpretation of 
>> the
>> fragment identifier during a retrieval action is performed solely by 
>> the
>> user agent; the fragment identifier is not passed to other systems 
>> during
>> the process of retrieval."
>>
>> Is the focus of this sentence on retrieval deliberate - ie. the spec 
>> has
>> nothing to say about whether or not fragment identifiers are passed 
>> to other
>> systems during operations other than retrieval?
>>
>> I'd have expected this prohibition to have been more universal.
>
> I'd say that the prohibition must indeed be focused on retrieval.  
> There are other applications for which it is vital that a fragment 
> identifier part of a URI be passed to other systems - XML namespaces 
> and passing RDF data come to mind.

I think what Stuart is noting is that a fragment is also not passed
for PUT or POST or any other action on the URI via HTTP. 
     
             The "any other action... via HTTP" seems pretty severe to me.

             I think it's OK to state that for certain methods, the fragment identifier
            is not considered to be relevant to the request (e.g. GET, PUT, POST,
            etc.

             But for other methods, e.g. MGET, MPUT, MDELETE as defined by
             the URIQA model (http://sw.nokia.com/uriqa/URIQA.html) such a 
             constraint would preclude alot of interaction between SW agents
             via HTTP concerning resources denoted by URIrefs with fragids.


 I am still
thinking of a way to rephrase it.  Perhaps what it should say is that
the fragment is not passed to another system upon dereference of the 
URI?

               That would, of course, depend on the definition of "dereference".
               I consider e.g. MGET to involve dereference of a URI to a description
               of the denoted resource. Again, I think it is safest to take a more 
               conservative position on this and simply note the irrelevance of fragids
               for particular methods.

               That said, even if some fragid is not relevant for some particular method,
               that does not mean that software should not include the fragid in requests.
               Or perhaps more generally, the URI of a request should be honored by
              all intermediate agents (proxies, firewalls, etc.) and should not be modified
              in any way. If the ultimate server recieving and acting upon the request
               disregards a fragid because it is not relevant to the method in question, fine.
              But we should not have to worry about fragids being lost in transit, particularly
               when using new/experimental/proprietary methods.

               The irrelevance of fragids to GET, PUT, POST, etc. should not preclude
                research and experimentation by either licensing or encouraging 
               software to discard them in transit.

               Cheers,

               Patrick Stickler
               patrick.stickler@nokia.com



....Roy

Received on Tuesday, 24 February 2004 01:50:58 UTC