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

SM <sm@resistor.net> Wed, 06 July 2011 19:50 UTC

Return-Path: <sm@resistor.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 1987D21F8B54 for <apps-discuss@ietfa.amsl.com>; Wed, 6 Jul 2011 12:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BO0zfBaTMmeA for <apps-discuss@ietfa.amsl.com>; Wed, 6 Jul 2011 12:50:34 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2455621F8B74 for <apps-discuss@ietf.org>; Wed, 6 Jul 2011 12:50:31 -0700 (PDT)
Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p66Jo9k8006629; Wed, 6 Jul 2011 12:50:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1309981818; bh=VKGvP4XrLd7CB8QKlu8A72qGjXrfPBiCoK3XwViYHCo=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=fQ6qKE8uLJPmcp9J0c697idojL5tV02IsAcCmZ1q11cuIHlJP5T6k1eWEc8S4Q+qI HLMB2BajmdS784b1MFqpuk/DB86+xFcX40zKFTPRI7iEQ05URbXWW+wDVQuyxSGa6g E0WwxcA/Zw79NxPrC6GbyN3dfRUZ4UvDD6ua5+MU=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1309981818; bh=VKGvP4XrLd7CB8QKlu8A72qGjXrfPBiCoK3XwViYHCo=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=hZiEBgiA5gQdPd6KkCAGpd44gdCd1sjzNSBjkx8ZLEcS94CmzmbZ5YrNyPVsQZkIX 0kXa15uz+HVVADg/xJT5zNl4P/bgR0GJQAvSdNuisY8pDmCMUhTgEOPOZoBgKdn9Rv k/2ViASn4+yqXAJWQW4QzTb5SBM2mlalwbH5T02c=
Message-Id: <6.2.5.6.2.20110706121726.04f54f90@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 06 Jul 2011 12:49:27 -0700
To: dcrocker@bbiw.net
From: SM <sm@resistor.net>
In-Reply-To: <4E14A334.60500@dcrocker.net>
References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: 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 19:50:38 -0000

Hi Dave,
At 11:02 06-07-2011, Dave CROCKER wrote:
>The goal is to change normative behavior, so let's use normative 
>language (and I suggest changes to the ordering):
>
>    1.  Implementers wishing to experiment with parameters that have any
>        potential to be standardized SHOULD generate names without the
>        "X-" prefix.
>
>    2.  Authors of application protocol specifications SHOULD NOT
>        mandate that all parameters without the "X-" prefix need
>        to be registered with the IANA.
>
>(#2 seems odd.  I don't really understand why it is needed or what 
>it does that's significant, given the recommendation of not using x- 
>parameters ever. Is there a way of stating what is desired affirmatively?)

This is more of an open question; is it about standardizing the 
parameter or using the parameter over the Internet?  If an 
implementer wishes to use a parameter over the Internet, generate an 
I-D and ask for a provisional registration.  The problem with (2) is 
that it takes us back to the X- debate where "X-" was a way to have a 
parameter without IANA registration.

If the goal is to explain that X- has more cost than benefits, I am 
fine with what the document says.  For anything else, RFC 4122 
derived parameters or one derived from the domain name might do.  The 
issue with the latter can be addressed by getting a IANA registration.

Regards,
-sm