From fd@w3.org Tue Aug 4 09:31:15 2009 Return-Path: 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 C2E023A7007 for ; Tue, 4 Aug 2009 09:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 8hX9UHGL9ZHp for ; Tue, 4 Aug 2009 09:31:15 -0700 (PDT) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by core3.amsl.com (Postfix) with ESMTP id E56723A67F4 for ; Tue, 4 Aug 2009 09:31:14 -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 ) id 1MYMuj-0008I9-2z; Tue, 04 Aug 2009 16:31:01 +0000 Message-ID: <4A786244.2000508@w3.org> Date: Tue, 04 Aug 2009 18:31:00 +0200 From: Francois Daoust User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: SM References: <4A55C127.8030609@w3.org> <4A572B0A.5020104@ninebynine.org> <4A575F8C.7070907@w3.org> <6.2.5.6.2.20090710090140.02a0f0c8@resistor.net> In-Reply-To: <6.2.5.6.2.20090710090140.02a0f0c8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Graham Klyne , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 16:31:15 -0000 Apologies for the late reply, I somehow managed not to see it up until now. SM wrote: > Hi Francois, > At 08:34 10-07-2009, Francois Daoust wrote: >> The situation the Mobile Web Best Practices working group is trying to >> address is one where different vendors used different HTTP header >> field conventions (all starting with 'X-') for the same use in their >> proxies, requiring content providers to support the different names >> when they wanted to do things properly. What the working group would >> like to do is to shrink the list of existing conventions to one and >> only one convention, but would prefer not to introduce any new >> convention (be it the last one) for that to happen. The 'X-Device-foo' >> format is the most commonly used format in the list based on the >> group's experience, and thus the chosen one. > > I'll encourage you to adopt Graham's suggestion of moving to > "Device-foo" or any other valid name that does not start with "X-". > These "X-" headers are generally for private use where the > interpretation is by private agreement. There are people outside the > group that might use that header field for other purposes and they are > unlikely to look it up in the registry. If your working group already > agrees on having one convention, it is better to do away with the "X-". > Thanks. I understand the suggestion and the implications of not following the suggestion. At this point, the working group agrees on having one convention among the existing ones, which unfortunately all start with "X-". But the working group does not agree to do away with the "X-" not to introduce any kind of new notation. If you're fine with it, the group would thus like to proceed only with the registration of the "X-" versions of the HTTP header fields. Francois. [...] From sm@resistor.net Wed Aug 12 00:06:40 2009 Return-Path: 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 C9BF43A695D for ; Wed, 12 Aug 2009 00:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 yr8Ihwzbd0w2 for ; Wed, 12 Aug 2009 00:06:39 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id D5D693A63D3 for ; Wed, 12 Aug 2009 00:06:39 -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 n7C6rKJM027106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 23:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1250060009; x=1250146409; bh=Pwe3+si63EFdFH/tLDVPkreee9y5a97ZIO77WNkxp8E=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=LR2gQiEhVvIJXYfSnYx2Yb69iPPxQEmSOMvjyhYZSx9Oxu2BLo7jM9dBtGbIj8Ati xxoUtkKcwXX3CcbYJm7heVzFvYqzadGqBxDodMXbNUvcLnPvSowUyEULNQCgzN4lqE 5QZZjsJL7nsjlF6s5xLhuwKd2Bkxdfdm2QmvdcPk= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=Kl3Ffx4JTeDwjiqaVpR3UEfgrWrGY/Qr49QzFPXkY0yQt1gO/FXEydXs6D08IkT9l 0conKZ8uBh9bTx0iHb8KlxcgpC6+vAnianV2u56qta/SWR+SpxinGwb4foA9jdiL5QB P82SsZs/mzLyx6Sdw9y5FeHCjXJgosJzRlKRk9I= Message-Id: <6.2.5.6.2.20090811224922.02b803d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Aug 2009 23:38:40 -0700 To: Francois Daoust From: SM In-Reply-To: <4A786244.2000508@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Graham Klyne , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 07:06:40 -0000 Hi Francois, At 09:31 04-08-2009, Francois Daoust wrote: >At this point, the working group agrees on having one convention >among the existing ones, which unfortunately all start with "X-". >But the working group does not agree to do away with the "X-" not to >introduce any kind of new notation. If you're fine with it, the >group would thus like to proceed only with the registration of the >"X-" versions of the HTTP header fields. The alternatives are: (i) Reject the request as "X-" message header fields names are generally not registered in the provisional and permanent Message Header Fields registries given that "X-" message header field names are reserved for private use. (ii) Accept the request for the registration of the five "X-Device-*" message header fields in the provisional Message Header Field Names registry with a "depreciated" status. There aren't any "X-" headers in the Permanent Message Header Field Names registry. As the working group does not agree to do away with the "X-", there may be a request to register the five "X-Device-*" message header fields as permanent Message Header field names. I suggest using the first alternative as the working group does not plan to obsolete the five "X-Device-*" HTTP Header fields. Regards, -sm From fd@w3.org Thu Aug 13 01:43:06 2009 Return-Path: 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 C7C653A6950 for ; Thu, 13 Aug 2009 01:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PiOhaMgpr6zA for ; Thu, 13 Aug 2009 01:43:05 -0700 (PDT) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by core3.amsl.com (Postfix) with ESMTP id B46083A692F for ; Thu, 13 Aug 2009 01:43:05 -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 ) id 1MbVC9-00086W-PU; Thu, 13 Aug 2009 07:57:57 +0000 Message-ID: <4A83C786.9030607@w3.org> Date: Thu, 13 Aug 2009 09:57:58 +0200 From: Francois Daoust User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: SM 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> In-Reply-To: <6.2.5.6.2.20090811224922.02b803d8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Graham Klyne , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 08:43:07 -0000 SM wrote: > Hi Francois, > At 09:31 04-08-2009, Francois Daoust wrote: >> At this point, the working group agrees on having one convention among >> the existing ones, which unfortunately all start with "X-". But the >> working group does not agree to do away with the "X-" not to introduce >> any kind of new notation. If you're fine with it, the group would thus >> like to proceed only with the registration of the "X-" versions of the >> HTTP header fields. > > The alternatives are: > > (i) Reject the request as "X-" message header fields names are > generally not registered in the provisional and permanent Message Header > Fields registries given that "X-" message header field names are > reserved for private use. > > (ii) Accept the request for the registration of the five "X-Device-*" > message header fields in the provisional Message Header Field Names > registry with a "depreciated" status. > > There aren't any "X-" headers in the Permanent Message Header Field > Names registry. As the working group does not agree to do away with the > "X-", there may be a request to register the five "X-Device-*" message > header fields as permanent Message Header field names. I suggest using > the first alternative as the working group does not plan to obsolete the > five "X-Device-*" HTTP Header fields. I'm not sure I understand why you directly jump to deprecated at this step. 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. The intent of the working group is indeed to send a request to register the header fields in the permanent registry when (and if) the specification reaches a more stable level. 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. 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. Regards, Francois. > > Regards, > -sm > From sm@resistor.net Fri Aug 14 00:03:02 2009 Return-Path: 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 ; 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 ; 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 ; 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 From: SM 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 , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From fd@w3.org Fri Aug 14 07:15:08 2009 Return-Path: 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 569BC3A6A22 for ; Fri, 14 Aug 2009 07:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 ImteRgawMuFA for ; Fri, 14 Aug 2009 07:15:07 -0700 (PDT) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by core3.amsl.com (Postfix) with ESMTP id 2EAF73A69F6 for ; Fri, 14 Aug 2009 07:15:07 -0700 (PDT) Received: from 52.19.70-86.rev.gaoland.net ([86.70.19.52] helo=[192.168.1.5]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MbuGZ-0001Ul-2i; Fri, 14 Aug 2009 10:44:11 +0000 Message-ID: <4A853FFB.2030502@w3.org> Date: Fri, 14 Aug 2009 12:44:11 +0200 From: Francois Daoust User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: SM 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> In-Reply-To: <6.2.5.6.2.20090813232440.03f79318@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Graham Klyne , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:15:08 -0000 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. > That makes sense. In our case, note the "X-" header field names have already been adopted in mobile networks, the "X-Device-" form being the most common ones. This is why the group argues that the "X-" *already* cannot be dropped. > In future, someone will come up with an argument that there is already > some "X-" header names in the permanent registry. Perhaps it would be better to issue some recommendation that says "Do not use X- prefix at all for new HTTP header fields!". They seem to have often been used as synonym to a vendor-specific namespace rather than for private experiments. For new HTTP header fields, why not use a "real" name and register it provisionally without much ado, perhaps in a "private provisional" registry and simply drop this "X-" convention? For instance, your email client adds an X-Mailer HTTP header field to the message. There are other ways such information may be defined in an email: Mail-System-Version or Originating-Client for instance. These are non-standard HTTP header fields, but they are pretty common. I am not aware of any attempt to standardize one of them. If the info were deemed essential in the end, I guess one of the non "X-" HTTP header fields would probably be used and properly defined and standardized. And yet, whoever introduced them had no real "right" to do that. He should have used an "X-" HTTP header field. Once an "X-" HTTP header field has managed to escape the private sphere, the transition period lasts as long as the header field is in use when the transition affects millions of content authors. Don't we end up with locked situations where a given HTTP header field cannot be properly standardized because of the transition period? X-Forwarded-For, X-Wap-Profile have been used for years in mobile networks. It's a pity they cannot be registered properly, simply because they were not introduced with a correct name. Standardisation often has to compose with already existing stuff, and cannot just pretend nothing existed in the first place. The real discussion should be on the usefulness of the header fields. >> 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. > I do not think the working group can move ahead against the rest of the world. At the very least, It would have to justify why it thinks it's right. >> 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. Agreed. The group does not think that this is a real problem in this case. Trying to summarize to see if we are on the same grounds. If I get you right, you suggest that we do not register any HTTP header field at this step OR that we register the new HTTP header fields as "depreciated". The argument in favor of that is that the draft is not stable enough and registration of new HTTP fields in the provisional registry would seem like an encouragement to adopt them. If we do register HTTP fields names as depreciated, can we update their status to "non-depreciated" at a later time and thus use the provisional registry as a mere name reservation mechanism? Thanks, Francois. > > Regards, > -sm > From sm@resistor.net Fri Aug 14 13:26:58 2009 Return-Path: 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 1C4423A6BD8 for ; Fri, 14 Aug 2009 13:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 tvUh-hUVvdXN for ; Fri, 14 Aug 2009 13:26:57 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 13C8C3A6BAA for ; Fri, 14 Aug 2009 13:26:57 -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 n7EKQoT5010618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 13:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1250281619; x=1250368019; bh=UqnsfB2lxKKNAwzfflT7K8v0I83Fi07Xtc+/GLa6u3Y=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=fLXAT/EbgcA/OIif5e5z5h3JF2DTnw/GiL2K4UAX/HbVpbXepevvdhgXvqUVsvczm lkv1S8bL1/odO9aGMr8QsJnY99gWBpE6MfpaeQmD/etCCnYVMMEseK3YfvnH1dMBwq 6HVZS6RM7IdGb8UU+7y7HfD2Kvt1UG7fAkp/qlW8= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=fvr5yNJEKVeSbMd/QFpED9yQ03D1iG+HvI7AWr4vgk8VZAMVOaggbNofl5A7wFqsL i8NrS8u7ayOHuO+/iwOfnqVlPTPQfyIbVrB4um+JzDMsZAEGBDGqrU7niDldbo3G0uX yMx67O8b0rKfwQM6KKpSWuuw15cEuKpgMhKYa2g= Message-Id: <6.2.5.6.2.20090814115056.03260598@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Aug 2009 13:22:25 -0700 To: Francois Daoust From: SM In-Reply-To: <4A853FFB.2030502@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> <6.2.5.6.2.20090813232440.03f79318@resistor.net> <4A853FFB.2030502@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Graham Klyne , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 20:26:58 -0000 Hi Francois At 03:44 14-08-2009, Francois Daoust wrote: >Perhaps it would be better to issue some recommendation that says >"Do not use X- prefix at all for new HTTP header fields!". They seem >to have often been used as synonym to a vendor-specific namespace >rather than for private experiments. For new HTTP header fields, why >not use a "real" name and register it provisionally without much >ado, perhaps in a "private provisional" registry and simply drop >this "X-" convention? Private would also cover what vendors do internally. Once they seek interoperability with other vendors or use over the Internet, they can ask for a registration in the provisional registry. >For instance, your email client adds an X-Mailer HTTP header field >to the message. There are other ways such information may be defined >in an email: Mail-System-Version or Originating-Client for instance. >These are non-standard HTTP header fields, but they are pretty >common. I am not aware of any attempt to standardize one of them. If >the info were deemed essential in the end, I guess one of the non >"X-" HTTP header fields would probably be used and properly defined >and standardized. And yet, whoever introduced them had no real >"right" to do that. He should have used an "X-" HTTP header field. The "X-Mailer:" is a common Internet Message header. It is documented as not part of an Internet Standard and is not in any of the message header field names registries. There are also other issues with the message format emitted by my mail server. :-) It's not really about whether we have the "right" to introduce a header. It's more about avoiding conflict by using a common namespace as reference and to avoid interoperability issues. >Once an "X-" HTTP header field has managed to escape the private >sphere, the transition period lasts as long as the header field is >in use when the transition affects millions of content authors. > >Don't we end up with locked situations where a given HTTP header >field cannot be properly standardized because of the transition >period? X-Forwarded-For, X-Wap-Profile have been used for years in >mobile networks. It's a pity they cannot be registered properly, >simply because they were not introduced with a correct name. >Standardisation often has to compose with already existing stuff, >and cannot just pretend nothing existed in the first place. The real >discussion should be on the usefulness of the header fields. Yes. There are some problems that can't be fixed. :-) >Trying to summarize to see if we are on the same grounds. If I get >you right, you suggest that we do not register any HTTP header field >at this step OR that we register the new HTTP header fields as >"depreciated". The argument in favor of that is that the draft is >not stable enough and registration of new HTTP fields in the >provisional registry would seem like an encouragement to adopt them. I suggest that the group determines the naming of its HTTP header fields and requests a registration in the provisional message header registry. If the header field name begins with "X-", mark it as "depreciated", i.e. it is or will be superceded by another field name. If the draft is not stable enough or you don't want to encourage others to adopt the field name, don't register it in the provisional registry now. If the draft is an open specification, an implementor outside the group might read the draft and use the headers in his or her implementation. It's up to the group to decide whether to provide guidance on adoption of the headers and if so, how to do so. >If we do register HTTP fields names as depreciated, can we update >their status to "non-depreciated" at a later time and thus use the >provisional registry as a mere name reservation mechanism? I'll defer to IANA on the status update as it is an unusual move to go from "depreciated". The provisional registry acts as a name reservation mechanism. If I see "Device-User-Agent:" in there, I'll have to come up with a different field name if I am requesting a registration. Regards, -sm From fd@w3.org Mon Aug 17 00:27:56 2009 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Graham Klyne 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >> >