Subject: [Ltru] Re: The most perverse tag

From: "Doug Ewell" <[email-masked]>
Date: Sat, 4 Jun 2005 10:44:22 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

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

He's right.  We might be within our bounds to require this for new
applications, but we can't retrofit it onto existing applications that
don't already support it.

The rules for intelligent truncation would probably apply here (do not
chop a subtag in half, consider removing extensions before other things,
publicly state the limit to which truncation occurs).

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

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 4 Jun 2005 10:50:56 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> The MAY is obvious, that could be deleted.

Please do not delete this.  It is a useful reminder to implementers that
they need not limit themselves to the minimum requirement.  Removing a
five-word sentence will not shorten a 19,000-word draft in any
significant way.

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 4 Jun 2005 17:18:31 -0700

Hi -

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Saturday, June 04, 2005 10:44 AM
> Subject: [Ltru] Re: The most perverse tag
>

> publicly state the limit to which truncation occurs).
...

If the current number is not acceptable, what IS the minimum beyond which
conformant implementations MUST NOT truncate?

As a technical contributor, I don't find the limitations of existing applications
very persuasive, since we're adding features.  I *do* find the limitations of
existing *protocols* that use language tags more relevant, (though not decisive)
since they will have a longer term impact on what can actually be used.
However, if we learn that protocol FOO, for example, uses language tags and has
a field of at most 3 octets to hold them, we should think hard before letting
that be the tail that wags this dog.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 05 Jun 2005 18:20:12 +0200

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: Frank Ellermann <[email-masked]>
Date: Sun, 05 Jun 2005 18:30:46 +0200

Doug Ewell wrote:

>>| Support for tags of up to 64 characters is RECOMMENDED.
>>| Implementations MAY support longer tags.

> Please do not delete this.  It is a useful reminder to
> implementers that they need not limit themselves to the
> minimum requirement. Removing a five-word sentence will not
> shorten a 19,000-word draft in any significant way.

I'm a bit paranoid about unnecessary 2119 keywords.  How about
one sentence combining both effects:

    Implementations SHOULD at least support tags with 64
    characters.

If that's only a bad case of DEnglish lets's please forget it,
the separate MAY is not critical.

                        Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 5 Jun 2005 21:27:36 -0700

Hi -

(as a technical contributor)

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, June 05, 2005 9:30 AM
...
...

Please, no!  With that wording, an implementation which only
supported 2-character tags could claim to be conformant.
I don't think that is what we want.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 06 Jun 2005 17:12:18 +0200

> supported 2-character tags could claim to be conformant.

We're dicussing three nits at the same time.  So far we have:

- s/64/63/ is fine for some RfCs mentioned by Ira (2565, 2566,
  2910, 2911, 2707 - I've checked the latter)

- I wanted to combine "SHOULD 64" with "MAYbe more, maybe not"
  as shown above,  Doug said it's a bad idea => forget it

- any minimal MUST is a separate issue...

> I don't think that is what we want.

...yes, "2" isn't good enough.  The most perverse tag in the
direction of "shortest" needs "8" (registered-lang) or "10"
(grandfathered i-enochian) or maybe 11 = 3 +(1+4) +(1+2), but
so far the worst was "10" (zh-min-nan).

Applications supporting less than "10" were inompatible with
3066, no problem if they are also incompatible with 3066bis.

For a compatible "only the language, no nonsense" application
the new 3066is minimum would be "15" (lng-exa-exb-exc) instead
of "10".

Maybe add 5 for a script (1+4) and 4 for a region (1+3) to get
a more interesting no-nonsense limit "24".  But let's not get
carried away, somewhere above 30 we would hit the 2047 barrier.

Do we need an additional minimal MUST at all ?  Apparently RFC
3066 does not have a clear minimum, and our "15" is obvious.

                           Bye, Frank