Subject: RE: [Ltru] Can we live with #944 as in draft -05?

From: "Addison Phillips" <[email-masked]>
Date: Mon, 20 Jun 2005 16:45:00 -0700

My contribution to the hum: I feel that this is resolved.

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 Randy Presuhn
> Sent: 2005?6?20? 16:39
> To: LTRU Working Group
> Subject: [Ltru] Can we live with #944 as in draft -05?
> 
> Hi -
> 
> I'd like to see whether we can close issue #944 regarding whether
> a conformant implementation can impose length constraints and what
> those constraints might be.  So I'd like to get a "hum" from the group:
> 
> Can you live with the resolution of this issue are reflected in
> http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-05.txt ?
> 
> As you may recall from the discussion, points of concern included
> whether the MUSTs and SHOULDs made sense,  whether the
> lengths given were meaningful, and whether the underlying rationale
> was sufficiently clear.
> 
> Randy, ltru co-chair
> 
> 
> 
> 
> _______________________________________________
> 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: [email-masked]
Date: Mon, 20 Jun 2005 17:49:15 -0700 (PDT)

Before I leave I would like to positively return your welcome: you should
correct the "ANBF" typo in 2.1.1. to "ABNF",... and most of the rest to
white. I first tried to read your text .. I am not an intelligent person
enough (cf. Part 8) to understand most (I ask who will be your reader) nor
to understand Randy's tickets. All this is too obscure, even for a troll.
F. Charles.

PS. We had a good meeting tonoght over our testing. If some are seriously
interested ... It will use JFC's x-tags, but unlimited size (actually less
than 9 bytes but comment separator "." within a subtag). If the lib is not
supporting it will respond error, so we know. Long subtags will tell the
version of the library.

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 20 Jun 2005 18:16:57 -0700

I think we are almost, but not quite there. This is not because of a
substantive difference in the numbers, but because the wording is not
correct.

>   Implementations MUST support a limit of at least 33 characters.  This
   limit includes at least one subtag of each non-extension, non-private
   use type.  When choosing a buffer limit, a length of at least 42
   characters is strongly RECOMMENDED.

[The wording here is odd. It feels like we are saying that Implementations
must support a limit, and that limit must be 33 characters. It is also, of
course, the case that I can do *whatever I want* to a language tag as a part
of processing. Suppose, for example, I am processing some text tagged with
en-US-foobar. In the course of processing, I remove anything that is
foobar-specific, so I change the tag to en-US. We can't phrase it in such a
way as to say that that perfectly reasonable option is non-conformant. Also,
we really don't want people to just blindly pick 42, and thus screw up
extensions, unless they need to truncate. And it doesn't distinguish the
cases where I have really no control over a protocol that I must use to
exchange a language tag. Thus I have a suggested revision:]

=> Language tags SHOULD NOT be truncated unless the meaning of the tag is
purposefully being changed, or unless the tag does not fit into a limited
buffer size specified by a protocol for storage or transmission. Protocols
that specify limited buffer sizes for language tags MUST allow for language
tags of up to 33 characters, and SHOULD allow for language tags of at least
42 characters. As truncation can change the semantic meaning of the tag, it
is RECOMMENDED that the user be warned of any truncation.

> In these cases,
   implementations SHOULD use the longest possible language tag.
   Warning the user of truncation, if necessary, is RECOMMENDED, as
   truncation can change the semantic meaning of the tag.

[This text from further down is now not necessary. It was unnecessarily
limiting anyway; it is not only those circumstances where language tags
should not be shortened.]

>   In practice, most tags do not require additional subtags or
   substantially more characters.

[This is from a bit higher up. Remove, since it is not necessary in context.
Also not really complete "more than what", "to do what"? The second sentence
of that paragraph is a better lead-in. If there were no further changes
necessary, we could live with this, but because some are, we should do
this.]

‎Mark

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group"
<[email-masked]>
Sent: Monday, June 20, 2005 16:45
Subject: RE: [Ltru] Can we live with #944 as in draft -05?

Addison

Addison P. Phillips