Subject: [Ltru] The most perverse tag

From: Frank Ellermann <[email-masked]>
Date: Sat, 04 Jun 2005 12:52:01 +0200

Hi, the most perverse 62 example in -03 is nice, but I'm a bit
confused by the accompanying MUST - RECOMMENDED - MAY text:

| 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.

The MAY is obvious, that could be deleted.  The RECOMMENDED is
fine.  But what's the purpose of the MUST ?  We know that it's
impossible for an encoded word in a MIME header field line.

" =?c*t?e?x?=" -> 9 " =?*?e??=" + 62 "t" = 71.  That leaves 5
for the charset "c" + the text "x".  Or in the case of "utf-8"
precisely zero.  RfC 2047 (still missing in the references and
near the 2231 pointer) says encoded-text = 1*<stuff> and does
not like encoded empty strings.
                                 Bye, Frank

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

---

From: "Addison Phillips" <[email-masked]>
Date: Sat, 4 Jun 2005 09:45:34 -0700

SHOULD makes more sense to me. I doubt there will ever be tags found in the wild that are 62 characters long (extensions excluded) anyway. Truncation of ones that approach this length are unlikely to spoil the meaning, since a tag with ten levels of distinction (!!) is way more precise than an Internet header can really enumerate accurately in the first place. 

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 Frank Ellermann
> Sent: 2005?6?4? 3:52
> To: [email-masked]
> Subject: [Ltru] The most perverse tag
>

---

From: "Addison Phillips" <[email-masked]>
Date: Sun, 5 Jun 2005 09:53:07 -0700

26 is the "useful limit" for 3066bis.
34 is the "useful limit" for 3066ter (two extlangs)

There are some interesting lacunae in the longest tag sweepstakes. Extlangs, as shown in the 62 character example, will never be assigned to a registered language subtag, since presumably they are assigned by ISO 639-3. As a result, the longest case is an alpha3 followed by two extlangs (for 11 characters). The next longest case is an alphanum8 registered language subtag (59 characters) making that the longest legal-and-(un)likely 3066bis tag.

The 24 example below avoids variant. One variant makes the tag 33 characters. It would be more graceful if it were 32, but it looks like 36 is the next "grace point" for tag buffer allocation.

Addison

Addison P. Phillips

> Sent: 2005?6?5? 9:20
> Subject: [Ltru] Re: The most perverse tag
> 
> Randy Presuhn wrote:
> 
> > what IS the minimum beyond which conformant implementations
> > MUST NOT truncate?
> 
> If you tolerate truncations you get three interesting limits
> in addition to the RECOMMENDED 64:
> 
> 15 = only the language, lng-exa-exb-exc
> 20 = at least a script, lng-exa-exb-exc-Latn
> 24 = at least a region, lng-exa-exb-exc-Latn-830
> 
> The latter is still within the already documented limit 26 for
> lngeight-Latn-830-variant8
> 
> This 26 should be good enough for an 2231 / 2047 encoded word:
>  =?pc-multilingual-850+euro*x?B?y?=
> ....5...10...,5...20....5...30....5
> 
> 76 -26 -35 +2 = 17 for x has some leeway for worse charsets,
> 
>                          Bye, Frank
> 
> 
>

---

From: "Addison Phillips" <[email-masked]>
Date: Sun, 5 Jun 2005 18:46:20 -0700

63 is fine.

Let's face it: a sixty-three character tag is actually impossible until 3066ter is written and even then, by the rules written into 3066bis, it won't be valid unless some spectacularly weird registrations take place.

To wit: the perverse tag represents a variation of a variation (which means that the variant includes the variant in its recommended prefix) of a language enclosed by a macro language enclosed by a macro language enclosed by a macro language (Pant! Pant! Count the items...). And this language must be written in at least two scripts customarily. Oh, almost forgot, you need to have two private distinctions on top of that. And a *numeric* region code (a continent or an odd-body like Isle of Man).

I am constantly astounded by the range of human expression, etc. But this one limit that really makes no sense to approach.

While I'm sure that there will be tags created that exceed this limit at some point, I'm also pretty sure that the language will be fictional (like my favorite RFC 3066 test tag tlh-AQ).

Addison

Addison P. Phillips

> Behalf Of Mark Davis
> Sent: 2005年6月5日 15:20
> To: LTRU Working Group; Frank Ellermann
> Subject: Re: [Ltru] Re: The most perverse tag
> 
> I have no problem with a recommended minimum of 63.
> 
> ‎Mark
> 
> ----- Original Message -----
> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, June 05, 2005 14:02
> > McDonald, Ira wrote:
> > > IPP/1.0 (RFC 2565/2566) and IPP/1.1 (RFC 2910/2911)
> > > - defines the over-the-wire datatype 'naturalLanguage'
> > >   (maximum length 63 octets)
> >
> > > Job Monitoring MIB (RFC 2707)
> > > - defines the textual convention 'JmNaturalLanguageTagTC'
> > >   (maximum length 63 octets)
> >
> > We could RECOOMMEND 63 instead of 64.  And keep "MAYbe more,
> > maybe not" separate as it is in -03, and as Doug wants it.
> >
> > With an old magic number 63 we don't need a new 64 when what
> > we really want is "at least 62" ;-)
> >
> >
> >

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 5 Jun 2005 19:33:40 -0700

I have no problem with changing the recommended lower limit from 64 to
63.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/