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

From: Mark Nottingham <[email-masked]>
Date: Sun, 23 Dec 2007 23:13:01 +1100

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

What about changing the name? The proposal seems to change the concept  
substantially, and it's currently stuck in my head as a thing-on-the- 
wire, not a thing-on-the-server. Perhaps "variant resource"?

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.

Current text in 2616 for comparison:

> variant
> A resource may have one, or more than one, representation(s)  
> associated with it at any given instant. Each of these  
> representations is termed a `varriant'. Use of the term `variant'  
> does not necessarily imply that the resource is subject to content  
> negotiation.

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Sun, 23 Dec 2007 14:30:51 +0100

> Is the text below the solution for i69?

I don't think so:

1) It's not sufficient; with PROPFIND, REPORT and many other methods the 
request body would need to be taken into account as well.

2) I'm not entirely sure why we can't define the requested variant to be 
the same for all methods; as far as I understand this is what 
implementations do today.

> Is it necessary to refer to PROPFIND (Personally, I'd like to avoid the 
> informative ref if we can)?
> 
> substantially, and it's currently stuck in my head as a 
> thing-on-the-wire, not a thing-on-the-server. Perhaps "variant resource"?

I think Roy's proposal is indeed a semantic change, and I'm not 
comfortable with that change so far.

That being said, the problem in "requested variant" is the term 
"requested" -- for instance, when I PUT, I'm not really "requesting" a 
variant.

"Variant resource" sounds better, but may be confusing as well. Can a 
"variant resource" have multiple variants? I think so :-).

BR, Julian

---

From: "Javier Godoy" <[email-masked]>
Date: Sun, 23 Dec 2007 13:10:54 -0300

----- Original Message ----- 
From: "Mark Nottingham" <[email-masked]>
To: "HTTP Working Group" <[email-masked]>
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]

>>      own URI, which may be indicated by a Content-Location in the

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

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 27 Dec 2007 22:49:36 +0000

> >     own URI, which may be indicated by a Content-Location in the

When a variant is identified by its own URI indicated by
Content-Location, and keeping in mind that target of a request may
depend on request method and other things, _how_ is that
Content-Location URI supposed to be used?

Does it mean GET should be used with the Content-Location URI to fetch
that specific variant, while other methods cannot be depended upon to
access the specific variant (particularly if the specific variant was
originally selected dependent on request method)?  If so, the unique
role of GET on Content-Location URIs should be made clear.

-- Jamie