Re: Clarify "Requested Variant" [was: New "200 OK" status codes, PATCH & PROPFIND]

----- Original Message ----- 
From: "Mark Nottingham" <mnot@mnot.net>
To: "HTTP Working Group" <ietf-http-wg@w3.org>
Cc: "Roy T. Fielding" <>
Sent: Sunday, December 23, 2007 9:13 AM
Subject: i69: Clarify "Requested Variant" [was: New "200 OK" status codes, 
PATCH & PROPFIND]


> <http://tools.ietf.org/wg/httpbis/trac/ticket/69>
>
> Is the text below the solution for i69?
>
> Is it necessary to refer to PROPFIND (Personally, I'd like to avoid  the 
> informative ref if we can)?
>
> On 07/08/2007, at 8:52 AM, Roy T. Fielding wrote:
>
>>   variant
>>      The ultimate target resource of a request after indirections
>>      caused by content negotiation (varying by request fields) and
>>      method association (e.g., PROPFIND) have been taken into account.
>>      Some variant resources may also be identified directly by their
>>      own URI, which may be indicated by a Content-Location in the
>>      response.

When servicing the POST method, the representation MAY also depend on the 
request entity.

For instance,

     PROPFIND /file HTTP/1.1
     Host: www.example.com
     Content-type: application/xml; charset="utf-8"
     Content-Length: xxxx

     <?xml version="1.0" encoding="utf-8" ?>
     <D:propfind xmlns:D="DAV:">
       <D:prop xmlns:R="http://ns.example.com/boxschema/">
         <R:bigbox/>
         <R:author/>
         <R:DingALing/>
         <R:Random/>
       </D:prop>
     </D:propfind>

is quite similar to

     POST /file HTTP/1.1
     Host: www.example.com
     Content-type: application/x-www-urlencoded
     Content-Length: xxxx

     action=propfind&xmlns%3A=http://ns.example.com/boxschema&prop1=R%3Abigbox&prop2=R%3Aauthor&prop3=R%3ADingALing&prop4=R%3ARandom

(though the latter is a bit weird, just for illustrating my point).

The only difference I see is that PROPFIND always depends on the 
request-entity, while POST is not required to do so, but that difference 
goes beyond the definition of "variant".

I would refer to POST instead of PROPFIND in the definition, thus it would 
be self-contained within RFC 2616 and the informative reference would be 
avoided.

Regards

Javier

Received on Sunday, 23 December 2007 16:13:40 UTC