Re: [psg.com #960] use ITU E.164 calling codes instead of ISO 3166 country codes

At 00:57 12/05/2005, Randy Presuhn wrote:
> > From: "JFC (Jefsey) Morfin" <jefsey <at> jefsey.com>
> > To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>; "LTRU Working 
> Group" <ltru <at> ietf.org>
> > Sent: Wednesday, May 11, 2005 12:00 PM
> > Subject: Re: [Ltru] [psg.com #960] use ITU E.164 calling codes instead 
> of ISO 3166 country codes
> >
>
> >
> > At 20:28 11/05/2005, Randy Presuhn wrote:
> > >Hi -
> > > > In message
> > > > http://www1.ietf.org/mail-archive/web/ltru/current/msg01643.html
> > > > it was proposed to use ITU E.164 calling codes instead of ISO 3166
> > > > country codes.
> > >
> > >I haven't seen much support for this proposal, and some rather compelling
> > >arguments against it, so unless I see a groundswell of support, I plan to
> > >mark this one "rejected".
> >
> > Where did you read _instead_??
>...
>
>Please, then, state just what your proposal is.  Showing what the changes 
>to the
>ABNF would be might help.
>
>In the meantime, pending discussion of your proposal, I've re-opened the 
>issue.

My logic is the logic of the Charter which is a IANA registry where one can 
register needed relevant subtags. In the case of a region, ISO 3166, M.9, 
E.164, X.121, postcodes, geographic coordinates, ISO 3166-2, etc. are 
serious entries people may want/need to use or register. Our problem is to 
provide the IANA with a solution to take care of the version. I provided 
one. Mark has discussed the canonical aspect, Interface Grids may also 
provide a solution (an IPv6 identifier  compatible 10 to 12 hexa 
incremented number).

I fully understand that this logic conflicts with the specific format the 
W3C needs to use in the XML case. This is why the current Draft is the 
second document expected from this WG and not the first one. In the 
specific case of each applications the format may prevent some of the IANA 
from being used. It is the choice and the responsibility of the authors of 
each application specific format to best use the possibilities offered by 
the general Internet language indentification framework the first document 
should be.

For example in the case of E.164, I have no objection that the format calls 
for 4 or more digits padded with Fs since E.164 would probably more used as 
area codes. Non F digits would only be considered.

jfc

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