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

Tim Williams <williamstw@gmail.com> Wed, 06 July 2011 11:02 UTC

Return-Path: <williamstw@gmail.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 5D0F421F86CE for <apps-discuss@ietfa.amsl.com>; Wed, 6 Jul 2011 04:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Level:
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
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 I5UYPDClaURc for <apps-discuss@ietfa.amsl.com>; Wed, 6 Jul 2011 04:02:25 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7907921F86D2 for <apps-discuss@ietf.org>; Wed, 6 Jul 2011 04:02:25 -0700 (PDT)
Received: by pvh18 with SMTP id 18so9143648pvh.31 for <apps-discuss@ietf.org>; Wed, 06 Jul 2011 04:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FQYRwAxeIUtTfT787IGl32dcM3/+7huXH5IC/ld+ZCE=; b=meC9gm+Fke96C9RDZRKLH0I7g3HXRGxuD+O8kEbztWeFdAJEk0F1b9SI+otcG9xrG1 aaxaw3tH0T8LAPmkYcDyoJw0KxGwXhIzp6egX0HDcBlG6BK8fMGcDZo5DMkOohjKVe21 KqE7gk/V7sLhGE+3JBWsG6AR0RglfyyEOGkMg=
MIME-Version: 1.0
Received: by 10.68.13.228 with SMTP id k4mr10351324pbc.40.1309950144826; Wed, 06 Jul 2011 04:02:24 -0700 (PDT)
Received: by 10.68.46.104 with HTTP; Wed, 6 Jul 2011 04:02:24 -0700 (PDT)
In-Reply-To: <4E13DC15.2080302@stpeter.im>
References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im>
Date: Wed, 06 Jul 2011 07:02:24 -0400
Message-ID: <CAG_bHozjo=tkGmxKjCiadg=X9uG53HV=7PRf2VULSCZ7c2=RcA@mail.gmail.com>
From: Tim Williams <williamstw@gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "apps-discuss@ietf.org" <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: Wed, 06 Jul 2011 11:02:26 -0000

On Tue, Jul 5, 2011 at 11:52 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> On 6/27/11 12:36 PM, Peter Saint-Andre 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
>
> Based on list feedback, I've submitted a further revision (including
> much more specific recommendations for spec authors and implementers):
>
> http://www.ietf.org/id/draft-saintandre-xdash-01.txt
>
> Keep those cards and letters coming! ;-)

Hi Peter,
I'm interested in the "Recommendations" section and two things appear curious:

 "4.  Implementers wishing to experiment with parameters that are
       unlikely to be standardized are encouraged to generate
       meaningless names such as UUIDs or the output of a hash function."

Why?  It's not clear to me why names with obfuscated meaning is better
or worse than an X- prefix (or any other name) - when they are clearly
not intended for standardization?  Can you share more about *why*
that's encouraged?

   5.  Implementers wishing to create parameters for use in
       implementation-specific applications or on private networks are
       encouraged to mint URIs or generate names that incorporate the
       relevant organization's name or primary domain name.

Not sure if this is atypical for a spec like this but an example or
two would help for #5.  Is the intent something like:
urn:com:example:headers:myheader
or
http://example.com/headers/myheader
or
headers:example.com/myheader

or, it just doesn't matter?

FWIW, I'd also suggest substituting "subclass" or somesuch in the
following in the place of "ghetto":

"   Therefore it appears that segregating non-standard parameters into an
   "X-" ghetto has few if any benefits, and has at least one significant
   cost in terms of interoperability."

Thanks,
--tim