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

Eric Burger <> Sun, 03 July 2011 16:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BF6221F8616 for <>; Sun, 3 Jul 2011 09:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.346
X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TQVeop5Ymwyf for <>; Sun, 3 Jul 2011 09:15:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 22E9F21F8615 for <>; Sun, 3 Jul 2011 09:15:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=n0tW0rFUQK5vCDr1OiNszWvKhL95fGs7wTYMQQGrSbKzMvCgZakHq3J0p8iHRHj7UXRqQFkLb9ljKcnz9yHAIFbBrehkGpk7liOUjRtINpeeBoR8lYQUdfPIpnSWOHay;
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <>) id 1QdPKF-0004zj-Iq; Sun, 03 Jul 2011 09:15:15 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-137-690031576; protocol="application/pkcs7-signature"; micalg=sha1
From: Eric Burger <>
In-Reply-To: <>
Date: Sun, 3 Jul 2011 12:15:13 -0400
Message-Id: <>
References: <> <> <> <>
To: Dirk Pranke <>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Cc: General application-layer protocols discussion of <>
Subject: Re: [apps-discuss] "X-" revisited
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Jul 2011 16:15:18 -0000

On the one hand, we often DO have binary codes for protocol parameters, cf. IP as an example.

Is it easier to read ASCII text? Sure.
It is easier to understand English text, if you can read English? Sure.

It is a requirement a protocol be in ASCII and in English? Absolutely not.

That is the difference between a protocol parameter and the DNS. No one will sue you for creating an amex parameter.

On Jun 30, 2011, at 2:45 PM, Dirk Pranke wrote:

> If we wanted protocol parameters to be arbitrary strings, we'd just
> use huffman-encoded binary data or something similar. We don't, and it
> is well acknowledged that having protocols composed of human-readable
> text has a lot of advantages. In addition, since the protocol *is*
> text and not always hidden behind an API, the protocol *is* the API,
> and a well-designed API is easier to use.
> -- Dirk
> On Thu, Jun 30, 2011 at 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.
>> The point is *this* name space is huge and fungible, whereas the DNS is large and NOT fungible.
>> On Jun 29, 2011, at 6:05 PM, Dirk Pranke wrote:
>>> Your draft has:
>>>>  In some situations, segregating the name space of parameters used in
>>>>  a given application protocol can be justified:
>>>>  ...
>>>>  2.  When parameter names might have significant meaning.  This case
>>>>      is rare, since implementers can almost always find a synonym
>>>>      (e.g., "urgency" instead of "priority") or simply invent a new
>>>>      name.
>>> It seems to me that a primary benefit of the "X-" convention is that
>>> it makes unprefixed parameter names less socially acceptable; i.e.,
>>> there's a pretty clear rule of thumb that if the name isn't X-
>>> prefixed, it probably has seen a pass through a committee and hence it
>>> stands at least a chance of having the same meaning in multiple
>>> implementations.
>>> I am concerned that if you abandon the X- practice, you will lose this
>>> benefit and finding untainted, available parameter names might become
>>> harder. Sure, you can often find a synonym, but it is not usually as
>>> good as the original choice. I would hate to see things move to a
>>> namespace land-grab like we have seen in DNS.
>>> Has this been raised as an issue before?
>>> -- Dirk
>>> On Mon, Jun 27, 2011 at 11:36 AM, Peter Saint-Andre <> wrote:
>>>> Based on comments received to date, I've published a heavily-revised
>>>> version of the "X-" proposal:
>>>> Further feedback is welcome!
>>>> Peter
>>>> --
>>>> Peter Saint-Andre
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>> _______________________________________________
>>> apps-discuss mailing list