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

[Eric Burger <[e-mail]>]

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