Re: [Ietf-message-headers] Provisional registration of 5 X-Device-* HTTP Header fields for use in content transformation guidelines

Francois Daoust <fd@w3.org> Mon, 17 August 2009 07:27 UTC

Return-Path: <fd@w3.org>
X-Original-To: ietf-message-headers@core3.amsl.com
Delivered-To: ietf-message-headers@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0757C3A6950 for <ietf-message-headers@core3.amsl.com>; Mon, 17 Aug 2009 00:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Level:
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWIrAxkPG+Mp for <ietf-message-headers@core3.amsl.com>; Mon, 17 Aug 2009 00:27:55 -0700 (PDT)
Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by core3.amsl.com (Postfix) with ESMTP id 9B4663A6940 for <ietf-message-headers@ietf.org>; Mon, 17 Aug 2009 00:27:53 -0700 (PDT)
Received: from doust-w3claptop.sophia.w3.org ([10.1.2.97]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <fd@w3.org>) id 1Mcwd1-0007xC-8F; Mon, 17 Aug 2009 07:27:39 +0000
Message-ID: <4A89066B.4050002@w3.org>
Date: Mon, 17 Aug 2009 09:27:39 +0200
From: Francois Daoust <fd@w3.org>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Graham Klyne <GK@ACM.ORG>
References: <4A55C127.8030609@w3.org> <4A572B0A.5020104@ninebynine.org> <4A575F8C.7070907@w3.org> <6.2.5.6.2.20090710090140.02a0f0c8@resistor.net> <4A786244.2000508@w3.org> <6.2.5.6.2.20090811224922.02b803d8@resistor.net> <4A83C786.9030607@w3.org> <6.2.5.6.2.20090813232440.03f79318@resistor.net> <4A86AC16.70609@ACM.ORG>
In-Reply-To: <4A86AC16.70609@ACM.ORG>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ietf-message-headers@ietf.org
Subject: Re: [Ietf-message-headers] Provisional registration of 5 X-Device-* HTTP Header fields for use in content transformation guidelines
X-BeenThere: ietf-message-headers@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <ietf-message-headers.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-message-headers>
List-Post: <mailto:ietf-message-headers@ietf.org>
List-Help: <mailto:ietf-message-headers-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2009 07:27:56 -0000

Thanks,

I will report to the working group, and will likely proceed with the 
provisional registration of the header fields, with a clear 
understanding that thorough discussion with IETF is needed to transition 
from provisional to permanent:
  1. because of the use of the "X-" prefix, and
  2. because the introduction of new HTTP header fields require as wide 
a review as possible anyway.

Francois.



Graham Klyne wrote:
> As designated reviewer for registrations, here's my current position:
> 
> If this were a mail header, I think the response would be fairly 
> clear-cut:  the email standards prohibit the standardization of headers 
> named X-whatever.  But this is HTTP, and the last time I checked I 
> didn't see any specific status for X-headers there.  And there is a 
> general feeling that, while it sometimes serves a purpose, the approach 
> of using X-headers for experimentation generally does not work, for 
> reasons that are exemplified by this debate.
> 
> This leaves us with the strong expectations of developers who have 
> worked with IETF protocols that X-headers are experimental, and not to 
> be taken seriously.
> 
> The header registration procedure itself deliberately does not take a 
> position on X- headers, so there is nothing there specifically 
> prohibiting the permanent registration of X-headers - it's up to the 
> protocol concerned (HTTP in this case) to specify what is the minimum 
> requirement for standardization.  Permanent registration requires 
> publication as "open standard", which means a clear community consensus 
> is required;  this is not necessarily an IETF standard - W3C REC is good 
> - but I'd expect some dialog with the IETF if there appears to be a 
> conflict of styles or expectations.
> 
> Thus: if the document is approved as an IETF proposed standard with the 
> X-header specifications (which I think may be effectively required for 
> all but new HTTP entity-header fields), then I would have no problem 
> agreeing to the permanent registration of the X-headers.  Otherwise, I 
> would look for IETF review and consensus by IESG and/or HTTP protocol 
> experts that permanent registration of an X-header is not likely to 
> cause any problems in other areas.
> 
> Personally, if I have to make the call, I'd allow it because I can't see 
> any fundamental reason not to do so.  But I really would prefer to see 
> wider review.
> 
> None of this in any way impedes provisional registration.
> 
> #g
> -- 
> 
> 
> SM wrote:
>> Hi Francois,
>> At 00:57 13-08-2009, Francois Daoust wrote:
>>> I'm not sure I understand why you directly jump to deprecated at this 
>>> step.
>>
>> A provisional registration is a step towards permanent registration.  
>> Omitting the depreciated status would be an encouragement to adopt 
>> that header field name.  Once that is done, it will be argued that the 
>> "X-" cannot be dropped.
>>
>> In future, someone will come up with an argument that there is already 
>> some "X-" header names in the permanent registry.
>>
>>> I thought the purpose of the provisional registry was to reserve 
>>> names while the underlying specification matures along the 
>>> standard-track. The underlying specification is not definitive, and 
>>> there will be at least one other Last Call working draft period 
>>> during which the working group expects to receive external comments 
>>> both on the choice of names and the usefulness of these HTTP header 
>>> fields.
>>
>> Yes.  But if the working group is not agreeing on the change now, it 
>> is improbable that they will agree to it on another Last Call.
>>
>>> The use of the "X-" prefix has been extensively discussed both 
>>> formally within the group and informally with some IETF contributors. 
>>> The fact that companies use private "X-" header field names on a 
>>> public level is a pity, but it is unfortunately common practice 
>>> within mobile networks. We are trying to move away from a situation 
>>> where there exist 5 different sets of "X-" header field names to a 
>>> situation where there's only one. Mobile content developers complain 
>>> about the existence of these different sets that were imposed on 
>>> them. They do not want to hear about a new one, introduced for the 
>>> sake of removing the "X-" prefix, in particular if that means they 
>>> would still have to be prepared to receive the "X-" form and the non 
>>> "X-" during the transition period.
>>
>> The transition period can be now or later.  The longer we wait to do 
>> such changes, the more difficult it will be.
>>
>>> That is the reason why the mobile web best practices working group 
>>> thinks it is reasonable to bend the naming rule here. We are not 
>>> aware of any real difference between "X-" header fields and regular 
>>> non "X-" ones, apart from their intended use.
>>
>> When using "X-" headers, it is difficult to tell whether anyone 
>> outside the working group is using the headers for other purposes.
>>
>> Regards,
>> -sm
>> _______________________________________________
>> Ietf-message-headers mailing list
>> Ietf-message-headers@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-message-headers
>>
>