Subject: RE: [Ltru] Tag perversity text revised... (#944)

From: "Addison Phillips" <[email-masked]>
Date: Wed, 8 Jun 2005 14:40:35 -0700

Frank's own email demonstrated that 42 doesn't break all email and MIME bodies :-). It is ugly, but it doesn't *always* break.

My concern about MUST on the length limitation is that there are existing specs and implementations with a variety of limitations. The magic number (no matter which you pick) will not be appropriate for all applications or protocols. At least some will be less and many will be close to 42.

Therefore I think it might be best to say something like:

---
When choosing a buffer limit, a length of at least 42 characters is RECOMMENDED. If the limit must be less, it SHOULD be as large as possible. A value less than 33 characters in length represents a considerable impediment to interoperability, since relatively common tags can approach or exceed this length.
---

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: 2005?6?7? 20:54
> To: 'John.Cowan'; Randy Presuhn
> Cc: [email-masked]
> Subject: RE: [Ltru] Tag perversity text revised... (#944)
> 
> +1
> 
> Despite Mark's protests, lower bound for conformance to _this_ spec
> has to be a MUST for length (and Frank's right that 33 is the magic
> number - breaking all email and MIME bodies is not acceptable).
> 
> And including the rationale for SHOULD of 63 (safest lower bound)
> is a good idea.  One of the best ISO specs is any later version
> of the C Language with the clause-by-clause companion rationale
> (also done in later POSIX specs), because the _meaning_ of those
> apparently arbitrary numbers and constraints is manifest.
> 
> Leaving out rationale is throwing away the value of a working group.
> 
> 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 John.Cowan
> > Sent: Tuesday, June 07, 2005 5:46 PM
> > To: Randy Presuhn
> > Cc: [email-masked]
> > Subject: Re: [Ltru] Tag perversity text revised... (#944)
> >
> >
> > Randy Presuhn scripsit:
> >
> > > >    value is generated or the language tag is truncated).
> > This limit
> > > >    SHOULD be at least 42 characters in length.  If truncation is
> > > ...
> > >
> > > SHOULD -> MUST, otherwise there is no lower bound to what can claim
> > > to be a conformant implementation.
> >
> > +1.  Otherwise I'm happy with Addison's latest.
> >
> > --
> > Do NOT stray from the path!             John Cowan
> > <[email-masked]>
> >         --Gandalf                       http://www.ccil.org/~cowan
> >
> > _______________________________________________
> > 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, 8 Jun 2005 21:31:43 -0700

Hi -

(as a technical contributor)

> From: "Addison Phillips" <[email-masked]>
...
> Cc: <[email-masked]>
> Sent: Wednesday, June 08, 2005 2:40 PM
...
> My concern about MUST on the length limitation is that there are existing specs
> and implementations with a variety of limitations. The magic number (no matter
> which you pick) will not be appropriate for all applications or protocols. At least
> some will be less and many will be close to 42.

Of course there are and will be apps and protocols that won't handle some
reasonable language tags.  The point is that we need to tell developers what
they must AT LEAST support if they want interoperability.  Yes, this may mean
that tag X will survive protocol Y intact but not protocol Z.  If we don't say
what MUST be done for conformance, then all bets are off, no matter what
we RECOMMEND.

> When choosing a buffer limit,

This phrase gets too close to specifying an implementation,
 rather than a requirement, in my opinion.

> a length of at least 42 characters is RECOMMENDED.
> If the limit must be less, it SHOULD be as large as possible.

This is remarkably toothless.  (I'm with Ira in not liking this "must")

> A value less than 33 characters in length represents a
> considerable impediment to interoperability, since relatively
> common tags can approach or exceed this length.
...

If something is "a considerable impediment to interoperability",
it's time to break out the "MUST NOT".

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 09 Jun 2005 15:17:25 +0200

Addison Phillips wrote:
 
> Frank's own email demonstrated that 42 doesn't break all
> email and MIME bodies :-)

You forgot to count:

 =?pc-multilingual-850+euro*lng-exa-exb-exc-Latn-830-variant8-variant8?Q?Ta?=
 =?pc-multilingual-850+euro*lng-exa-exb-exc-Latn-830-variant8-variant8?Q?g_?=
 =?pc-multilingual-850+euro*lng-exa-exb-exc-Latn-830-variant8-variant8?Q?pe?=
....5...10....5...20....5...30....5...40....5...50....5...60....5...70....567

77 was illegal.  And I didn't use any real Q-encoded =D5 Euro,
that would be 78.  Of course the charset is rather obscure, but
it's still what I use locally.

> it doesn't *always* break.

ACK.  There might be worse registered charset names, checking:

pc-multilingual-850+euro
JIS_C6229-1984-hand-add
csISO95JIS62291984handadd
ebcdic-international-500+euro
csEUCFixWidJapanese
Extended_UNIX_Code_Fixed_Width_for_Japanese

Now that must be a record, fortunately irrelevant for MIME ;-)