Subject: [Ltru] Proposed note on well-formed but not valid language tags

From: John Cowan <[email-masked]>
Date: Tue, 15 Jan 2008 13:17:07 -0500

I propose this language for inclusion as a note in the 4646bis section
on well-formed and valid tags, because I have found myself typing it,
or something like it, several times lately:

	Well-formed but not valid language tags are not like well-formed
	but not valid XML.  They are much more like unassigned Unicode
	characters.  That is, they should never be used by anyone for any
	purpose, because at any time they may be assigned an official
	meaning that will probably conflict with any user-assigned
	meaning.

-- 
John Cowan  [email-masked]   http://www.ccil.org/~cowan
O beautiful for patriot's dream that sees beyond the years
Thine alabaster cities gleam undimmed by human tears!
America! America!  God mend thine every flaw,
Confirm thy soul in self-control, thy liberty in law!
        -- one of the verses not usually taught in U.S. schools

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

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 15 Jan 2008 10:24:47 -0800

agreed, with one minor wording change.

>        meaning that will probably conflict with any user-assigned

that would conflict with the user-assigned
[we only need one "may" in the sentence.]

>
>        meaning.
>
> --
> John Cowan  [email-masked]   http://www.ccil.org/~cowan<http://www.ccil.org/%7Ecowan>

-- 
Mark

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 15 Jan 2008 20:37:55 -0000

> 	meaning that will probably conflict with any user-assigned

I really don't like language that refers the end user to standards that they
may be unfamiliar with and that have, as such, nothing to do with language
encoding.

How about:
---

Language tags may be well formed in terms of syntax but not valid in terms
of content.  Users SHOULD NOT assign and use their own subtags, other than
private use codes as designated within the underlying standards, as they may
find an as yet unassigned subtag may be officially assigned at a later date
with a different meaning.

---

Best regards

Debbie

> -----Original Message-----
> From: John Cowan [mailto:[email-masked]]
> Sent: 15 January 2008 18:17
> To: [email-masked]
> Subject: [Ltru] Proposed note on well-formed but not valid
> language tags
>
> I propose this language for inclusion as a note in the
> 4646bis section on well-formed and valid tags, because I have
> found myself typing it, or something like it, several times lately:
>
> America! America!  God mend thine every flaw, Confirm thy
> soul in self-control, thy liberty in law!

---

From: [email-masked]
Date: Tue, 15 Jan 2008 12:40:49 -0800

>From my perspective, Debbie's suggestion would be more clear to your 
average end user of the RFC.

Karen Broome

"Debbie Garside" <[email-masked]> wrote on 01/15/2008 12:37:55

---

From: Addison Phillips <[email-masked]>
Date: Tue, 15 Jan 2008 13:38:31 -0800

Why not use MUST NOT instead of SHOULD NOT?

MUST NOT does not prevent people from doing the wrong thing nor does it 
prevent well-formed-by-not-validating implementations from being 
written. But it does say, clearly, not to use unregistered junk. SHOULD 
NOT means "don't unless you have a really good reason to". I cannot 
think of a single case where there would be a really good reason to (not 
addressed by private-use codes).

Note: to either proposed text, one might note that a validating 
processor would be within its rights to reject any such tag, making it 
inoperable.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

[email-masked] wrote:
> "Debbie Garside" <[email-masked]> wrote on 01/15/2008 
> 12:37:55 PM:
> 
>  > John wrote:
>  >
> ------------------------------------------------------------------------
>

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 15 Jan 2008 14:15:01 -0800

Even better. And since conformance to the spec requires it, MUST NOT is the
right choice. And I would make your note stronger:

A validating processor will reject any such tag, making it inoperable.

---

From: John Cowan <[email-masked]>
Date: Tue, 15 Jan 2008 19:22:24 -0500

> Why not use MUST NOT instead of SHOULD NOT?

I had meant this to be just a note, but if it's going to have
RFC 2119 verbs in it, then MUST NOT is certainly correct.

-- 
John Cowan    http://www.ccil.org/~cowan   <[email-masked]>
    "Any legal document draws most of its meaning from context.  A telegram
    that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in
    5-bit Baudot code plus appropriate headers) is as good a legal document
    as any, even sans digital signature." --me

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 16 Jan 2008 09:15:57 +0100

On Tue, Jan 15, 2008 at 02:15:01PM -0800,
 Mark Davis <[email-masked]> wrote 
 a message of 203 lines which said:

> A validating processor will reject any such tag, 

It seems a very dangerous idea. Since what is valid for one processor
is invalid for another (because they do not use the same version of
the LSR, remember that a processor is not forced to fetch the LSR each
time it valids) the robustness principle should mean that even
validating processors should think twice before rejecting a tag.

If the entire purpose of the processor is to validate, for instance,
before a publication, yes, I understand the rejection. But in general,
it is dangerous.

Asking people to *not* produce well-formed-but-invalid tags is one
thing. Asking consumers to reject them is another, much more
questionable.

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 16 Jan 2008 09:49:33 +0100

Debbie Garside wrote:
 
> I really don't like language that refers the end user to
> standards that they may be unfamiliar with and that have,
> as such, nothing to do with language encoding.

Strong ACK.  For obvious reasons we use some ISO standards
here.  But we do NOT need TUS details, XML, and what else. 

 Frank

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 16 Jan 2008 10:00:29 -0000

So do you agree with the following?
 
of content. Users MUST NOT assign and use their own subtags, other than

Debbie

  _____  

From: Mark Davis [mailto:[email-masked]] 
Sent: 15 January 2008 22:15
To: Addison Phillips
Cc: [email-masked]; [email-masked]
Subject: Re: [Ltru] Proposed note on well-formed but not valid language tags

Addison

[email-masked] wrote:
>  > > From: John Cowan [mailto: [email-masked]]
<http://www.ccil.org/%7Ecowan> 

-- 
Mark

---

From: Addison Phillips <[email-masked]>
Date: Wed, 16 Jan 2008 08:25:01 -0800

I agree with the sentiment but think some editing is in order. Notably, 
the private use codes you mention are in the registry, while what I had 
in mind were -x- type private use sequences. Also: I think we have 
similar text elsewhere in the document and would like to look at the 
whole and see what makes the most sense.

Addison

Debbie Garside wrote:
> Language tags may be well formed in terms of syntax but not valid in 
> terms of content. Users MUST NOT assign and use their own subtags, other 
> than private use codes as designated within the underlying standards, as 
> they may find an as yet unassigned subtag may be officially assigned at 
> a later date with a different meaning.
> 
>  
> 
> Debbie
> 
> 
>     *From:* Mark Davis [mailto:[email-masked]]
>     *Sent:* 15 January 2008 22:15
>     *To:* Addison Phillips
>     *Cc:* [email-masked]; [email-masked]
>     *Subject:* Re: [Ltru] Proposed note on well-formed but not valid
>     language tags
> 
>     Even better. And since conformance to the spec requires it, MUST NOT
>     is the right choice. And I would make your note stronger:
> 
>     On Jan 15, 2008 1:38 PM, Addison Phillips <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         [email-masked] <mailto:[email-masked]> wrote:
>          >
>          > "Debbie Garside" <[email-masked]
>         <mailto:[email-masked]>> wrote on 01/15/2008
>          > 12:37:55 PM:
>          >
>          >  > John wrote:
>          >  >
>         standards
>          > that they
>          >  > may be unfamiliar with and that have, as such, nothing to
>         do with
>          > language
>          >  > encoding.
>          >  >
>          >  > How about:
>          >  > ---
>          >  >
>          >  > Language tags may be well formed in terms of syntax but
>         not valid in
>          > terms
>          >  > of content.  Users SHOULD NOT assign and use their own
>         subtags, other
>          > than
>          >  > private use codes as designated within the underlying
>         standards, as
>          > they may
>          >  > find an as yet unassigned subtag may be officially
>         assigned at a
>          > later date
>          >  > > From: John Cowan [mailto: [email-masked]
>         <mailto:[email-masked]>]
>          >  > > To: [email-masked] <mailto:[email-masked]>
>          >  > > John Cowan  [email-masked] <mailto:[email-masked]>  
>         http://www.ccil.org/~cowan <http://www.ccil.org/%7Ecowan>
>          >  > > [email-masked] <mailto:[email-masked]>
>          >  > [email-masked] <mailto:[email-masked]>
>          > [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: LB <[email-masked]>
Date: Fri, 18 Jan 2008 14:36:55 +0100

I do not know why this mail did not make it to the list. Sorry.
LB

---------- Forwarded message ----------
From: LB <[email-masked]>
Date: Thu, 17 Jan 2008 18:45:19 +0100
Subject: Re: [Ltru] Proposed note on well-formed but not valid language tags
To: "[email-masked]" <[email-masked]>

> average end user of the RFC.

Respectfully, there is no "RFC end user", only "RFC users".
I cannot make my mind about this important wording. I need Randy to answer
first the question he made me to prompt. If RFC 4646 is not only for the
IANA LSR the wording should take it into account. Methink straight ISO 639-3
(and ISO 639-6) code elements would be simpler for those Karen refers to.

--
LB

Karen Broome

-- 
LB

-- 
LB