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

From: "Addison Phillips" <[email-masked]>
Date: Tue, 7 Jun 2005 13:30:03 -0700

The only thing I'd add to this is to change this:

<t>Since language tags longer than 42 characters may be truncated by an application or protocol that limits tag sizes, when choosing language tags... 

To this:

<t>Since language tags may be truncated by an application or protocol that limits tag sizes, when choosing language tags... 

The lack (or presence) of a rigid limit doesn't affect advice to users on choosing language tags that are succinct.

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日 13:20
> To: Addison Phillips; LTRU Working Group
> Subject: Re: [Ltru] Tag perversity text revised... (#944)
> 
> my comments below.
> 
> ‎Mark
> 
> ----- Original Message -----
> From: "Addison Phillips" <[email-masked]>
> To: "Mark Davis" <[email-masked]>; "LTRU Working Group"
> <[email-masked]>
> Sent: Tuesday, June 07, 2005 12:42
> Subject: RE: [Ltru] Tag perversity text revised... (#944)
> 
> 
> > Hi Mark,
> >
> > >
> > >
> > > I disagree strongly with this language, as I stated before. It appears
> > > that
> > > you didn't see my message of Monday, June 06, 2005 13:49. Please look
> at
> > > that.
> > [Addison Phillips]
> >
> > I missed that message, or at least the substance of it. You're
> suggesting
> that the truncation be by strict progressive removal from right, correct?
> Or
> should we attempt to enumerate progressively removing extensions first?
> 
> See my later message to John. I'm suggesting strictly removal from the
> right, plus any trailing singleton that would remain. Simple.
> 
> >
> > >
> > > >This limit SHOULD be at least 33 characters in length.
> > >
> > > I haven't heard anyone say why we shouldn't use 63 instead. (here and
> in
> > > other locations)
> > [Addison Phillips]
> >
> > The reason was given semi-obliquely by Frank and Ira: RFC 2047 headers
> (and other applications) can only contain a limited number of characters
> and
> 63 leaves no room for actual content. Thus it seems like an overly large
> value as a *required* minimum. Pointing out the 63 number makes a lot of
> sense, though.
> 
> Ah, I now understand. I still think there is no reason to not use 63;
> after
> all, it is a SHOULD, and if someone has reason for it to be shorter then
> they can make it so.
> 
> > >
> > > >Here is how the 33-character length of the longest generated tag is
> > > derived:
> > >
> > > This is incorrect.
> > > en-US-x-abcdefgh-abcdefgh-abcdefgh-abcdefgh-abcdefgh-abcdefgh-abcdefgh
> > > is a generated tag, and it is longer.
> > [Addison Phillips]
> >
> > The "longest generated tag" uses only registry entries and no private
> use
> values. It is not the longest tag. There is no "longest tag". There are
> merely different probabilities of a tag being of a specific length. Even
> really long potentially useful tags don't approach the 63 maximum:
> 
> Every use of "generate" that I see in the text (before your changes)
> applies
> to "generated according to this specification", which includes private use
> and extension. Nothing supports exclusion of the latter. And "generated"
> is
> a bad term to use if you really mean "generated with the exclusion of
> private use and extension subtags". If we really need a single term for
> the
> later we should define a new term (but I'm not convinced we do).
> 
> >
> > zh-min-nan-Latn-CN-xiang-x-wadegile (35 characters and xiang is
> irresponsible)
> > >
> > > Moreover, I don't see the purpose of having this analysis be present
> in
> > > the
> > > specification itself. We should delete "Here is...Figure 2: Derivation
> of
> > > the Longest Generated Tag"
> > >
> > > And should delete also "Note: The longest tag...Figure 3: Derivation
> of
> > > the
> > > Longest Tag". I disagree that this is the longest practical tag --
> what
> is
> > > "practical" is an extremely gray area -- and there is no reason for us
> to
> > > go
> > > into the analysis.
> > [Addison Phillips]
> >
> > Agreed. It is wasteful to illustrate this in this manner.
> >
> > Addison
> >
> >
> >
> >
> 

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

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 7 Jun 2005 14:02:57 -0700

agreed

‎Mark

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

> <t>Since language tags longer than 42 characters may be truncated by an
application or protocol that limits tag sizes, when choosing language
tags...
>
> To this:
>
> <t>Since language tags may be truncated by an application or protocol that
limits tag sizes, when choosing language tags...
>
> The lack (or presence) of a rigid limit doesn't affect advice to users on
choosing language tags that are succinct.