W3C home > Mailing lists > Public > public-bpwg@w3.org > September 2009

Re: Reviewer comments on X-Device Headers

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 22 Sep 2009 13:34:06 +0100
Message-ID: <4AB8C43E.6090202@mtld.mobi>
To: Francois Daoust <fd@w3.org>
CC: W3C MWBP WG <public-bpwg@w3.org>
OK, let's talk about this on the call, it is one of our favourite 
topics, after all.

FWIW I am not sure I can remember where the X- notation comes from nor 
can I now find any reference saying that extension header fields must or 
should be registered. So I would personally find it hard to do anything 
other than "remain silent" on the subject, which is what we do right now.

FWIW I have pasted what I think the relevant section from RFC 2616 
below. This is the only part of the RFC that refers to extension headers.

RFC Bingo will resume at 2.30 UK time on channel #bpwg.


7.1 Entity Header Fields

    Entity-header fields define metainformation about the entity-body or,
    if no body is present, about the resource identified by the request.
    Some of this metainformation is OPTIONAL; some might be REQUIRED by
    portions of this specification.

        entity-header  = Allow                    ; Section 14.7
                       | Content-Encoding         ; Section 14.11
                       | Content-Language         ; Section 14.12
                       | Content-Length           ; Section 14.13
                       | Content-Location         ; Section 14.14
                       | Content-MD5              ; Section 14.15
                       | Content-Range            ; Section 14.16
                       | Content-Type             ; Section 14.17
                       | Expires                  ; Section 14.21
                       | Last-Modified            ; Section 14.29
                       | extension-header

        extension-header = message-header

    The extension-header mechanism allows additional entity-header fields
    to be defined without changing the protocol, but these fields cannot
    be assumed to be recognizable by the recipient. Unrecognized header
    fields SHOULD be ignored by the recipient and MUST be forwarded by
    transparent proxies.

On 22/09/2009 13:14, Francois Daoust wrote:
> Jo Rabin wrote:
>> I think we are between the devil and the deep blue sea on this.
>> If we say that you can't extend it then aren't we contradicting RFC 
>> 2616 which says you can?
> You can't extend it if you're not doing it right, i.e. if you do not 
> register the additional replacement HTTP header fields, can you?
> I think that is what we should say.
> The group registered the replacement HTTP header fields it needed for 
> the guidelines. Additional registrations may be considered by third 
> parties and we should indeed not forbid anyone from extending the 
> mapping table as needed. Equally, we should not imply that you can 
> extend it without having the extension reviewed by the community, i.e. 
> without going through some Internet draft.
> Francois.
>> If we don't say you can't, then it's open to interpretation and that 
>> is probably the best we can do. I think we resolved this on some call 
>> or other but maybe we should re-resolve it?
>> Jo
>> On 22/09/2009 11:33, Francois Daoust wrote:
>>> Jo Rabin wrote:
>>> [...]
>>>> 2) ACTION-928
>>>> Registration of X-Device Headers
>>>> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/928
>>>> The reviewer's comments ref section spelling out the headers 
>>>> is addressed in a previous editor's draft.
>>> I think part of the comment [1] might bounce back:
>>> [[ as written, an implementer might conceivably feel free to add 
>>> additional headers that have not been registered. ]]
>>> While section now includes the mapping table, it does leave 
>>> open the possibility to add additional headers that have not been 
>>> registered.
>>> Francois.
>>> [1] http://lists.w3.org/Archives/Public/public-bpwg/2009Aug/0028.html
>>> [...]
Received on Tuesday, 22 September 2009 12:38:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:54 UTC