Re: [apps-discuss] "X-" revisited

Dave CROCKER <dhc@dcrocker.net> Fri, 01 July 2011 03:13 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FD61F0C41 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jun 2011 20:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.566
X-Spam-Level:
X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S9cIkmqAuoD for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jun 2011 20:13:51 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BE9DA1F0C35 for <apps-discuss@ietf.org>; Thu, 30 Jun 2011 20:13:51 -0700 (PDT)
Received: from [192.168.1.147] (ppp-68-120-198-5.dsl.pltn13.pacbell.net [68.120.198.5]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p613Dk8d011226 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Thu, 30 Jun 2011 20:13:51 -0700
Message-ID: <4E0D3B64.5020500@dcrocker.net>
Date: Thu, 30 Jun 2011 20:13:40 -0700
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4E08CDCB.70902@stpeter.im> <BANLkTikOQt4k8YDv5z43SYuRcq5rzueGKw@mail.gmail.com> <C54B11FA-BCD2-4D60-9E46-851D6780D5DE@standardstrack.com>
In-Reply-To: <C54B11FA-BCD2-4D60-9E46-851D6780D5DE@standardstrack.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 30 Jun 2011 20:13:51 -0700 (PDT)
Subject: Re: [apps-discuss] "X-" revisited
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2011 03:13:52 -0000

Eric,

On 6/30/2011 4:22 AM, Eric Burger wrote:
> The difference between protocol parameters and domain names is domain names are meant for human consumption, while protocol parameters are arbitrary strings of ASCII or UTF-8 text. A protocol might use the string "kritisch" to mean "something critical." Great -- people building user interfaces will read the RFC, know that parameter is "kritisch" and will display "critical," "crucial," "krytyczny," or whatever is appropriate for the user. For that matter, one could really use the string "foobar" to mean "something criticial" or even the number 42. The protocol will work just fine, and users (who do NOT read what is on the wire) can have a great experience.

You have the theory down exactly correctly, IMO.  The practice however matches 
the theory only partially.  Were all fieldnames fully registered, it would 
probably match completely, but they aren't.

In point of fact, most header fields are meant for human consumption and that 
includes their fieldnames, which frequently are entirely ad hoc and can't be 
predictably translated.


> The point is *this* name space is huge and fungible, whereas the DNS is large and NOT fungible.

I guess I'm missing what the import is, for the distinction(s) you are making.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net