Subject: RE: [Ltru] New version posted: ready for publication??

From: "Addison Phillips" <[email-masked]>
Date: Thu, 21 Apr 2005 09:52:01 -0700

That's the document! Sorry I didn't send a link previously. At that point I was rushing to get to the airport on time.

Outlook ate the extra carriage returns in your message. Check to see if I captured your comments correctly.

Notes follow.

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: Mark Davis [mailto:[email-masked]]
> Sent: Thursday, April 21, 2005 9:16 AM
> To: Addison Phillips; ltru Working Group
> Subject: Re: [Ltru] New version posted: ready for publication??
> 
> I didn't get an attachment and there wasn't a link I assume you mean the
> document at
> 
> http://inter-locale.com/ID/draft-ietf-ltru-registry-01.html
> 
> It looks good. I only found some minor stuff.
> 
> 
> 2.1
> [In the ABNF, variant has extra spaces in front.]
[Addison Phillips] 

Space removed.
> 
> 2.1.1
> [add] All subtags are from 1 to 8 characters in length.
[Addison Phillips] 

Not sure where you want me to put this. 2.1.1 is the length considerations section and I don't see a particular spot to stick this text.
> 
> 
> 2.2.5
> [remove] The maximum length of a variant subtag is eight characters long.
[Addison Phillips] 

Done.
> 
> 
> 3.1
> field = field-name *SP ":" field-body CRLF=>field = field-name *SP ":" *SP
> field-body CRLF[Leading spaces shouldn't be considered part of the
> field-body, for consistency.] 
[Addison Phillips] 

Good catch. Done.

Subsequent records represent subtags in the
> registry. Each record MUST contain the following fields: => Subsequent
> records represent subtags in the registry. Each of the fields in each
> record
> MUST occur no more than once, unless otherwise noted below. Each record
> MUST
> contain the following fields:
[Addison Phillips] 

Done.

> 4.1 [some extra you's]
>  Some protocols may force you to give a value for the language tag and the
> 'UND' subtag may be useful when matching language tags in certain
> situations.
> =>
>  The 'UND' subtag may be necessary when a protocol requires a value for
> the
> language tag, or when matching language tags in certain situations.
[Addison Phillips] 

I did a slightly different rewrite:

Some protocols may require a value for the language tag and the 'UND' subtag may be useful when matching language tags in certain situations.
> 
>  The 'MUL' (Multiple) primary language subtag SHOULD NOT be used if the
> protocol allows you to use multiple languages, as is the case for the
> Content-Language header in HTTP.
> =>
>  The 'MUL' (Multiple) primary language subtag SHOULD NOT be used whenever
> a
> protocol allows the use of multiple languages, as is the case for the
> Content-Language header in HTTP.
[Addison Phillips] 

Done. Should there be a general warning against using 'MUL'? Something like:

--
The 'MUL' subtag conveys little useful information: content in multiple languages should individually tag the languages where they appear or otherwise indicate the actual language in preference to the 'MUL' subtag.
--
> 
> 6.
>  This is a special case of the general problem that anything you send is
> visible to the receiving party. It is useful to be aware that such
> concerns
> can exist in some cases.
> =>
>  This is a special case of the general problem that anything sent is
> visible
> to the receiving party. It is useful to be aware that such concerns can
> exist in some cases.
[Addison Phillips] 

Done. Will post shortly.
> 
> Mark
> 
> ‎Mark
> 
> ----- Original Message -----
> From: "Addison Phillips" <[email-masked]>
> To: "ltru Working Group" <[email-masked]>
> Sent: Wednesday, April 20, 2005 16:27
> Subject: [Ltru] New version posted: ready for publication??
> 
> 
> > All,
> >
> > I have just posted an updated version of draft-01 editor's copy. This
> includes all of the edits I'm currently aware, including the less subtle
> variant ABNF. It has been updated using the new xml2rfc and references the
> latest and greatest IETF process RFCs.
> >
> > I'm prepared to submit this, barring errors in the document.
> >
> > Question: what issues remain before this document can be considered in
> its
> final form?
> >
> > Best Regards,
> >
> > Addison
> >
> > Addison P. Phillips
> > Globalization Architect, Quest Software
> > http://www.quest.com
> >
> > Chair, W3C Internationalization Core Working Group
> > http://www.w3.org/International
> >
> > Internationalization is not a feature.
> > It is an architecture.
> >
> >
> >
> 
> 
> --------------------------------------------------------------------------
> --
> ----
> 
> 
> > _______________________________________________
> > 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: "Mark Davis" <[email-masked]>
Date: Thu, 21 Apr 2005 10:11:09 -0700

My comments below.

‎Mark

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "Mark Davis" <[email-masked]>; "Addison Phillips"
<[email-masked]>; "ltru Working Group"
<[email-masked]>
Sent: Thursday, April 21, 2005 09:52
Subject: RE: [Ltru] New version posted: ready for publication??

> That's the document! Sorry I didn't send a link previously. At that point
I was rushing to get to the airport on time.
> > [In the ABNF, variant has extra spaces in front.]
OK

> Not sure where you want me to put this. 2.1.1 is the length considerations
section and I don't see a particular spot to stick this text.

We can put this below the ABNF itself in a note. In the Length
considerations, perhaps the following
" This limits most tags to a sequence of four subtags (excluding any
extensions or private use sequences). "
=>
 In practice, this limits most tags to a sequence of four subtags -- and
thus a length of 35, because subtags are limited to a length of 8 each
(excluding any extensions or private use sequences).

> > [remove] The maximum length of a variant subtag is eight characters
long.
OK

> > field-body, for consistency.]
OK

> > contain the following fields:
OK

> Some protocols may require a value for the language tag and the 'UND'
subtag may be useful when matching language tags in certain situations.

I did a bit more shuffling around, because the sentences was very clumsy.
The two clauses are really disconnected, separate reasons for why someone
might want to use UND, but the "and" makes them sound like they are supposed
to be connected. So I prefer my rewrite.

> Done. Should there be a general warning against using 'MUL'? Something
like:
OK

>
> --
> The 'MUL' subtag conveys little useful information: content in multiple
languages should individually tag the languages where they appear or
otherwise indicate the actual language in preference to the 'MUL' subtag.
SURE

OK

> > > Internationalization is not a feature.

----------------------------------------------------------------------------
----

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 21 Apr 2005 10:42:01 -0700

Oh, almost forgot.

UND, MUL and FR should use recommended [ISO 639] casing (lowercase) in the
following:

> The 'UND' (Undetermined) primary language subtag SHOULD NOT be used to
label content, even if the language is unknown. Omitting the tag is
preferred. Some protocols may force you to give a value for the language tag
and the 'UND' subtag may be useful when matching language tags in certain
situations.

>  <span lang="FR">C'est la vie.</span> in