Subject: RE: [Ltru] Editorial error in BNF

From: "Peter Constable" <[email-masked]>
Date: Tue, 24 May 2005 11:57:50 -0700

I'm OK with moving forward on this basis.

Peter Constable

> -----Original Message-----
> From: Addison Phillips [mailto:[email-masked]]
> Sent: Tuesday, May 24, 2005 10:37 AM
> To: Peter Constable; [email-masked]
> Subject: RE: [Ltru] Editorial error in BNF
> 
> > 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?
> 
> Yes. It would break the design to do that, of course.
> 
> > 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
> 
> The consensus seemed to be: we know that ISO 639-6 is being worked on.
The
> material is not mature enough to incorporate into 3066bis. However, we
can
> make a very minor marginal allowance for the possibility of ISO 639-6
> being of value in forming language tags at some future date and the
only
> cost is forbidding the registration of alpha4 subtags for now.
> 
> A future update could incorporate ISO 639-6 in an appropriate way or
> restore the ability to register alpha4 subtags or, as you say, allow
> registration of alphanum4 subtags.
> 
> In other words, there is no cost to do it and it was a consensus to
> reserve a slot in case it becomes interesting/necessary in the future.
I'm
> not going to defend ISO 639-6 here: I am actually skeptical about the
> effort, but there is no reason to prevent ISO 639-6 from being easily
> incorporated at a future date.
> 
> 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: [email-masked]
[mailto:[email-masked]]
> On
> > Behalf Of Peter Constable
> > Sent: 2005?5?24? 9:56
> > To: [email-masked]
> > 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:[email-masked]]
> > > Sent: Tuesday, May 24, 2005 9:38 AM
> > > To: Peter Constable; [email-masked]
> > > 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: [email-masked]
> > [mailto:[email-masked]]
> > > On
> > > > Behalf Of Peter Constable
> > > > Sent: 2005?5?24? 9:10
> > > > To: [email-masked]
> > > > Subject: RE: [Ltru] Editorial error in BNF
> > > >
> > > > > From: [email-masked]
> > [mailto:[email-masked]]
> > > > 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
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 24 May 2005 15:48:48 -0700

Hi -

> From: "Peter Constable" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, May 24, 2005 11:57 AM

> I'm OK with moving forward on this basis.
...

As a contributor, so am I.
If we've guessed correctly, it's a major win.
If we've our guess is wrong, the harm is insignificant, and could
be rectified in an update to the specification.

Randy

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 25 May 2005 08:51:50 +0100

> be rectified in an update to the specification.

+ 1

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: 24 May 2005 23:49
> To: [email-masked]
> Subject: Re: [Ltru] Editorial error in BNF
> 
> Hi -
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 25 May 2005 17:15:12 -0700

Hi -

I've created a ticket to record our resolution of this issue.
If you think it needs further discussion, *please* use the
appropriate subject line, rather than the not-too-accurate
"Editorial error in BNF".

The ticket summary says:
-------------------------------------------------------------------------
Although ISO 639-6 will not be ready in time for this work to
reference it formally, there were statements that it would be
desirable to structure the ABNF so that the impact on
implementations would be minimized, if ISO 639-6 develops
as is currently anticipated.

This question arose in several threads, and a summary of
concerns is in
http://www1.ietf.org/mail-archive/web/ltru/current/msg01869.html

The rough consensus was to allow for them in syntax, recognizing
that there is a risk that 639-6 might take a different form.

-------------------------------------------------------------------------

Randy, ltru co-chair