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