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

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 22 Jun 2005 10:45:00 -0700

Hi,

The text is all pretty clear, but some numbered subsections
and a little reorganization (for like topics) are badly needed.  

Hidden far down in the middle of _fifth_ paragraph of section 
2.1.1 'Length Considerations' is out Normative length requirement 
of 33 characters for buffers.

I suggest inserting some subsections and breaking up the
two-topic (length and truncation) fifth paragraph as follows:

2.1.1.1 Tag Length Conformance Requirements

Protocols or specifications that conform to the current version
of this document and specify limited buffer sizes for language tags 
MUST allow for language tags of up to 33 characters, and SHOULD 
allow for language tags of at least 42 characters.  

2.1.1.2 Tag Truncation Conformance Requirements

Language tags SHOULD NOT be truncated unless the meaning of the tag
is purposefully being changed, or unless the tag does not fit into a
limited buffer size specified by a protocol for storage or
transmission.  As truncation can change the semantic meaning of the 
tag, it is RECOMMENDED that the user be warned of any truncation.

<para 6 as is>

<para 7 as is>

<move 'Applications or protocols which have to truncate a tag...'
and following <figure 3> up to section 2.1.1.2 after the existing 
<para 7>>

2.1.1.3 Derivation of Tag Length Requirements

<The following illustration shows...>

<figure 2 as is>

OK?

Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Randy Presuhn
> Sent: Tuesday, June 21, 2005 12:21 AM
> To: LTRU Working Group
> Subject: Re: [Ltru] Can we live with #944 as in draft -05? (yes, BUT)
> 
> 
> Hi -
> 
> > From: "Addison Phillips" <[email-masked]>
> > To: "Addison Phillips" <[email-masked]>; 
> "Martin Duerst" <[email-masked]>; "Randy Presuhn"
> <[email-masked]>; "LTRU Working Group" <[email-masked]>
> > Sent: Monday, June 20, 2005 8:57 PM
> > Subject: RE: [Ltru] Can we live with #944 as in draft -05? 
> (yes, BUT)
> >
> > Changes in the editor's copy.
> >
> > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-06.html
> > 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?
> 
> 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: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Jun 2005 09:13:29 -0700

>  >> Please add a short intro paragraph to Chapter 2.

I've thought about this some more...

I've done the following as a result:

1. I simplified the text in the introduction with more reliance on the word "tag".

2. I moved the definition of language tags from Section 4.2 (meaning) to act as an introduction to the language tag in Section 2 (just before Section 2.1). Section 4.2 has been slightly reorganized as a result (the "meaning" material was moved ahead of the prefix relationship material).

3. Following Ira's note, I have added more structure and some gentle word tugging to Section 2.1.1 (length considerations) and fixed the pedantic "divided" as noted by Martin. There are now two subtags for that section ("Assigning Buffer Limitations" and "Truncation of Language Tags")

4. I changed to use the symrefs='yes' processing instruction. References should now be somewhat cleaner.

Results on-line at inter-locale. If no objections result, I'll post an official draft-06 today.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> From: Martin Duerst [mailto:[email-masked]]
> Sent: 2005?6?23? 1:31
> To: Addison Phillips; Randy Presuhn; LTRU Working Group
> Subject: RE: [Ltru] Can we live with #944 as in draft -05? (yes, BUT)
> 
> Sorry for the delay. Here are some replies. The rest is fine with me.
> 
> At 12:46 05/06/21, Addison Phillips wrote:
>  >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.
>  >
>  >> From: [email-masked] [mailto:[email-masked]]
> On
>  >> Behalf Of Martin Duerst
>  >> Sent: 2005?6?20? 18:21
>  >> To: Randy Presuhn; LTRU Working Group
>  >> 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:
>  >>     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.
> 
> First time somebody has called a proposal of mine "Anglo-Saxon phrasing".
> Delighted to hear that!
> 
>  >> -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.
> 
> "not chopping mid-tag" is much easier to understand (but maybe not yet
> as formal as the rest of the draft) than "divided".
> 
>  >> 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?
> 
> 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... :-)
>  >>
>  >> 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.
> 
> Section 2 as such has enough structure. The problem is with Section 2.1.
> Please fix.
> 
>  >> Please add a short intro paragraph to Chapter 2.
> 
>  >> 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.
> 
> I got that problems solved for IRIs (RFC 3987). The source is one
> click away from http://www.w3.org/International/iri-edit.
> 
>  >> 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?
> 
> Fine with me.
> 
> 
> Regards,    Martin.

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 23 Jun 2005 09:38:56 -0700

Hi Addison,

Well...the new subsections don't even show in the Table of Contents
(because they're at the fourth level).

What I'd like to see (details of text aside) is:
- A numbered section in the Table of Contents named something like
  'Tag Length Conformance Requirements' (not 'Assigning...')
- That old <para 5> broken up, because it still buries the
  key conformance requirement of the whole spec in obscurity.

Cheers,
- Ira

> Behalf Of Addison Phillips
> Sent: Thursday, June 23, 2005 12:13 PM
> To: Martin Duerst; Randy Presuhn; LTRU Working Group
> 2. I moved the definition of language tags from Section 4.2 
> (meaning) to act as an introduction to the language tag in 
> Section 2 (just before Section 2.1). Section 4.2 has been 
> slightly reorganized as a result (the "meaning" material was 
> moved ahead of the prefix relationship material).
> 
> 3. Following Ira's note, I have added more structure and some 
> gentle word tugging to Section 2.1.1 (length considerations) 
> and fixed the pedantic "divided" as noted by Martin. There 
> are now two subtags for that section ("Assigning Buffer 
> Limitations" and "Truncation of Language Tags")
> 
> 4. I changed to use the symrefs='yes' processing instruction. 
> References should now be somewhat cleaner.
>