Subject: RE: new ECML v 2 requirements from Nokia

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Mon, 10 Jun 2002 11:01:50 -0400

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:[email-masked]]
Sent: Monday, June 10, 2002 10:39 AM
To: Donald Eastlake 3rd
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
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

---

From: Eric Brunner <[email-masked]>
Date: Mon, 10 Jun 2002 11:30:42 -0400

Donald,

The big issue is jurisdiction, from which the regulatory circumstances and
taxation consequences of a transaction arise.

> not covered by that which would be of any significance in this protocol?

The Navajo Nation is vastly larger than the Vatican State, Monacco, Pitcarn's
Island, the Channel Islands, the Sechyelles, and a dozen Pacific Nations ...
combined. The Pequot Nation is vastly wealthier than some of those also.

To limit the territorial jurisdiction identifiers to the criteria set by the
DIN makes two-byte comparison easy, but it subordinates use to "states".

Tell me how I can use thie protocol if the trading community consists of
financial clearinghouse operating companies located within the soverign
indigenous nations of North America (I already know the answer for soverign
colonial nations).

> interoperable core of values.

We shouldn't use iso3166 unless there really is no alternative. Until last
year you couldn't even find Palestine in 3166.

Practially speaking, for iso3166 territorial jurisdictions (TJs), implementors
will use 3166 code. Realistically, implementors for non-3166 TJs will consult
the TJ for identifiers.

Eric

---

From: Donald Eastlake 3rd <[email-masked]>
Date: Mon, 10 Jun 2002 23:35:31 -0400 (EDT)

Hi,

On Mon, 10 Jun 2002, Eric Brunner wrote:

> Date: Mon, 10 Jun 2002 11:30:42 -0400
> From: Eric Brunner <[email-masked]>
> To: Eastlake III Donald-LDE008 <[email-masked]>
> Cc: 'Eric Brunner' <[email-masked]>, [email-masked],
>      [email-masked], [email-masked],
>      [email-masked]

The Navajo Nation, etc., are subordinate entities that are "soveriegn"
only to the extent that the US allows. In this regard, it is not clear
to me that they are different from states or territories of the US.
Since you talk about tax consequences, it can vary in the US not just on
state/indian-nation but also city, county, special districts, and who
knows what else...

> indigenous nations of North America (I already know the answer for soverign

US law prevails in the cases where the US has decided it is important
enough. When the law can vary and this is important, you would need a
subdesignator under the country code.

> year you couldn't even find Palestine in 3166.

Whether you like the situation or not, the Palestinian Authority /
Occupied Palestinian Territories is a subordinate sovereignty to Israel
and has just as much sovereignty as Isreal permits, as recent events
have shown.

So you don't like iso3166. What exactly is your alternative? You make a
reasonable argument that there is some benefit in being able to extend
iso3166 codes, the same way the IETF standard lets you extend ISO
language codes, but I'm not convinced it come up much in real life or if
it does, that you can't just figure it out from other parts of the
address. I don't think there is any standard for such extensions and I
don't think the TRADE WG wants to take on defining such a standard.

> will use 3166 code. Realistically, implementors for non-3166 TJs will consult

I would note that all the financial card network protocols I know of get
along fine using UN Country numbers, which are pretty much the same as
iso3166 country codes.

Donald

---

From: Chris Smith <[email-masked]>
Date: Tue, 11 Jun 2002 00:47:29 -0400 (Eastern Daylight Time)

> > > not covered by that which would be of any significance in this protocol?

There needs to be a decision regarding a geographical basis vs a
political basis. ISO 3166 refers to "areas of geopolitical
interest", and won't completely resolve the issue for you.

Many embassies are in Washington DC, U.S.A, but the embassies
proper are considered sovereign. Jurisdiction and location
can be independent at times.

> The Navajo Nation, etc., are subordinate entities that are
> "soveriegn" only to the extent that the US allows.

Subject to occasional court decisions, both ways...

> Since you talk about tax consequences, it can vary in the US
> not just on state/indian-nation but also city, county,
> special districts, and who knows what else...

Don't forget parish. Yes, accomodating this could be difficult.
If it was easy we would be done by now...

> language codes,

Even ISO 3166 documents some of the 'extensions' - witness the
addition of "ca-nu". But it also clear that in some cases, the
chain of jurisdiction does not flow all the way back to "ca".

So, the choice would appear to be between

1) ISO 3166 codes and restricting the field as such
2) allow ISO and private codes with a way to distinguish
3) provide one ISO field and one 'Jurisdiction' field

1) is tough and inflexible
2) tends towards non-interoperable
3) is growing the complexity

It depends on what the goal is - what IS the goal for
this field, anyway?

----------------------------------------------------------------------
Chris Smith                                       <[email-masked]>

---

From: Eric Brunner <[email-masked]>
Date: Tue, 11 Jun 2002 10:17:48 -0400

Donald,

> Whether you like the situation or not, the Palestinian Authority

We don't dork with ARIN/RIPE/APNIC addr allocations because some State
has a preference for negative-allocation to a competitor.
We don't dork with the IANA root because some State wants to edit it.
We don't dork with BGP4 because some State wants to prevent peering to
a competitor.

We are neutral, or as neutral as we are conscious of how mechanism
is distorted by policy. States don't define the scope of correct
function by a protocol, even an application protocol.

Some octets for an identifier. Is Big. Fine.
Two octets interpreted as 16 bits. Is Still Big. Fine.
Two octets restricted to ASCII isalpha(). Not Is Big. Worry.
Two octets restricted to ASCII isalpha() and restricted to fewer than
300 values, over a hundred of which are absolutely bogus for a 1st-world
financial infrastructure except as tax dodges and worse, and which makes
extension elsewhere manditory. Ouch.

> So you don't like iso3166. What exactly is your alternative? 

Don't overspecify. Use MAY nor MUST. It isn't our business to codify the
passions of Kings and Presidents, or make the net safe for Nation States.

I object to iso3166 as unnecessary overspecification of the range of
identifiers of a two- (or more) octet, octet-alligned field. You've
noted the objection, so we're probably done.

Eric