RE: new ECML v 2 requirements from Nokia

[Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>]

Hi Eric,

IETF Language Tags have ample provision for extension and registration of
languages not in ISO 639 so I really don't see any problem in defining that
field by reference to RFC 3066. (I was in error in the previous message
referring to RFC 3282. That RFC defines the Content-Language header which
uses language tags. The current definition for Language Tags is in RFC
3066.)

I'm not quite so clear on country codes but if you include the codes
reserved in ISO 3166 but not actually issued, I think you cover the entities
in the Universal Postal Union.  Can you give an example of a jurisdiction
not covered by that which would be of any significance in this protocol?

This protocol will only be interoperable to the extent that field values are
well defined. There is nothing wrong with having non-interoperable private
values and extensions, but I believe we should strive to have an
interoperable core of values.

Thanks,
Donald

-----Original Message-----
From: Eric Brunner [mailto:brunner@world.std.com]
Sent: Monday, June 10, 2002 10:39 AM
To: Donald Eastlake 3rd
Cc: lauri.piikivi@nokia.com; Chris.Brandt@ernexinc.com;
ietf-trade@lists.elistx.com; brunner@world.std.com
Subject: Re: new ECML v 2 requirements from Nokia


Donald,

I suggest that the references to iso3166 (and iso639) be recommended,
not manditory. There are jurisdictions that don't exist in 3166, and
languages that aren't in 639. Error semantics and local extensibility
are preferable over global uniqueness off of two- or three-alpha codes
that force extension (and error handling) elsewhere.

Eric