Re: Rewrite of feature tag syntax rules

On Mon, 19 May 1997, Jeffrey Mogul wrote:

> As Larry says, at the bottom of the hierarchy we want
> an enumerated type (essentially opaque) for specifying a feature
> tag "on the wire".  We could just as easily use small integers
> for these, but using ASCII tags might have some benefit in
> debugging things.

Then it's very easy to see what could (and probably will) happen:
- Western (mostly US) users will use meaningful ASCII tags.
- Because they are meaningful, some applications will show them
	to the end user and allow the end user to manipulate them.
- English-speaking users will be at an advantage to others, and
	problems and flaming with internationalization will start.
- Some people will even blame the problems on internationalization
	rather than on the original design.

> Fine; just introduce a map between a set of human-sensible,
> internationalized names, and the enumerated set of feature tags.

To "introduce" such a map is easy. But if it's an add-on that
won't be implemented because the original implementors don't
need it, it's a non-starter. The two real solutions are:

- Have a syntax that allows meaningful names for the whole
	world. (This would mean e.g. URI syntax with
	correct treatment of %HH and such.)

- Have a two-level system for the whole world, i.e. strictly
	limit the syntax of the lower level to something that
	can't possibly ever make sense, such as digits only.
	(This would mean e.g. digits only, with the "description
	field" mentionned by Koen used as the second level.)

ASCII only is only a solution in cases such as e.g. GET/PUT/HEAD,
where we very well could also say that these are UTF-8, but
where we have an extremely limited number of values. When it
comes to open name spaces, name spaces that possibly have to
be able to express things to end users, and name spaces that
possibly have to be able to express concepts in various languages,
ASCII only is a bad choice.


Regards,	Martin.

Received on Thursday, 22 May 1997 06:16:59 UTC