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

From: "Addison Phillips" <[email-masked]>
Date: Tue, 21 Jun 2005 17:08:16 -0700

Playing additional catch-up.

Comments inter-linearly below.

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月20日 18:17
> To: Addison Phillips; Randy Presuhn; LTRU Working Group
> Subject: Re: [Ltru] Can we live with #944 as in draft -05?
> 
> 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

[Addison Phillips] deleted a bunch of text...

> 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.
[Addison Phillips] 

Added this text verbatim in place of the existing text.

> 
> > 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.]
[Addison Phillips] 

This is a different case that is worth pointing out. The other text focuses on limitations where it is possible to document as specific size limitation. In this case, the limitation is a by-product of other header items and is a variable size and may be quite large. This is distinct from the previous text which strongly suggests specific enumerated sizes and places the burden on the protocol or specification (here the burden is on implementations to support the largest possible tag). In any case, to make this text clearer, I changed it to:

<t>Some specifications are space constrained but do not have a fixed length limitation. 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. For example, <xref target="RFC2231">[RFC 2231]</xref>  has no explicit length limitation: the length available for the language tag is constrained by the length of other header components (such as the charset's name) coupled with the 76 character limit in <xref target="RFC2047">[RFC 2047]</xref>. Thus the "limit" might be 50 or more characters, but it could potentially be quite small.</t>
> 
> 
> >   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.]
> 
[Addison Phillips] 

Changed to:

In practice, most tags do not require more than a few subtags and will not approach reasonably sized buffer limitations.
> 
> ‎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?
> 
> 
> 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
> 

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

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 21 Jun 2005 17:30:59 -0700

I'm happy with it after those changes. Thanks

‎Mark

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "Mark Davis" <[email-masked]>; "Randy Presuhn"
<[email-masked]>; "LTRU Working Group" <[email-masked]>
Sent: Tuesday, June 21, 2005 17:08
Subject: RE: [Ltru] Can we live with #944 as in draft -05?

> This is a different case that is worth pointing out. The other text
focuses on limitations where it is possible to document as specific size
limitation. In this case, the limitation is a by-product of other header
items and is a variable size and may be quite large. This is distinct from
the previous text which strongly suggests specific enumerated sizes and
places the burden on the protocol or specification (here the burden is on
implementations to support the largest possible tag). In any case, to make
this text clearer, I changed it to:
>
> <t>Some specifications are space constrained but do not have a fixed
length limitation. 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. For
example, <xref target="RFC2231">[RFC 2231]</xref>  has no explicit length
limitation: the length available for the language tag is constrained by the
length of other header components (such as the charset's name) coupled with
the 76 character limit in <xref target="RFC2047">[RFC 2047]</xref>. Thus the
"limit" might be 50 or more characters, but it could potentially be quite
small.</t>
> In practice, most tags do not require more than a few subtags and will not
approach reasonably sized buffer limitations.