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

Dirk Pranke <dpranke@chromium.org> Thu, 30 June 2011 18:46 UTC

Return-Path: <dpranke@google.com>
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 4551511E80AC for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jun 2011 11:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 0gvLknRxAkMy for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jun 2011 11:46:06 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE1F11E8077 for <apps-discuss@ietf.org>; Thu, 30 Jun 2011 11:46:06 -0700 (PDT)
Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p5UIk22v024470 for <apps-discuss@ietf.org>; Thu, 30 Jun 2011 11:46:02 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309459562; bh=Y6t/7q0Fc2HFejzvh7wN9ztuyjs=; h=MIME-Version:Sender:In-Reply-To:References:From:Date:Message-ID: Subject:To:Cc:Content-Type:Content-Transfer-Encoding; b=fDAFZQr7fW5lzHlNE3jOl7R/F6/GF4VaSt5TTowpq2m/VVmiacOkopJfXSs70MyA1 KPSE5svKTw6yXDYPv6wdw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:sender:in-reply-to:references:from: date:x-google-sender-auth:message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=fh4Kz0BLI9hjNtMp9ay/cZsS9yB05YsdgoyKXOzuPTbdr+zpU0m1hJedhrno9iN4b vqtUKWELEATLKP166M8Ng==
Received: from pvc21 (pvc21.prod.google.com [10.241.209.149]) by hpaq6.eem.corp.google.com with ESMTP id p5UIi0gJ012252 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <apps-discuss@ietf.org>; Thu, 30 Jun 2011 11:46:01 -0700
Received: by pvc21 with SMTP id 21so2929226pvc.39 for <apps-discuss@ietf.org>; Thu, 30 Jun 2011 11:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=eSYnOISNA9UierdVrX8TIEgnHnGRWbghrj9iIZb8y6U=; b=brxBAqeQB7aoSqrI3LnChaAK/+V/V55+5G/y/C6IWVbBH/Qrn3JDjUtAMETRnOBtA6 6kCRR4SPyFdPdC55Tfyg==
Received: by 10.142.136.18 with SMTP id j18mr1056299wfd.284.1309459560439; Thu, 30 Jun 2011 11:46:00 -0700 (PDT)
MIME-Version: 1.0
Sender: dpranke@google.com
Received: by 10.142.193.2 with HTTP; Thu, 30 Jun 2011 11:45:40 -0700 (PDT)
In-Reply-To: <C54B11FA-BCD2-4D60-9E46-851D6780D5DE@standardstrack.com>
References: <4E08CDCB.70902@stpeter.im> <BANLkTikOQt4k8YDv5z43SYuRcq5rzueGKw@mail.gmail.com> <C54B11FA-BCD2-4D60-9E46-851D6780D5DE@standardstrack.com>
From: Dirk Pranke <dpranke@chromium.org>
Date: Thu, 30 Jun 2011 11:45:40 -0700
X-Google-Sender-Auth: rM36F6BE1jSdCJQlefKFY8dvjYo
Message-ID: <CAEoffTBFJSmG90tjVr-ts0zHZBS96MdTmiJPY7450NGFKqVJBw@mail.gmail.com>
To: Eric Burger <eburger@standardstrack.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: General application-layer protocols discussion of <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] "X-" revisited
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Thu, 30 Jun 2011 18:46:07 -0000

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 <eburger@standardstrack.com> 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 <stpeter@stpeter.im> wrote:
>>> Based on comments received to date, I've published a heavily-revised
>>> version of the "X-" proposal:
>>>
>>> http://www.ietf.org/id/draft-saintandre-xdash-00.txt
>>>
>>> Further feedback is welcome!
>>>
>>> Peter
>>>
>>> --
>>> Peter Saint-Andre
>>> https://stpeter.im/
>>>
>>>
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>