[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Ltru] Private Use Tags



> From: ltru-bounces at lists.ietf.org [mailto:ltru-bounces at lists.ietf.org]
On
> Behalf Of Dylan N. Pierce


> The solution is simply to define an organizational namespace. We take
a
> random tag--we'll say "P" for private--and then allow companies and
> organizations to register their own namespace. Everything that follows
> their namespace tag is then interpreted according to their standard,
> whatever that may be. For example, the ALA would register "ala," the
AP
> would register "ap," Microsoft would register "mcrsoft," Adobe would
> register "adobe" and so on.

This reminds me a bit of an idea Gary Simons and I came up with in 2000,
though we were thinking about alternate naming agencies for the primary
language subtag, not private-use subtags.

The particular benefit of your proposal is realized if extensions are
defined by agencies rather than for particular functions. It's clear
that there are far more than 35 agencies that could potentially want
their own variant extensions, but not clear that there are that many
functions. Up to now, I don't think anyone has mentioned the possibility
that extensions could be defined for use within single agencies.

I'd be open to seeing your idea considered further. It doesn't have to
go into this document, however: it's an extension, and this doc provides
the framework needed for creating extensions. Given the late date and
the delays this doc has seen, I recommend that we not pursue adding this
into *this* document, but that you consider preparing an internet draft
for your proposed extension and present it for discussion once this is
approved (i.e. waiting until there is an approved framework on which to
propose extensions).



Peter Constable

_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.