Subject: RE: [Ltru] Re: [psg.com #944] MAY a conformant implementation imposelength constraints?

From: "Addison Phillips" <[email-masked]>
Date: Wed, 1 Jun 2005 09:57:01 -0700

See: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-03.html#length

And: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-03.html#security

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 Addison Phillips
> Sent: mercredi 1 juin 2005 09:37
> To: McDonald, Ira; Doug Ewell; LTRU Working Group
> Subject: RE: [Ltru] Re: [psg.com #944] MAY a conformant implementation
> imposelength constraints?
> 
> Okay, here's what I'm doing:
> 
> 1. I'm rewriting the security considerations section, since the text that
> says "the only consideration" is increasingly odd.
> 
> 2. I'm inserting a version of Randy's text. The problem with Randy's text
> is that it doesn't fully explain the problem (where the length can come
> from).
> 
> 3. WRT Ira's comments, RFC3066bis tags won't be that much longer for the
> reasons stated in Section 2.1.1 (Length Considerations): although there is
> no limit on the number of variants and so on, the recommended prefixes and
> other guidance in the registry means that useful tags will be limited, in
> general, to just four subtags plus private use. I am adding some text to
> Section 2.1.1 explaining this in detail (the gist of it is that the
> smallest buffer limit that will not be exceeded by a practical tag is 58
> bytes and a buffer limit of 64 is therefore advised and that
> implementations that are limited in this manner should truncate
> extensions).
> 
> 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 McDonald, Ira
> > Sent: mercredi 1 juin 2005 08:51
> > To: 'Doug Ewell'; LTRU Working Group
> > Subject: RE: [Ltru] Re: [psg.com #944] MAY a conformant implementation
> > impose length constraints?
> >
> > Hi,
> >
> > I support Randy's suggested update to Security Considerations too.
> >
> > I still think it would be good to specify a lower bound of length
> > for language tags that SHOULD be supported by conforming implementations.
> > Because in the RFC3066bis real-world language tags may very well be much
> > longer than the classic 'll-CC'.
> >
> > Cheers,
> > - Ira
> >
> > Ira McDonald (Musician / Software Architect)
> > Blue Roof Music / High North Inc
> > PO Box 221  Grand Marais, MI  49839
> > phone: +1-906-494-2434
> > email: [email-masked]
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On
> > > Behalf Of Doug Ewell
> > > Sent: Tuesday, May 31, 2005 11:50 PM
> > > To: LTRU Working Group
> > > Subject: [Ltru] Re: [psg.com #944] MAY a conformant implementation
> > > impose length constraints?
> > >
> > >
> > > Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:
> > >
> > > >> Won't work: Variants and private use subtags are not bounded in
> > > >> number. Neither can extension lengths be known in advance.
> > > >
> > > > Then I think we really need to add something like the
> > > following to the
> > > > security considerations section, as part of this issue's
> > > resolution /
> > > > rejection:
> > > >
> > > > Since there is no limit to the number of variant and private use
> > > > subtags, and consequently no limit on the possible length of a tag,
> > > > implementations need to guard against buffer overflow attacks.  See
> > > > section ## for details on tag truncation, which can occur as a
> > > > consequence of defenses against buffer overflow.
> > >
> > > Yes.  Excellent.
> > >
> > > --
> > > Doug Ewell
> > > Fullerton, California
> > > http://users.adelphia.net/~dewell/
> > >
> > >
> > >
> > > _______________________________________________
> > > 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: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Jun 2005 10:46:57 -0700

Hi -

> From: "Addison Phillips" <[email-masked]>
...
> Sent: Wednesday, June 01, 2005 9:57 AM
> Subject: RE: [Ltru] Re: [psg.com #944] MAY a conformant implementationimposelength constraints?
>
...

The current proposed text is most helpful.  However, as a technical
contributor, I'd like to tighten up this paragraph:

Longer tags are possible to envision. The longest practical tags (excluding
extensions) could consist of a sequence of up to 58 characters, as shown
below. Implementations which choose to implement a specific minimum buffer
length SHOULD choose a buffer that exceeds this size (64 characters is
suggested). Implementations that restrict storage should consider removing
extensions before processing. Here is how the most perverse tag is derived:

Suggestion:

(a) tighter conformance language

Longer tags are possible.  The longest practical tags (excluding extensions)
could have a length of up to 58 characters, as shown below.  Implementations
MUST be able to handle tags of this length without truncation.  Support for
tags of up to 64 characters is RECOMMENDED.  Implementations MAY support
longer tags.

(b) separate out text on removal of extensions and integrate it with
the truncation algorithm.  (Does this impact the matching draft?)

(c) New paragraph on longest practical tag:

Here is how the 58-character length of the longest practical tag
(excluding extensions) is derived:

Randy