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

Dzonatas Sol <dzonatas@gmail.com> Sun, 03 July 2011 16:35 UTC

Return-Path: <dzonatas@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 4693A11E807A for <apps-discuss@ietfa.amsl.com>; Sun, 3 Jul 2011 09:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.829
X-Spam-Level:
X-Spam-Status: No, score=-4.829 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_00=-2.599, 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 Y6M6ENBawoqV for <apps-discuss@ietfa.amsl.com>; Sun, 3 Jul 2011 09:34:59 -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 5F9A511E807E for <apps-discuss@ietf.org>; Sun, 3 Jul 2011 09:34:59 -0700 (PDT)
Received: by pvh18 with SMTP id 18so5749738pvh.31 for <apps-discuss@ietf.org>; Sun, 03 Jul 2011 09:34:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=85Pehc+LOp5jd+yGsy4usQbYGS+/ezqw1y3ZApbpSnY=; b=HLWerQRvDaPsKXU1oZu5LhJ2gU9l2RqWR9i+KY3AKlck3Pq+NorzhDWrrydM3bGpxg nbRHcv28pB7d377J4tYa0Oey+LRC5nJCpjuF1qGzwIGDBgw8286FzWveHU0tnCgszIoV vMqM8zlkukSQCfQSKtPPLZao4LKN6s6084HZA=
Received: by 10.68.17.5 with SMTP id k5mr5897218pbd.92.1309710898762; Sun, 03 Jul 2011 09:34:58 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id p7sm1525287pbn.17.2011.07.03.09.34.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jul 2011 09:34:57 -0700 (PDT)
Message-ID: <4E109A17.1010502@gmail.com>
Date: Sun, 03 Jul 2011 09:34:31 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.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> <CAEoffTBFJSmG90tjVr-ts0zHZBS96MdTmiJPY7450NGFKqVJBw@mail.gmail.com> <9B604239-6A7D-4669-9F34-839A3DECC4FA@standardstrack.com>
In-Reply-To: <9B604239-6A7D-4669-9F34-839A3DECC4FA@standardstrack.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Sun, 03 Jul 2011 16:35:00 -0000

On 07/03/2011 09:15 AM, Eric Burger wrote:
> 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.
>    

ASCII is a protocol with-in itself, so there is no question about "a 
protocol be in ascii".

> 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<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
>>>>          
>>>
>>>        
>    
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>    


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant