Subject: RE: [Ltru] Re: Confusing conformance language

From: "Addison Phillips" <[email-masked]>
Date: Thu, 9 Jun 2005 12:01:19 -0700

Okay. Done.

NB> I have rewritten Section 2.1.1 some more and those changes went along for the ride. If you're interesting in issue #944, you should go read that section again and send comments (some innovations were gleaned from the thread with Frank).

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: 2005?6?9? 11:43
> To: [email-masked]
> Subject: Re: [Ltru] Re: Confusing conformance language
> 
> Hi -
> 
> > From: "Addison Phillips" <[email-masked]>
> > To: "Frank Ellermann" <[email-masked]>; <[email-masked]>
> > Sent: Thursday, June 09, 2005 10:36 AM
> > Subject: RE: [Ltru] Re: Confusing conformance language
> ...
> > All of the normative language is now normalized in the editor's copy.
> ...
> 
> Since we're oh-so-close to being ready for working group last call,
> please submit it as an i-d.  The secretariat has been quick to get
> things through, and we have lots of integers left.  :-)
> 
> 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: Frank Ellermann <[email-masked]>
Date: Thu, 09 Jun 2005 22:25:50 +0200

Addison Phillips wrote:

> I have rewritten Section 2.1.1 some more and those changes
> went along for the ride. If you're interesting in issue #944,
> you should go read that section again and send comments

Not new, but reading it again it still tickles me:  You say...

| a combined total length of up to six characters, much larger
| registered tags were not only possible but were actually
| registered.

...if this "much longer" stands for "almost 67% longer" it's
true, but OTOH ten characters is not _that_ long, if it's the
worst registered 3066bis tag.

Here's a "normative" typo:

| For example, see [RFC 2231] [23].  This protocol has no
| explicit length limitation:

In fact it is in part about bypassing some length limitations
and introducing I18N in MIME parameters.  In its second part it
is about more I18N (= language tags) in MIME encoded words.

| the language tag's length is limited by the length of other
| header components (such as the charset's name) coupled with
| the 78 character limit in [RFC 2822]

NAK, the relevant limit for encoded words isn't the SHOULD "78"
in RfC 2822, it is the "76" in RfC 2047:

| An 'encoded-word' may not be more than 75 characters long,
| including 'charset', 'encoding', 'encoded-text', and
| delimiters.  If it is desirable to encode more text than will
| fit in an 'encoded-word' of 75 characters, multiple
| 'encoded-word's (separated by CRLF SPACE) may be used.

| While there is no limit to the length of a multiple-line
| header field, each line of a header field that contains one
| or more 'encoded-word's is limited to 76 characters.

You could also say "75" with a reference to [RFC2047].  Please
do not mention RfC 2822 and its SHOULD "78", this is another
story, and it's unrelated to our "most perverse tag" problem.

| Thus the "limit" might be 60 or more characters, but it could
| potentially be quite small.

 =?utf-8*?B?9L+/vw==?=
1234567890123456789012 (22)

The worst case for UTF-8 is 4 bytes F4 BF BF BF (u+10FFFF).
I'm not sure about the B64 rules, but IIRC splitting is evil,
and so we get 8 bytes 9L+/vw==.

Total length for the worst case from SP up to ?= therefore 22,
76-22=54.  For many Q-encoded US-ASCII characters it's only
one byte resulting in an absolute _maximum_ of 76-15 = 61:

 =?utf-8*?Q?3?=
123456789012345 (15)

And for the worst Q-encoded case it is 76-26=50.

 =?utf-8*?Q?=F4=BF=BF=BF?=
12345678901234567890123456 (26)

Now that's a nice number needing no explicit justification, you
could say:                  vv
  Thus the "limit" might be 50 or more characters, but it could
  potentially be quite small
                            Bye, Frank