Subject: RE: [Ltru] Can we live with #944 as in draft -05? (yes, BUT)

From: "Addison Phillips" <[email-masked]>
Date: Mon, 20 Jun 2005 20:46:44 -0700

Some notes below.

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 Martin Duerst
> Sent: 2005?6?20? 18:21
> To: Randy Presuhn; LTRU Working Group
> Subject: Re: [Ltru] Can we live with #944 as in draft -05? (yes, BUT)
> 
> At 08:38 05/06/21, Randy Presuhn wrote:
>  >Hi -
>  >
>  >I'd like to see whether we can close issue #944 regarding whether
>  >a conformant implementation can impose length constraints and what
>  >those constraints might be.  So I'd like to get a "hum" from the group:
>  >
>  >Can you live with the resolution of this issue are reflected in
>  >http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-05.txt ?
>  >
>  >As you may recall from the discussion, points of concern included
>  >whether the MUSTs and SHOULDs made sense,  whether the
>  >lengths given were meaningful, and whether the underlying rationale
>  >was sufficiently clear.
> 
> Overall, I'm quite satisfied.
> 
> But here are a few, mostly editorial, nits:
> (for Randy: I think all these can be lumped together unless
> somebody wants to have one of them addressed specifically).
> 
> -05.txt says:
>     Some applications and protocols are forced to allocate fixed buffer
>     sizes or otherwise limit the length of a language tag in a particular
>     application.
> It might be a good idea to reword this slightly to mention backwards
> compatibility and/or to stress the fact that these would mainly be
> existing protocols.
[Addison Phillips] 

It isn't strictly existing protocols, since any protocol might have a length limitation. I don't think the extra verbiage is necessary to point out that these might be legacy protocols.
> 
> -05.txt says:
>     and such
>     documentation SHOULD include the disposition of any longer tags (for
>     example, whether an error value is generated or the language tag is
>     truncated).
> I don't like the use of a noun that then gets expanded into a 'whether'
> sentence. Maybe:
>     and such
>     documentation SHOULD include what happens to longer tags (for
>     example, whether an error value is generated or the language tag is
>     truncated).
[Addison Phillips] 

That's a no-op change, if there ever was one. It's good because it drops the rather convoluted "disposition" in favor of the more Anglo-Saxon phrasing you suggest. I'll make this change.
> 
> -05.txt says:
>     If truncation is permitted it MUST NOT permit a subtag to be divided
>     or the formation of invalid tags (for example, one ending with the
>     "-" character).
> please at least reword to:
>     If truncation is permitted it MUST NOT permit a subtag to be divided
>     or an invalid tag to be formed (for example, a tag ending with the
>     "-" character).
> Also, I'm not sure why we need two things (divided, formed) here. Wouldn't
> the later just be enough?
[Addison Phillips] 

Divided is, to be sure, a special case of invalid. But a divided subtag might be valid per the ABNF--or even the registry. It makes sense to call out the special case of not chopping mid-tag.
> 
> Somewhat more serious, it looks like the current draft talks a lot about
> subtags, but never exactly says what they are. A reader has to look at
> section 2.2, to somehow get the concept of subtag by enumeration, before
> being able to reasonably well understand the start of 2.1.
> So please, somewhere very early in 2.1, say that subtags are separated
> by "-".
[Addison Phillips] 

Okay.
> 
> An even more serious problem is that section 1 speaks about language
> identifiers, and the word 'tag' doesn't appear a single time in that
> section. Please add something at the end of section 1 saying that
> this document defines a language tag that is designed to serve as
> a language identifier. Or even better, use the stem 'identif...'
> just for the purpose, and the word 'tag' for the thing, as done in
> the title.
[Addison Phillips] 

This text is more-or-less inherited. Must we remove all vestiges of Harold's authorship? But I'll be sufficiently creative to spell out that a tag is an identifier... :-)
> 
> Also, please give Section 2.1 more structure. If there are subsections,
> good style requires that almost everything (except a relatively short
> intro piece) is a subsection, and that there are at least two of them.
> The easiest thing to do is to make the ABNF 2.1.1, and the length
> stuff 2.1.2.
[Addison Phillips] 

No. Section 2 has plenty of structure.
> 
> Please add a short intro paragraph to Chapter 2.
> 
> -05.txt says:
>     Some specifications are space constrained but do not have a fixed
>     length limitation.  For example, see [RFC 2231] [23].  This protocol
>     has no explicit length limitation: the length of the language tag in
>     this document is limited by the length of other header components
>     (such as the charset's name) coupled with the 76 character limit in
>     [RFC 2047] [10].
> The referrent of 'This' is unclear. There is no protocol mentioned
> before, just an RFC. The reader shouldn't have to go to the bibliography
> to figure out that this might be a protocol. The referent of 'this'
> is confusing, too. Is 'this document' our draft? or RFC 2231? or
> a mail document being sent around? Probably best remove "in this
> document".
[Addison Phillips] 

Okay, I'll fix that.
> 
> References such as [RFC 2231] [23] look extremely ugly. Please make this
> either [RFC 2231] or [RFC2231] only (my strong preference) or something
> like RFC 2331 [23].
[Addison Phillips] 

I'll look into it. I have developed a strong aversion to xml2rfc. W3C Specifications are much cleaner.
> 
> -05.txt says:
>     (each subsequent subtag includes '-')
> This is very dangerous. Please change to something like 'the length of
> this and all subsequent subtags includes the preceeding "-"', to avoid
> the impression that the "-" is in any way part of the subtag.
[Addison Phillips] 

Agreed.
> 
> Also, 'showing how the 42 character recommendation was derived' and
> then populating that with "unlikely" is confusing. It would be easier
> to understand if these two things were separated, i.e. first giving
> just the simple example, and then afterwards saying something like
> "Having more than one extlang or variant is considered to be highly
> unlikely, but this was included in the 42 limit to make sure that
> even highly unlikely tags can be processed by applications respecting
> this limit."
[Addison Phillips] 

Okay.
> 
> Also, I'd change "derivation" to something else. "derivation" sounds
> too much like a logical, undavoidable process.
[Addison Phillips] 

"How we figured the length limit" sounds too conversational? Derivation is a bit stodgy, but that's life.
> 
> The text about truncation is in two different places:
> First where it says:
>     If truncation is permitted it MUST NOT permit a subtag to be divided
>     or the formation of invalid tags (for example, one ending with the
>     "-" character).
> and later where it says:
>     Applications or protocols which have to truncate a tag MUST do so by
>     progressively removing subtags along with their preceding "-" from
>     the right side of the language tag until the tag is short enough for
>     the given buffer.  If the resulting tag ends with a single-character
>     subtag, that subtag and its preceding "-" MUST also be removed.
> The first MUST in the second paragraph seems to be very similar to
> the MUST NOT above. The second MUST in the second paragraph comes as
> a (somewhat unexpected) additional restriction.
> Please put everything about truncation together, maybe even in its own
> subsection.
[Addison Phillips] 

Okay.
> 
> I'm not sure zh-Hant-CN-variant1-a-extend1-x-wadegile makes a good example.
> Wade-Giles is a romanization, one would therefore expect zh-Latn rather
> than
> zh-Hant.
[Addison Phillips] 

This example was taken from a particular thread "early" on in this WG's life. Since it is a private use tag, any sort of illogical garbage might exist. That said, "zh-latn-CN-variant1-a-extend1-x-wadegile" would actually make some sense, wouldn't it?

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 21 Jun 2005 07:18:56 +0200

Addison Phillips wrote:

> I'll be sufficiently creative to spell out that a tag is an
> identifier... :-)

You could create a new section 1.1 for the terminology, both
2119 keywords, and the tag vs. subtag terms.  In draft -06 you
now have it twice, at the begin of 2.1 and also at the begin
of 2.2.  Once in 1.1 could be good enough.

>> References such as [RFC 2231] [23] look extremely ugly.
>> Please make this either [RFC 2231] or [RFC2231] only (my
>> strong preference) or something like RFC 2331 [23].
 
> I'll look into it. I have developed a strong aversion to
> xml2rfc.

You'd just need <?rfc symrefs="yes" ?> at the begin, and later
use e.g. <xref target="RFC2231" /> without any explicit text
terminated by </xref>.

> W3C Specifications are much cleaner.

<http://www.w3.org/TR/Templates,tools> and the "pubrules" stuff
are only different, not better.  I can actually read plain text
US ASCII without a browser.  No UTF-8 trouble, no fragment id.
without a name=, just text.

In a later article Randy said:

|> http://www.inter-locale.com/ID/draft-ietf-ltru-registry-06.txt
|...
|
|Ok, can we get a hum on whether these address everyone's
|concerns regarding issue #944?

I've no "hum.wav" and I still like 2.1 in draft -06, bye, Frank

---

From: Martin Duerst <[email-masked]>
Date: Thu, 23 Jun 2005 17:30:59 +0900

Sorry for the delay. Here are some replies. The rest is fine with me.

 >That's a no-op change, if there ever was one. It's good because it drops
 >the rather convoluted "disposition" in favor of the more Anglo-Saxon
 >phrasing you suggest. I'll make this change.

First time somebody has called a proposal of mine "Anglo-Saxon phrasing".
Delighted to hear that!

 >Divided is, to be sure, a special case of invalid. But a divided subtag
 >might be valid per the ABNF--or even the registry. It makes sense to call
 >out the special case of not chopping mid-tag.

"not chopping mid-tag" is much easier to understand (but maybe not yet
as formal as the rest of the draft) than "divided".

 >This text is more-or-less inherited. Must we remove all vestiges of
 >Harold's authorship?

Of course not. But if that's from RFC 3066, then I have to apologise
to Harald that I didn't comment on that earlier.

 >But I'll be sufficiently creative to spell out that a
 >tag is an identifier... :-)
 >>

Section 2 as such has enough structure. The problem is with Section 2.1.
Please fix.

 >Specifications are much cleaner.

I got that problems solved for IRIs (RFC 3987). The source is one
click away from http://www.w3.org/International/iri-edit.

 >This example was taken from a particular thread "early" on in this WG's
 >life. Since it is a private use tag, any sort of illogical garbage might
 >exist. That said, "zh-latn-CN-variant1-a-extend1-x-wadegile" would actually
 >make some sense, wouldn't it?

Fine with me.

Regards,    Martin.