Subject: RE: [Ltru] Tag perversity text revised... (#944)

From: "Addison Phillips" <[email-masked]>
Date: Tue, 7 Jun 2005 19:01:56 -0700

The MUST can remain a MUST: I had the same reaction to John Cowan's suggestion the first time, but then thought about it. Here's the distinction: this is an instruction to users selecting tags. It is an instance of "tag content wisely". Admittedly, we could wrap the MUST in a SHOULD, or at least an implied SHOULD:

--
Users or applications who wish to avoid problems with applications or protocols that truncate tags or have limited storage SHOULD avoid adding subtags that add no distinguishing value and MUST follow fields in the registry (such as Prefix and Suppress-Script) that limit subtag composition. See Section 4.1 (Choice of Language Tag).
--

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: Mark Davis [mailto:[email-masked]]
> Sent: 2005年6月7日 18:37
> To: Mark Davis; Addison Phillips; LTRU Working Group
> Subject: Re: [Ltru] Tag perversity text revised... (#944)
> 
> I take back part of what I said. The Prefix is only required for extlang;
> it
> is (correctly) a SHOULD for variants. So we should mention both Prefix and
> Suppress-Script, but we still have to change the MUST to a SHOULD. Thus
> the
> correction should be:
> 
> >    value and MUST follow fields in the registry (such as Prefix and
> >    Suppress-Script) that limit subtag composition.  See Section 4.1.
> 
> =>
> 
> >    value and SHOULD follow fields in the registry (such as Prefix with
> variants and
> >    Suppress-Script) that limit subtag composition.  See Section 4.1.
> 
> ‎Mark
> 
> ----- Original Message -----
> From: "Mark Davis" <[email-masked]>
> To: "Addison Phillips" <[email-masked]>; "LTRU Working Group"
> <[email-masked]>
> Sent: Tuesday, June 07, 2005 18:27
> Subject: Re: [Ltru] Tag perversity text revised... (#944)
> 
> 
> some corrections.
> 
> ‎Mark
> 
> ----- Original Message -----
> From: "Addison Phillips" <[email-masked]>
> To: "Addison Phillips" <[email-masked]>; "Mark Davis"
> <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, June 07, 2005 13:48
> Subject: RE: [Ltru] Tag perversity text revised... (#944)
> 
> 
> > Results of all the suggested changes (I used 42 this time).
> >
> > ~Addison
> >
> > --
> > 2.1.1  Length Considerations
> >
> >    RFC 3066 [23] did not provide for an upper limit on the size of
> >    language tags.
> 
> > While the largest tag that could be generated from
> >    language and region codes defined under RFC 3066 could not exceed six
> >    characters in length, much larger registered tags were not only
> >    possible but were actually registered.
> 
> => While the largest tag that could be generated under RFC 3066 from
> language and region codes alone could not exceed six characters in length,
> much larger registered tags could be and were registered, and private use
> tags could be arbitrarily long.
> [forgot private use]
> 
> >
> >    The ABNF and other guidelines in this document also do not impose a
> >    fixed upper limit on the number of subtags in a Language Tag (and
> >    thus the upper bound on the size of a tag) and it is possible to
> 
> 
> >    envision quite long and complex subtag sequences.  The upper bound on
> >    generative subtag combinations has expanded and, depending on the
> >    specific language, may require more characters to form a complete
> >    tag.
> 
> 
> => generate quite long and complex subtag sequences. Depending on the
> specific language, it may require more characters to form a complete tag.
> [there is no upper bound on generative subtag combinations.]
> 
> >
> >    In practice, most tags will not require substantially more
> >    characters.  This is partly because additional granularity in tags
> >    seldom adds useful distinguishing information and because longer,
> >    more granular tags interfere with the meaning, understanding, and
> >    processing of language tags.  The 'Prefix' and 'Suppress-Script'
> >    fields in the registry (see Section 3.1) limit the way in which
> >    subtags may be combined to form meaningful, valid tags.  For example,
> >    variant subtags SHOULD be used only with the  prefix specified in the
> >    registry.
> >
> >    Some applications and protocols must allocate fixed buffer sizes or
> >    otherwise limit the length of a language tag in a particular
> >    application.  A conformant implementation or specification MAY refuse
> >    to support the storage of language tags which exceed a specified
> >    length.  For an example, see [RFC 2231] [22].  Any such limitation
> >    SHOULD be clearly documented, and such documentation SHOULD include
> >    the disposition of any longer tags (for example, whether an error
> >    value is generated or the language tag is truncated).  This limit
> >    SHOULD be at least 42 characters in length.  If truncation is
> >    permitted it MUST NOT permit a subtag to be divided.  A protocol that
> 
> => permitted it MUST NOT permit a subtag to be divided, nor result in an
> invalid tag. A protocol that
> [this is to handle the trailing singleton]
> 
> >    allows tags to be truncated at an arbitrary limit, without giving any
> >    indication of what that limit is, has the potential for causing harm
> >    by changing the meaning of tags in substantial ways.
> 
> > Here is how the
> >    42-character length of the longest generated tag is derived:
> >
> >    language      = 3
> >    extlang1      = 4 (each subsequent subtag includes '-')
> >    extlang2      = 4 (unlikely: needs prefix="language-extlang1")
> >    extlang3      = 4 (extremely unlikely)
> >    script        = 5 (must not be suppressed)
> >    region        = 4 (UN M.49; ISO 3166 requires 3)
> >    variant1      = 9 (must have language as a prefix)
> >    variant2      = 9 (must have language-variant1 as a prefix)
> >
> >    total         = 42 characters
> >
> >              Figure 2: Derivation of the Limit on Tag Length
> 
> [delete above diagram. not needed]
> 
> >
> >    Since language tags may be truncated by an application or protocol
> >    that limits tag sizes, when choosing language tags users and
> >    applications SHOULD avoid adding subtags that add no distinguishing
> 
> >    value and MUST follow fields in the registry (such as Prefix and
> >    Suppress-Script) that limit subtag composition.  See Section 4.1.
> 
> => value and SHOULD follow the Suppress-Script field in the registry.
> [we CANNOT say MUST since the requirements for  Suppress-Script are SHOULD.
> We don't HAVE to mention at all the Prefix, because conformance elsewhere
> requires it anyway!]
> 
> >
> >    Applications or protocols that must truncate a tag MUST do so by
> >    progressively removing subtags along with their preceding "-" from
> >    the right side of the language tag until the tag is short enough for
> >    the given buffer.  If the resulting tag ends with a single-character
> >    subtag, that subtag and its preceding "-" MUST also be removed.  For
> >    example, when shortening the subtag sequence "en-a-abc-x-private1-
> >    private2", the first truncation produces "en-a-abc-x-private1" and
> >    the second truncation produces "en-a-abc".
> > --
> >
> > Addison P. Phillips
> > Globalization Architect, Quest Software
> > Chair, W3C Internationalization Core Working Group
> >
> > Internationalization is not a feature.
> > It is an architecture.
> >
> >
> >
> 
> 
> 
> _______________________________________________
> 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: "Mark Davis" <[email-masked]>
Date: Wed, 8 Jun 2005 06:57:26 -0700

I disagree. MUST is compliance language. Instructions cannot use MUST if
they are just guidance to users who 'wish' something. And since the
instructions are NOT guaranteed to "avoid problems", that is even more the
case. The text should be:

=> Users or applications who wish to avoid problems with applications or
protocols that truncate tags or have limited storage should avoid adding
subtags that add no distinguishing value, and follow fields in the registry
(such as Prefix and Suppress-Script) that limit subtag composition. See
Section 4.1 (Choice of Language Tag).

‎Mark

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "Mark Davis" <[email-masked]>; "LTRU Working Group"
<[email-masked]>
Sent: Tuesday, June 07, 2005 19:01
Subject: RE: [Ltru] Tag perversity text revised... (#944)

> The MUST can remain a MUST: I had the same reaction to John Cowan's
suggestion the first time, but then thought about it. Here's the
distinction: this is an instruction to users selecting tags. It is an
instance of "tag content wisely". Admittedly, we could wrap the MUST in a
SHOULD, or at least an implied SHOULD:
>
>
> --
> Users or applications who wish to avoid problems with applications or
protocols that truncate tags or have limited storage SHOULD avoid adding
subtags that add no distinguishing value and MUST follow fields in the
registry (such as Prefix and Suppress-Script) that limit subtag composition.
See Section 4.1 (Choice of Language Tag).

---

From: Marion Gunn <[email-masked]>
Date: Wed, 08 Jun 2005 15:05:37 +0100

Perhaps better to drop MUST altogether, if it is still causing
confusion, and stick to the old ISO regular pairing of SHALL (compliance
language) and SHOULD (guidance language). 

Stylistically and in defence of the Queen's English, may we please have
the occasional 'having', 'truncating', 'following', 'adding' 'limiting',
so as to break up the rat-tat-tat of that repetitive 'that...' in
zillions of places such as msg below?:-)
mg

-- 

Marion Gunn * EGTeo (Estab.1991)
27 Páirc an Fhéithlinn, Baile an 
Bhóthair, Co. Átha Cliath, Éire.
* [email-masked] * [email-masked] *