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

SM <sm@resistor.net> Fri, 14 August 2009 07:03 UTC

Return-Path: <sm@resistor.net>
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 8281F3A67B1 for <ietf-message-headers@core3.amsl.com>; Fri, 14 Aug 2009 00:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level:
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599]
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 Ijx3QcXTcKIe for <ietf-message-headers@core3.amsl.com>; Fri, 14 Aug 2009 00:03:01 -0700 (PDT)
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 6A00C3A63EB for <ietf-message-headers@ietf.org>; Fri, 14 Aug 2009 00:03:01 -0700 (PDT)
Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n7E6pWxp011738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 23:51:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1250232701; x=1250319101; bh=jolti1dGJaqQ54MvL/jXEcl6YJ9W2NwI/x9vy4FrG+g=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=nD3eDpZYJ5Kq6Ql23WtEtQXLWmcrIPvNQb6nET0hlqbs2C+0QFdWevCvCiG3d00Ku 9eocoKZQsMl8qcawSVWgZJ4Cssm5mFvDAqRxVy8X48m810sPuHuqrvwl+V5ri4RDfP tNi3KTqV6HJ4MNp2OLzNJPXGSsfTQISCES5tUiOk=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=sLEXCev2xIgp7GAsfTcWsTFEPEgXOo8wVto7qaAIrRy4+qdOsVg4H6maSd2Vaszkp d5nL1CABlJySmRU/Fh3gDsnXwxMQ6ksVZAr6ZosYtAGrAQXa2KTFqjsltsGqgx+eK1h VvGKVH9tnTJmvlKjCTPY8pCXMKGzRva4NCE87UQ=
Message-Id: <6.2.5.6.2.20090813232440.03f79318@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 13 Aug 2009 23:50:28 -0700
To: Francois Daoust <fd@w3.org>
From: SM <sm@resistor.net>
In-Reply-To: <4A83C786.9030607@w3.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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Graham Klyne <GK@ninebynine.org>, 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: Fri, 14 Aug 2009 07:03:02 -0000

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