Subject: Moving to editorial: i39 / i51 / i61 / i64 / i94

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Apr 2008 12:05:38 +1100

Looking over the design issues list <http://www3.tools.ietf.org/wg/httpbis/trac/report/9 
 >, the following issues look like they can be handled by the editors  
without input from the WG (keeping in mind that we can always correct  
errors after they're in the draft);

* i39 - ETag uniqueness

* i51 - HTTP-date vs. rfc1123-date

* i61 - Redirection vs. Location

* i64 - WS in quoted-pair

* i94 - Reason-Phrase BNF

If anyone (especially the editors) has an objection, please say so.

Cheers,

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Apr 2008 03:41:42 +0200

Mark Nottingham wrote:

 <http://www3.tools.ietf.org/wg/httpbis/trac/report/10>
> the following issues look like they can be handled by
> the editors without input from the WG
[...]
> * i51 - HTTP-date vs. rfc1123-date
[...]
> * i64 - WS in quoted-pair

i51 + i64 look interesting, the latter mentions to use
RFC 2822.  When the editors tackle this I hope they
check 2822upd, there are some subtle ABNF corrections,
and 2822upd is very near to ready (behind PubReq).

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Apr 2008 14:51:12 +0200

Mark Nottingham wrote:
> ...
> ...

Fixed with <http://www3.tools.ietf.org/wg/httpbis/trac/changeset/237>.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Apr 2008 15:32:00 +0200

> * i64 - WS in quoted-pair

Fixed with <http://www3.tools.ietf.org/wg/httpbis/trac/changeset/238>.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Apr 2008 16:25:59 +0200

> * i51 - HTTP-date vs. rfc1123-date

I think there was no real consensus for a change, see for instance Roy 
in <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0293.html>:

RF> No, there is no need for any changes in that section (aside from
RF> updating the BNF to the ABNF standard).
RF>
RF> The BNF is for parsing the superset of what is allowed in a message,
RF> not for defining all of the specifics of each message generation.
RF> All IETF specs that use BNF specify it to be lenient in what is
RF> received,
RF> while the text requirements add limitations to be conservative in
RF> what is sent.

My proposal is to either close as WONTFIX, or to do a minimal BNF change 
that makes the intent a bit more clearer, as proposed by Henrik in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0289.html>:

HN> Maybe we shoud split the HTTP-date BNF for the older dates in two steps
HN> to stress this within the BNF as well? I.e. something like the
HN> following:
HN>
HN> 	HTTP-date     = rfc1123-date | obsolete-date
HN> 	obsolete-date = rfc850-date | asctime-date

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Apr 2008 17:23:52 +0200

> * i39 - ETag uniqueness

Looking at 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p4-conditional-02.html#entity.tags>:

"Entity tags are used for comparing two or more entities from the same 
requested resource. HTTP/1.1 uses entity tags in the ETag (Section 7.1), 
If-Match (Section 7.2), If-None-Match (Section 7.4), and If-Range 
(Section 6.3 of [Part5]) header fields. The definition of how they are 
used and compared as cache validators is in Section 5. An entity tag 
consists of an opaque quoted string, possibly prefixed by a weakness 
indicator.

   entity-tag = [ weak ] opaque-tag
   weak       = "W/"
   opaque-tag = quoted-string

A "strong entity tag" MAY be shared by two entities of a resource only 
if they are equivalent by octet equality.

A "weak entity tag," indicated by the "W/" prefix, MAY be shared by two 
entities of a resource only if the entities are equivalent and could be 
substituted for each other with no significant change in semantics. A 
weak entity tag can only be used for weak comparison.

An entity tag MUST be unique across all versions of all entities 
associated with a particular resource. A given entity tag value MAY be 
used for entities obtained by requests on different URIs. The use of the 
same entity tag value in conjunction with entities obtained by requests 
on different URIs does not imply the equivalence of those entities."

...it already seems clear that each entity has it's own etag (expect for 
the special case of weak etags).

Now, what we may want to clarify though is when entities are indeed 
different -- we know that implementors got that wrong with 
Content-Encoding, for instance. That would make it a change to Part 3, I 
guess.

- should we try to improve 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-02.html#rfc.section.4> 
(introduction of "Entity"), or

- would it be sufficient to add a warning to the description of 
Content-Encoding 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-02.html#rfc.section.6.5>)?

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Apr 2008 12:44:29 +1100

FWIW, I think that this might help, but we should probably address  
i109 (clarify entity / representation / variant terminology ) first.

Cheers,

On 04/04/2008, at 2:23 AM, Julian Reschke wrote:
> - should we try to improve <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-02.html#rfc.section.4

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Apr 2008 10:41:38 +1000

> HN> 	obsolete-date = rfc850-date | asctime-date

+1

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Apr 2008 15:47:06 +0200

>> HN>     obsolete-date = rfc850-date | asctime-date

Ok, change applied and issue closed with 
<http://tools.ietf.org/wg/httpbis/trac/changeset/239>.

BR, Julian