Subject: RE: [Ltru] Re: [psg.com #965] expectation of support for automatedreading of registry

From: "Addison Phillips" <[email-masked]>
Date: Wed, 1 Jun 2005 12:35:57 -0700

Note: I just posted an editor's copy of matching-01 at:

http://www.inter-locale.com/ID/draft-ietf-ltru-matching-01.html
http://www.inter-locale.com/ID/draft-ietf-ltru-matching-01.txt

This includes a new section 2.6 "Length Considerations in Matching" which is slightly rewritten from the same text in section 2.1.1 of registry. Here is the text:

---

Although there is no upper bound on the number of subtags in a language tag and it is possible to envision quite long and complex subtag sequences, in practice these are rare because of the various considerations discussed in Section 2.1.1 of [1] (Phillips, A., Ed. and M. Davis, Ed., "Tags for the Identification of Languages (Internet-Draft)," February 2005.).

A matching implementation MAY choose not to support the storage or matching of language tags and ranges which exceed a specified length. Any such limitation SHOULD be clearly documented, and such documentation SHOULD include the disposition of any longer tags or ranges (for example, whether an error value is generated or the language tag is truncated). If truncation is permitted it must not permit a subtag to be divided, since this changes the semantics of the tag or range being matched and may result in false positives or negatives. Implementations that restrict storage should consider removing extensions before matching. A protocol that allows tags or ranges to be truncated at an arbitrary limit, without giving any indication of what that limit is, has the potential for causing harm by changing the meaning of values in substantial ways.

In practice, tags and ranges are limited to a sequence of four subtags, and thus a maximum length of 26 characters (excluding any extensions or private use sequences). This is because subtags are limited to a length of eight characters and the extlang, script, and region subtags are additionally limited to even fewer characters. In addition, the Language Subtag Registry provides guidance on the use of subtags (via fields such as Suppress-Script and Recommended-Prefix) which further limit useful combination of subtags in a language tag or range.

Longer tags are possible. The longest practical tags (excluding extensions) could have a length of up to 58 characters, as shown below. Implementations MUST be able to handle matching tags of this length. Support for tags and ranges of up to 64 characters is RECOMMENDED. Implementations MAY support longer tags, including matching extensive sets of private use or extension subtags.

Here is how the 58-character length of the longest practical tag (excluding extensions) is derived:
---

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: mercredi 1 juin 2005 12:34
> To: LTRU Working Group
> Subject: [Ltru] Re: [psg.com #965] expectation of support for
> automatedreading of registry
> 
> Hi -
> 
> > From: "McDonald, Ira" <[email-masked]>
> ...
> > Sent: Wednesday, June 01, 2005 12:00 PM
> > Subject: RE: [Ltru] Re: [psg.com #944] MAY a conformant implementation
> imposelength constraints?
> ...
> > In the security section, I'm not sure what is meant by the last
> > sentence:
> >
> > "Although the specification of valid subtags for an extension MUST be
> > available over the Internet, implementations SHOULD NOT mechanically
> depend
> > on it being always accessible, to prevent denial-of-service attacks."
> >
> > Is that 'specification' the IANA Language Subtag Registry?  If so, we
> should
> > say that explicitly.  If not, we should be clearer.
> ...
> 
> This really belongs in the thread for issue [psg.com #965]
> 
> 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: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Jun 2005 12:44:18 -0700

Hi -

and THIS should have been posted on thread [psg.com #944]

Randy

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
Sent: Wednesday, June 01, 2005 12:35 PM
Subject: RE: [Ltru] Re: [psg.com #965] expectation of support for automatedreading of registry

This includes a new section 2.6 "Length Considerations in Matching" which is slightly rewritten from the same text in section 2.1.1
of registry. Here is the text:

---

Although there is no upper bound on the number of subtags in a language tag and it is possible to envision quite long and complex
subtag sequences, in practice these are rare because of the various considerations discussed in Section 2.1.1 of [1] (Phillips, A.,
Ed. and M. Davis, Ed., "Tags for the Identification of Languages (Internet-Draft)," February 2005.).

A matching implementation MAY choose not to support the storage or matching of language tags and ranges which exceed a specified
length. Any such limitation SHOULD be clearly documented, and such documentation SHOULD include the disposition of any longer tags
or ranges (for example, whether an error value is generated or the language tag is truncated). If truncation is permitted it must
not permit a subtag to be divided, since this changes the semantics of the tag or range being matched and may result in false
positives or negatives. Implementations that restrict storage should consider removing extensions before matching. A protocol that
allows tags or ranges to be truncated at an arbitrary limit, without giving any indication of what that limit is, has the potential
for causing harm by changing the meaning of values in substantial ways.

In practice, tags and ranges are limited to a sequence of four subtags, and thus a maximum length of 26 characters (excluding any
extensions or private use sequences). This is because subtags are limited to a length of eight characters and the extlang, script,
and region subtags are additionally limited to even fewer characters. In addition, the Language Subtag Registry provides guidance on
the use of subtags (via fields such as Suppress-Script and Recommended-Prefix) which further limit useful combination of subtags in
a language tag or range.

Longer tags are possible. The longest practical tags (excluding extensions) could have a length of up to 58 characters, as shown
below. Implementations MUST be able to handle matching tags of this length. Support for tags and ranges of up to 64 characters is
RECOMMENDED. Implementations MAY support longer tags, including matching extensive sets of private use or extension subtags.

Addison P. Phillips

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 01 Jun 2005 22:33:00 +0200

Addison Phillips wrote:

> various considerations discussed in Section 2.1.1 of [1]
> (Phillips, A., Ed. and M. Davis, Ed., "Tags for the
> Identification of Languages (Internet-Draft)," February
> 2005.).

Somewhere I saw Bruce Lilly quoting an older article on the
rfc-interest mailing list, where "they" (RfC editor) wanted
<?rfc symrefs="yes" ?> as an xml2rfc-default, because "they"
have sometimes a problem with fixing numbered references...

...hearsay, I can't tell you more, but please replace or
remove "February", draft -02 was published in May.  Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 01 Jun 2005 22:45:03 +0200

Randy Presuhn wrote:

> THIS should have been posted on thread [psg.com #944]

| Policy-Mandated Labels Such as "Adv:" in Email Subject Headers
|                    Considered Ineffective At Best

<http://purl.net/net/rfc/4096>  It's not completely funny, my
UA does strange things with folded subject header fields when
I use "quoted printable" as default (if necessary).  If some
spaces are lost in these long subjects it's a side-effect.

Is anything _wrong_ with the concept of References in mail and
news ?  The USEFOR WG just started its 1001st debate on this
issue, fresh ideas always welcome.
                                   Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Jun 2005 14:26:13 -0700

Hi -

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, June 01, 2005 1:45 PM
> Subject: [Ltru] Meta (was: MAY a conformant implementation impose lengthconstraints)
>
> Randy Presuhn wrote:
>

That document considers a completely different question, and in
section 4 explicitly declares our kind of label usage out of scope.

> spaces are lost in these long subjects it's a side-effect.

When I respond to a message with such a mangled subject, I
just try to put the spaces back.  Subject lines are for humans,
after all, which is why *I* need the issue number.  If this were not
such a spectacularly verbose working group, they probably would
not be needed.

...

Well, just as your UA mangles subject lines, here's what I have to
do to handle a "References" with mine:

(1) right-click on message
(2) pull down and select "Properties"
(3) click on "Details"
(4) click on "Message Source"
(5) look for the "References:" header (there is no "search")
(6) select & control-c (to copy) the message id
(7) close the window
(8) right-click on my folder of filed ltru messages
(9) pull down and select "Find"
(10) control-v (to paste) the message id to look for into the "Message" field
(11) sit back and wait (and wait) to see whether a message actually has that id
     frequently there will be no matching message id, even though the intended
     content is indeed there.

I don't even want to think about doing this on a regular basis.
The concept might be good, but the implementation is nearly worthless.
I guess the obvious solution is for both of us to get new UAs.  :-)

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Jun 2005 04:15:35 +0200

Randy Presuhn wrote:

 [4096] 
> That document considers a completely different question

Sure, and my "last call" comment "stay away from RfC 3834 and
its [Auto] tag" is not exactly represented in the text, but
it's fun to read it (outside of its RfC 3865 / 4095 context).
 
> just try to put the spaces back.

Me too, actually I think my UA wouldn't introduce new errors,
it's only too stupid to display the folded subjects correctly.

> Subject lines are for humans,

RT ticket numbers aren't for humans, they are for RT.  In its
"overview" mode with a window size that is no accident my UA
displays exactly the portion "Re: [psg.com #1018..."

Not that "Re: Meta" is much better, and in the case of #1018 I
now know what it means.

> If this were not such a spectacularly verbose working group

Compared with lists like USEFOR or SPF or the former MARID it
is still relatively quiet.  It might even produce an RfC, and
that would be the first from my POV.  Maybe SPF can beat LTRU.

> the implementation is nearly worthless.

Unlike Outlook OE at least sort of supports 2049.  With my old
UA I just click on a link to get an article in the References.
For mail if it exists in the same mail folder, but I read LTRU
as newsgroup, and the server normally has all articles.

> I guess the obvious solution is for both of us to get new

You for threading, and I for Unicode, yes.  For de and en the
latter isn't too important.  Sometimes "stupid UA" also means
"too stupid to get it seriously wrong".  Bye, Frank