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

From: "Addison Phillips" <[email-masked]>
Date: Tue, 7 Jun 2005 12:42:13 -0700

Hi Mark,

> 
> 
> I disagree strongly with this language, as I stated before. It appears
> that
> you didn't see my message of Monday, June 06, 2005 13:49. Please look at
> that.
[Addison Phillips] 

I missed that message, or at least the substance of it. You're suggesting that the truncation be by strict progressive removal from right, correct? Or should we attempt to enumerate progressively removing extensions first?

> 
> >This limit SHOULD be at least 33 characters in length.
> 
> I haven't heard anyone say why we shouldn't use 63 instead. (here and in
> other locations)
[Addison Phillips] 

The reason was given semi-obliquely by Frank and Ira: RFC 2047 headers (and other applications) can only contain a limited number of characters and 63 leaves no room for actual content. Thus it seems like an overly large value as a *required* minimum. Pointing out the 63 number makes a lot of sense, though.
> 
> >Here is how the 33-character length of the longest generated tag is
> derived:
> 
> This is incorrect.
> en-US-x-abcdefgh-abcdefgh-abcdefgh-abcdefgh-abcdefgh-abcdefgh-abcdefgh
> is a generated tag, and it is longer.
[Addison Phillips] 

The "longest generated tag" uses only registry entries and no private use values. It is not the longest tag. There is no "longest tag". There are merely different probabilities of a tag being of a specific length. Even really long potentially useful tags don't approach the 63 maximum:

zh-min-nan-Latn-CN-xiang-x-wadegile (35 characters and xiang is irresponsible)
> 
> Moreover, I don't see the purpose of having this analysis be present in
> the
> specification itself. We should delete "Here is...Figure 2: Derivation of
> the Longest Generated Tag"
> 
> And should delete also "Note: The longest tag...Figure 3: Derivation of
> the
> Longest Tag". I disagree that this is the longest practical tag -- what is
> "practical" is an extremely gray area -- and there is no reason for us to
> go
> into the analysis.
[Addison Phillips] 

Agreed. It is wasteful to illustrate this in this manner.

Addison

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

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 7 Jun 2005 13:20:19 -0700

my comments below.

‎Mark

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "Mark Davis" <[email-masked]>; "LTRU Working Group"
<[email-masked]>
Sent: Tuesday, June 07, 2005 12:42
Subject: RE: [Ltru] Tag perversity text revised... (#944)

> I missed that message, or at least the substance of it. You're suggesting
that the truncation be by strict progressive removal from right, correct? Or
should we attempt to enumerate progressively removing extensions first?

See my later message to John. I'm suggesting strictly removal from the
right, plus any trailing singleton that would remain. Simple.

> The reason was given semi-obliquely by Frank and Ira: RFC 2047 headers
(and other applications) can only contain a limited number of characters and
63 leaves no room for actual content. Thus it seems like an overly large
value as a *required* minimum. Pointing out the 63 number makes a lot of
sense, though.

Ah, I now understand. I still think there is no reason to not use 63; after
all, it is a SHOULD, and if someone has reason for it to be shorter then
they can make it so.

> The "longest generated tag" uses only registry entries and no private use
values. It is not the longest tag. There is no "longest tag". There are
merely different probabilities of a tag being of a specific length. Even
really long potentially useful tags don't approach the 63 maximum:

Every use of "generate" that I see in the text (before your changes) applies
to "generated according to this specification", which includes private use
and extension. Nothing supports exclusion of the latter. And "generated" is
a bad term to use if you really mean "generated with the exclusion of
private use and extension subtags". If we really need a single term for the
later we should define a new term (but I'm not convinced we do).