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

From: "Addison Phillips" <[email-masked]>
Date: Wed, 1 Jun 2005 11:22:05 -0700

Done.

I think that we should consider adding some material on length limitations and processing to the matching draft, although this doesn't affect the matching draft per-se as it sits.

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: mercredi 1 juin 2005 10:47
> To: LTRU Working Group
> Subject: Re: [Ltru] [psg.com #944] MAY a conformant implementation
> imposelength constraints?
> 
> 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?
> >
> > See: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-
> 03.html#length
> ...
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> 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: "Addison Phillips" <[email-masked]>
Date: Wed, 1 Jun 2005 12:04:15 -0700

No, this is extensions, which are separately defined. This sentence was added as part of a previous comment about denial of service attacks on registries in general. 

Addison

Addison P. Phillips

> From: McDonald, Ira [mailto:[email-masked]]
> Sent: mercredi 1 juin 2005 12:00
> To: Addison Phillips; McDonald, Ira; Doug Ewell; LTRU Working Group
> Subject: RE: [Ltru] Re: [psg.com #944] MAY a conformant implementation
> Hi,
> I agree with Randy's proposed tightening of the length section.
> 
> In the security section, I'm not sure what is meant by the last
> sentence:
> 
> "Although the specification of valid subtags for an extension MUST be
> available over the Internet, implementations SHOULD NOT mechanically
> depend
> on it being always accessible, to prevent denial-of-service attacks."
> 
> Is that 'specification' the IANA Language Subtag Registry?  If so, we
> should
> say that explicitly.  If not, we should be clearer.
> 
> 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]
> 
> > From: Addison Phillips [mailto:[email-masked]]
> > Sent: Wednesday, June 01, 2005 12:57 PM
> > To: Addison Phillips; McDonald, Ira; Doug Ewell; LTRU Working Group
> > Subject: RE: [Ltru] Re: [psg.com #944] MAY a conformant implementation
> > 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.htm
> > l#security
> >
> >
> > Addison
> >
> > Addison P. Phillips
> > > Behalf Of Addison Phillips
> > > Sent: mercredi 1 juin 2005 09:37
> > > To: McDonald, Ira; Doug Ewell; LTRU Working Group
> > > 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
> > > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On
> > > > Behalf Of McDonald, Ira
> > > > Sent: mercredi 1 juin 2005 08:51
> > > > To: 'Doug Ewell'; LTRU Working Group
> > 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]
> > > >
> > > > > 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/
> > > > >
> > > > >
> > > > >

---

From: "Peter Constable" <[email-masked]>
Date: Wed, 1 Jun 2005 21:33:47 -0700

> Behalf Of Frank Ellermann

> > The recommended buffer limit of 64 is long enough to take
> > three extlangs (62 characters up from my example of 58).
> 
> If Peter can live with that it's certainly better than five.

I'd expect we could get by with a limit of three. 

Perhaps that would give impetus to the maintainers of 639-3 to use care
in reanalyzing existing macrolanguage-individual language cases. There
*will* likely be cases in which an individual language in 639-3 is
reanalyzed as being a macrolanguage encompassing two or more individual
languages, but hopefully they will take care to do that only after there
has been a good sociolinguistic assessment, decreasing the likelihood of
a further splitting of the same group later on. Not that I expect they'd
be cavalier about how they maintain things, but it doesn't hurt to
provide motivation

Peter Constable