Message-Id: <6.2.1.2.2.20050524233528.047bba30@mail.jefsey.com>
Date: Tue, 24 May 2005 23:58:15 +0200
To: "McDonald, Ira" <imcdonald@sharplabs.com>,
	"'Peter Constable'" <petercon@microsoft.com>, ltru@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] Editorial error in BNF
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7BEE@mailsrvnt02.enet.sh
	arplabs.com>
References: <CFEE79A465B35C4385389BA5866BEDF00C7BEE@mailsrvnt02.enet.sharplabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear all,
I would _strongly_ advise to stabilise your XML oriented tag for the 
present and to not consider "RFC 3066 ter" now. You all know that I 
disagree with the concept of this Draft to become BCP 047, and that I find 
its proposition technically not precise, and conflicting (between a precise 
orthogonal charset and a non defined notion of "script"). A conflict which 
is by far not resolved at ISO 639-4 level. Etc.

But RFC 3066 bis is proposed/supported by W3C people and it will be used 
for XML, with the difficulties you all described. If it is accepted, it 
will be used. So, do not make things more complex for users and developers. 
Randy will say that the text is not written for me and I should learn 
English before reading it, but I find enough complexities and oddities (Ira 
quoted some), not to add more. Please, only include things that WILL work, 
not things that MIGHT work.

Unless, obviously, you want to kill the project because you finally agree 
with me, without telling it officially. What I doubt. :-(
jfc

At 19:29 24/05/2005, McDonald, Ira wrote:
>Hi Peter,
>
>I tend to agree with you about defining things for the future.
>If the future's very close (months later) that might work.
>
>RFC 3066 defined the format of language tags such that future
>changes/additions of subtag elements would still allow a
>successful parse.  That seems to be the intent here, but I'm
>not convinced that it can be achieved.
>
>Unfortunately, it's rather important that it _is_ achieved,
>because otherwise clients that examine language tags on returned
>results will fail to parse them when a non-trivial new subtag
>element is defined in RFC3066ter.  That would mask entirely
>access to the that new content to the older client.
>
>Cheers,
>- Ira
>
>
>
>Ira McDonald (Musician / Software Architect)
>Blue Roof Music / High North Inc
>PO Box 221  Grand Marais, MI  49839
>phone: +1-906-494-2434
>email: imcdonald@sharplabs.com
>
> > -----Original Message-----
> > From: ltru-bounces@lists.ietf.org
> > [mailto:ltru-bounces@lists.ietf.org]On
> > Behalf Of Peter Constable
> > Sent: Tuesday, May 24, 2005 12:56 PM
> > To: ltru@ietf.org
> > Subject: RE: [Ltru] Editorial error in BNF
> >
> >
> > My point is that it's not even clear that the *lang* subtag is where
> > these would go. But I guess I don't care if you want to allow for
> > possible 4alpha subtags that *might* be defined some day; it
> > just seems
> > rather speculative. If someone suggested we might someday allow
> > 4alphanum (not purely alpha or purely num) in the region
> > slot, would we
> > go ahead and define the syntax for that now?
> >
> >
> > Peter Constable
> >
> >
> >
> > > -----Original Message-----
> > > From: Addison Phillips [mailto:addison.phillips@quest.com]
> > > Sent: Tuesday, May 24, 2005 9:38 AM
> > > To: Peter Constable; ltru@ietf.org
> > > Subject: RE: [Ltru] Editorial error in BNF
> > >
> > > We wouldn't define the syntax or even the source for alpha4 primary
> > > language subtags. It would work thusly:
> > >
> > > 1. The ABNF defines lang=2*4ALPHA / 5*8alphanum
> > > 2. The text defines that ALPHA2 and ALPHA3 subtags are
> > defined by ISO
> > 639-
> > > 1 and ISO 639-2.
> > > 3. The text says that ALPHA4 subtags are reserved for future
> > > standardization. Implementations know that four letter subtags might
> > be
> > > added to the registry in the future.
> > >
> > > Implementations know already how to deal with the primary language
> > > subtag(the semantics of ISO 639-6 are not important here)
> > and must be
> > > written to handle registered subtags with length two through eight.
> > > Ultimately this has no impact on implementations: the only
> > effect this
> > has
> > > is that there won't be any four letter primary language
> > subtags in the
> > > registry. Well, it has one effect: a primary language subtag with a
> > length
> > > of four that contains a digit is illegal.
> > >
> > > In other words, your caution that we should wait to see ISO 639-6
> > before
> > > standardizing it in language tags is well taken, but not
> > important at
> > this
> > > juncture. We are merely reserving a location in the
> > registry for those
> > > values. Standardization of 3066-based language tags on ISO
> > 639-6 might
> > > never happen or will at least happen in its own time. The exact same
> > can
> > > be said about ISO 639-3.
> > >
> > > Addison
> > >
> > > Addison P. Phillips
> > > Globalization Architect, Quest Software
> > > Chair, W3C Internationalization Core Working Group
> > >
> > > Internationalization is not a feature.
> > > It is an architecture.
> > >
> > > > -----Original Message-----
> > > > From: ltru-bounces@lists.ietf.org
> > [mailto:ltru-bounces@lists.ietf.org]
> > > On
> > > > Behalf Of Peter Constable
> > > > Sent: 2005?5?24? 9:10
> > > > To: ltru@ietf.org
> > > > Subject: RE: [Ltru] Editorial error in BNF
> > > >
> > > > > From: ltru-bounces@lists.ietf.org
> > [mailto:ltru-bounces@lists.ietf.org]
> > > > On
> > > > > Behalf Of Mark Davis
> > > >
> > > >
> > > > > One of the goals of the project was that the BNF never
> > needs to be
> > > > changed
> > > > > in the future; that every current parser must be able to read
> > every
> > > > future
> > > > > tag. (You've reminded me of this on occasion!) So it must be
> > changed
> > > > to
> > > > > 2*4
> > > >
> > > > See my comments in another msg just sent: I do not think at this
> > point
> > > > we can know what the syntax for language tags that incorporate an
> > ISO
> > > > 639-6 standard would look like, so I think the
> > requirement that devs
> > be
> > > > able to anticipate that future syntax with certainty now is
> > impossible.
> > > >
> > > >
> > > >
> > > > Peter Constable
> > > >
> > > > _______________________________________________
> > > > Ltru mailing list
> > > > Ltru@lists.ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > Ltru@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru
> >
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru