Subject: RE: [Ltru] Referencing the Scheme within the Tag

From: "Peter Constable" <[email-masked]>
Date: Mon, 4 Jul 2005 17:39:16 -0700

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Debbie Garside

> What harm is there in my proposal?

There's no harm in proposing something; there's only a risk of rabbit
trails if a proposal isn't explained clearly. Now, is there harm in
*adopting* your proposal? I'm not certain what you're proposing, so I
can't say.

If you're suggesting that the ABNF specify

Language-Tag[RFC3066bis]= (lang
                          *3("-" extlang)
                          ["-" script]
                          ["-" region]
                          ...

rather than 

Language-Tag = (lang
                *3("-" extlang)
                ["-" script]
                ["-" region]
                ...

then I think there's no harm, but I also think there's nothing
accomplished. The RFC would still provide a single syntax; it just
happens to name the start rule slightly differently.

I think what you really want is the *consuming* protocols that use these
metadata elements should add some kind of qualifier in their protocols
to indicate what specification for the particular metadata category is
in use. Something along the lines of 

<body xml:lang="zh-yue-Hant" xml:langspec="RFC 3066bis">

In general, I think this kind of meta-metadata can be useful,
particularly if there's likelihood of re-architecting something. And
while I don't foresee particular reasons for rearchitecting this
category of metadata elements, it would be foolish to assume a need
wouldn't arise in ten or twenty or fifty or more years.

But, this is something that belongs in *consuming* protocols, not in
this document. At most, this document can suggest that applications
incorporate support for such meta-metadata.

Given that there are lots of existing applications / consuming protocols
of RFC 3066 that do *not* do this, and given that adding text of this
sort isn't likely going to change them, I wouldn't make it a priority.
Given that we are overdue and trying to drive toward completion, I'm
reluctant to consider another addition at this time -- feature creep
*can* harm us. If it's to be entertained at all, I'd suggest that this
not be adopted unless some proposed text is provided promptly and
there's a quick consensus that the proposed text is a useful addition.

Peter Constable

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 05 Jul 2005 04:32:39 +0200

> Language-Tag[RFC3066bis]= (lang
[...]
 
> Language-Tag = (lang
[...]
 
> then I think there's no harm, but I also think there's
> nothing accomplished.

| The name of a rule is simply the name itself; that is, a
| sequence of characters, beginning with an alphabetic
| character, and followed by a combination of alphabetics,
| digits and hyphens (dashes).

No square brackets.  Bye, Frank

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 4 Jul 2005 19:54:54 -0700

I'm absolutely in accord with Peter.

‎Mark

----- Original Message ----- 
From: "Peter Constable" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 04, 2005 17:39
Subject: RE: [Ltru] Referencing the Scheme within the Tag

On

rather than

Language-Tag = (lang
                *3("-" extlang)
                ["-" script]
                ["-" region]
                ...

Peter Constable

---

From: Martin Duerst <[email-masked]>
Date: Tue, 05 Jul 2005 10:40:15 +0900

Personally, and technically, I have to agree with Peter.
I'm also not sure ABNF allows '[' and ']' on the left side
of productions (which could be fixed easily by changing the
proposal to something like Languag-Tag-RFC-****, however).

Please note that in general standards practice, it's the
using standard that defines what spec to use, so e.g. a
protocol or format spec using RFC3066bis will say something
like "protocol element foo is a Language-Tag according to
RFC 3066bis".

Regards,    Martin.

---

From: r&d afrac <[email-masked]>
Date: Tue, 05 Jul 2005 13:08:26 +0200

>like "protocol element foo is a Language-Tag according to

Debbie,
as long as the "RFC 3066" does not define the (possibly conditional to the 
format) purpose (decriptive, normative, etc.) of the tag there will be a 
possible ambiguity on a considered langtag own internal ambiguity. If this 
langtag system develops in using ISO 3166/15924/639 usage will probably 
decide. I suppose that an other way may develop from http://rfc3066.org 
warning: the use of a comment. It will permit to enter:

en-Latn-us as a general confusing entry: as discussed we do not know it if 
is an in/out/exchange - required/advised etc.
en.air-Latn-us could be understood as en - context RFC 3066, in signal, 
required to pursue (this is just an hint: could also be en.a.i.r-Lantn-us)

jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 7 Jul 2005 23:25:46 -0700

Hi -

The proposal is in message
http://www1.ietf.org/mail-archive/web/ltru/current/msg02535.html
Followed by discussion starting with message
http://www1.ietf.org/mail-archive/web/ltru/current/msg02536.html

At this time, it sounds like we have some WG members strongly
in favor of the proposal, and some others who view it as neither
necessary nor harmful, so I plan to mark this one as "resolved",
assuming the editors will make the necessary changes.

If there are technical objections to adopting this proposal,
this is your last chance to make them.

Randy, ltru co-chair

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Jul 2005 09:31:27 +0200

> this is your last chance to make them.

See <http://mid.gmane.org/[email-masked]>

The proposal makes no sense, is not allowed in ABNF, and
should be rejected.  If you are talking about this idea:

| Language-Tag[RFC3066bis]= (lang
[...]

Variations with hyphens, underscores, or other decorations
are not better.  ABNF is no meta data.  Bye, Frank

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 8 Jul 2005 14:55:02 -0700

In those two messages, there was no firm proposal for a change that the
editors could make. The only thing that approaching that was from Peter:
"But, this is something that belongs in *consuming* protocols, not in
this document. At most, this document can suggest that applications
incorporate support for such meta-metadata."But that is not language, and
Peter goes on to say:" Given that there are lots of existing applications /
consuming protocols
of RFC 3066 that do *not* do this, and given that adding text of this
sort isn't likely going to change them, I wouldn't make it a priority.
"Which I agree with. So I see "no action" as the correct
resolution.‎Mark----- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 07, 2005 23:25
Subject: [Ltru] [psg.com #1058] Referencing the tagging scheme

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 15:06:02 -0700

Hi -

> From: "Mark Davis" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Friday, July 08, 2005 2:55 PM
> Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme
>
> resolution.?Mark
...

By "no action" do you mean
   (a) keep the ticket open, rather than rejecting it (its current status)
   (b) not adopt the proposed change (in any of the various flavours that
       appeared in the discussion) => mark the ticket "rejected"
?

Randy, ltru co-chair

---

From: "Debbie Garside" <[email-masked]>
Date: Fri, 8 Jul 2005 23:34:46 +0100

Just to clarify as some people seem to have missed it... this is a copy of
the proposed text in my initial post:

“Implementers MAY reference this scheme within the language tag itself using
the following syntax:

Language-Tag (Scheme_RFC_3066_bis) = ..."

Which was then changed to:

Language-Tag[RFC****]=...

And further suggestions included:

Language-Tag-RFC****=...

One final word on this:

Mark wrote:
> Peter goes on to say:" Given that there are lots of existing applications
> / consuming protocols of RFC 3066 that do *not* do this, and given that 
> adding text of this sort isn't likely going to change them, I wouldn't 
> make it a priority.

Personally, I like to see new precedents being set... it's called progress I
believe... ;-)

(no comments required)

Regards

Debbie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mark Davis
> Sent: 08 July 2005 22:55
> To: Randy Presuhn; [email-masked]

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 8 Jul 2005 17:05:58 -0700

Mark it as rejected.

‎Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 17:13:49 -0700

Hi -

> Sent: Friday, July 08, 2005 5:05 PM

...

Happened nearly five hours ago.

Randy