Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP

From: Bruce Lilly <[email-masked]>
Date: Fri, 17 Dec 2004 21:09:29 -0500

>  Date: 2004-12-15 14:09
>  From: "Peter Constable" <[email-masked]>
>  To: [email-masked], [email-masked]
>  
> > From: [email-masked] [mailto:ietf-languages-
> > [email-masked]] On Behalf Of Bruce Lilly
> 
> 
> > Currently sr-CS has a specific
> > meaning under RFC 3066; it has had for some time.
> 
> The meaning "Serbia and Montenegro" was introduced relatively recently
> (a little more than a year ago), was immediately received with alarm by
> many in the IT sector. There were vain attempts to get it reversed, and
> that failure was an impetus to introduce protection against such changes
> in the revision of RFC 3066. I am not aware of "CS" being used in the IT
> sector with the new meaning, though cannot guarantee that.

I can. I could, but won't, simply put some content up
with that meaning.  One example will serve to establish
the existing usage; I'll provide two (I'm a heavy tipper :-).
I could provide more, but that would be superfluous.

1. URI http://welcome.hp.com/country/cs/sr/welcome.html
   Aside from the obvious usage in the URI itself, the
   HTML content contains the following (my commentary
   marks items of particular relevance):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="sr-cs">

   N.B. the specific language-tag "sr-cs"!

	<meta name="target_country" content="cs">

            <td><select name="countrySelect" id="countrySelect" title="Izbor zemlje - Promenom izbora pre&#263;i &#263;ete na lokaciju izabrane zemlje">
                <option selected>Srbija i Crna Gora-Srpski

2. URI http://www.ibm.com/cs/
   Once again, note the use in the URI itself.
   Content includes:

<meta name="IBM.Country" content="CS"/>
<meta name="Description" content="IBM Serbia and Montenegro"/>
<meta name="Abstract" content="IBM Serbia and Montenegro"/>

<meta name="Keywords" content="IBM Serbia and Montenegro"/>
<meta name="DC.Publisher" content="IBM Corporation"/>

<title>IBM Srbija I Crna Gora</title>

<a href="/news/cs/2004/10/cs_sr_20041013.html"><

   N.B. "cs" and "sr" used together.

<!-- cs/sr/all assembled by mhpb v1.1 on Thu, 25 Nov 2004 12:22:14 CUT -->

   N.B. "CS" and "sr" together again.

Clearly neither example is referring to the no longer
extant "Czechoslovakia"...  And Hewlett-Packard (having
acquired DEC and Compaq) and IBM clearly constitute
representatives of "the IT sector".

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

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 17 Dec 2004 21:51:09 -0500

>  Date: 2004-12-15 14:41
[...]
> How is it possible to predict ahead of time what is the worst-case
> length for a RFC3066-registered language tag?

In some contexts, the length is limited by the context
(e.g. encoded-words, Content-Language fields in an
Internet Message).
 
> Neither is possible. In light of that, I think it best to make sure
> implementers of the revised RFC 3066 be reminded that some
> implementations may impose limits (whether those implementers be
> constructing tags or passing them from one process to another), and for
> implementers to incorporate robustness into their implementations so
> that they can respond gracefully if an unexpectedly-long tag is
> encountered -- after all, no matter what limit could be imposed in a
> revision to RFC 3066, there's no way to stop malware from sending bad
> data.
> 
> (How *do* encoded-word parsers react if a bogus charset or language tag
> that's 2k octets long is encountered?

By definition, that cannot happen. No encoded-word may be
longer than 75 octets.  A sequence longer than that limit,
even if it matches all other characteristics of an
encoded-word, is treated as ordinary ASCII text (RFC 2047,
section 6.1, paragraph marked "(1)").  No header field
line may be longer than 998 octets (not counting the
terminating CRLF pair), so 2k is simply not permitted.

> The encoded-word spec already 
> allows for segmenting long strings;

To be a bit more precise, it permits text to be encoded to
be split across multiple encoded-words (with several
restrictions); the encoded-words themselves cannot be in
any way segmented or split.  That is because an encoded-word
is treated by a MIME-unaware application as a single RFC
[2]822 word.

> could it not also be revised to 
> allow segmenting for the parameters, which would also make it more
> robust?)

If you're referring to RFC 2231 extensions to Content-Type
and Content-Disposition field parameters, that's a separate
matter.

In general, though, as MIME has been around for more than a
decade and Internet Messages for more than three decades,
with a substantial installed base of interoperating
implementations, in what has become one of the core Internet
protocols, any changes would have to be backwards compatible
or would have to be negotiated between sender and receiver
at the same protocol level, or would require a lengthy
transition period before pulling the rug out from under
existing implementations.  It's probably more likely that a
separate next-generation system would be implemented first.

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 18 Dec 2004 13:38:25 -0500

>  Date: 2004-12-15 13:22
>  From: John Cowan <[email-masked]>

> The current process does *not* limit the length of non-private-use
> tags.

It does by way of reviewer, community, and IETF Area
Director review.

> But absolutely nothing except his good sense prevents Michael from registering
> en-the-dialect-spoken-on-the-bowery-between-1933-and-1945-by-alcoholic-drug-users-who-live-in-flophouses.

Aside from specific technical details already addressed
by others, such a long name would certainly solicit the
strong suggestion that the submitter should find a
suitable shortened form, as such a long tag could not
be used in an encoded-word.