* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #69 (closed design: fixed)

Opened 7 years ago

Last modified 4 years ago

Clarify "Requested Variant"

Reported by: mnot@pobox.com Owned by:
Priority: urgent Milestone: 11
Component: non-specific Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/4697DC4A.3090602@gmx.de

Description

The spec uses the term "requested variant" in several places (10.2.2 201 Created, 10.2.5 204 No Content, 14.19 ETag, 14.25 If-Modified-Since, 14.28 If-Unmodified-Since). It's quite clear what it means in the context of HEAD/GET, somewhat clear for PUT, but not clear at all for other methods.

We really need to clarify this, potentially choosing a different term.

Change History

comment:1 Changed 7 years ago by mnot@pobox.com

  • Component set to auth

From http://www.w3.org/mid/F2154EEA-1B28-4C8F-BB64-D3AD29D0F9F9@gbiv.com

  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.

comment:2 Changed 7 years ago by mnot@pobox.com

  • Component changed from auth to messaging

comment:3 Changed 7 years ago by mnot@pobox.com

  • Milestone set to unassigned

comment:4 Changed 7 years ago by mnot@pobox.com

  • Component changed from messaging to non-specific

comment:5 Changed 7 years ago by mnot@pobox.com

Dependency on #109.

Part of resolving this ticket will involve removing the "requested variant" phrase from parts of the spec where its use isn't required, as part of other rewrites.

comment:6 Changed 6 years ago by mnot@pobox.com

related to #22

comment:7 Changed 5 years ago by mnot@pobox.com

  • Priority set to normal

Reminder: may need to revise definition of GET semantics for 200 response (p2 3.2.1) as a result of this issue's resolution.

comment:8 Changed 5 years ago by mnot@pobox.com

  • Priority changed from normal to urgent

comment:9 Changed 5 years ago by mnot@pobox.com

Basic plan is to rewrite on a case-by-case basis.

comment:10 Changed 4 years ago by fielding@gbiv.com

From [856]:

Addresses #69: Clarify "Requested Variant" Addresses #109: Clarify entity / representation / variant terminology

Replaced entity with payload and variant with representation. Cleaned up description of 204 status code (related to ticket #22) Rewrote section on Content-Location and refer to def in RFC2557.

Addresses #110: Clarify rules for determining what entities a response carries

Detail the rules for Content-Location and remove the cross-ref.

Addresses #167: Content-Location on 304 responses

Removed sentence in C-Loc that refers to using C-Loc to select a

variant from cache (an already removed "feature")

Addresses #136: confusing req. language for Content-Location

Removed the confusing paragraph because HTTP does not know anything about variants behind the resource interface and thus cannot make this an interop requirement. In any case, it only existed to support the already removed cache feature that nobody implemented.

Addresses #80: Content-Location isn't special

Clarifies that C-Loc is representation metadata and what (not) to do with it if received on a request.

comment:11 Changed 4 years ago by fielding@gbiv.com

From [860]:

Addresses #69: Clarify "Requested Variant"

Eliminated that phrase.

Addresses #109: Clarify entity / representation / variant terminology

Replaced variant with representation. Cleaned up p4 description of 304 and 206 status code

comment:12 Changed 4 years ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to incorporated
  • Severity set to Active WG Document
  • Milestone changed from unassigned to 11

Replaced with either representation, resource, or "the representation that would have been transferred in a 200 response to a GET request on the same resource", as appropriate.

comment:13 Changed 4 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:14 Changed 4 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.