Subject: RE: [Ltru] [psg.com #944] MAY a conformant implementation impose lengthconstraints?

From: "Addison Phillips" <[email-masked]>
Date: Tue, 10 May 2005 09:04:55 -0700

<q>
A conformant implementation MAY refuse to support the storage of language tags which exceed a specified length. For an example, see [RFC 2231] (Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations," November 1997.)[22]. Any such limitation MUST 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). If truncation is permitted it SHOULD NOT permit a subtag to be divided.
</q>

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?5?13? 23:50
> To: LTRU Working Group
> Subject: [Ltru] [psg.com #944] MAY a conformant implementation impose
> lengthconstraints?
> 
> Hi -
> 
>  Comment #15 in message
>  http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html
>  asks whether an implementation that imposes length constraints
>  would still be considered conformant, and, if so, what constraints
>  would be permissible.
> 
> 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: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 May 2005 21:06:10 -0700

Hi -

(as a technical contributor)

> From: "Addison Phillips" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, May 10, 2005 9:04 AM
> Subject: RE: [Ltru] [psg.com #944] MAY a conformant implementation impose lengthconstraints?
>

> <q>
> A conformant implementation MAY refuse to support the storage of language
> tags which exceed a specified length. For an example, see [RFC 2231] (Freed,
> N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions:
> Character Sets, Languages, and Continuations," November 1997.)[22]. Any
> such limitation MUST 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). If truncation
> is permitted it SHOULD NOT permit a subtag to be divided.
> </q>
...

Thinking like an implementor, I'd find this of little help.  I don't see
how permitting truncation and permitting subtag division could possibly
help interoperability.

I'd be more comfortable with "If truncation is permitted, it MUST NOT permit a
subtag to be divided."

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 May 2005 06:03:28 +0200

Addison Phillips wrote:

> A conformant implementation MAY refuse to support the storage
> of language tags which exceed a specified length. For an
> example, see [RFC 2231] (Freed, N. and K. Moore, "MIME
> Parameter Value and Encoded Word Extensions: Character Sets,
> Languages, and Continuations," November 1997.)[22].

The real problem is 2231 in conjunction with 2047 encoded
words, the 2047 limit 76 is not mentioned in 2231.  Please
add RfC 2047.

While 2231 multiline-parameters are a pain they have almost
no length problems - in fact that's the idea of multiline
parameters, and any remaining limit 9?? (below 998) is no
real problem for LTRU.  BTW, 998 is documented in RfC 2045,
not in RfC 2231.

> Any such limitation MUST 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). If truncation is permitted
> it SHOULD NOT permit a subtag to be divided.

Please swap the MUST and the second SHOULD.  It SHOULD be
clearly documented (and we know that this is not the case
from our POV for 2231 + 2047), and any truncation MUST at
least syntactically make sense,
                               Bye, Frank