Some corrections entered as shown below. New copy online.
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: ltru-bounces at lists.ietf.org [mailto:ltru-bounces at lists.ietf.org] On
> Behalf Of Frank Ellermann
> Sent: 2005?6?13? 15:13
> To: ltru at ietf.org
> Subject: [Ltru] draft-ietf-ltru-matching-02
>
> Hi, if Randy really wants to "last call" the matching draft
> together with the registry draft it's time to find some nits:
>
> - the references are still messy (2234 instead of 2234bis,
> normative IANA MoU, unreferenced [2], [3], [4], [6], [7],
> [8], [9], [11], [12], [13], [14], [15], [16], [17], {18],
> [20] ).
[Addison Phillips]
Reference cleaning is not done yet.
>
> - the credits are dubious, IIRC only Doug, Ira, Ned, John,
> and Randy contributed to the matching draft (and Ira isn't
> listed).
[Addison Phillips]
Ahem... and both co-editors. And my fellow co-inventor of the extended language range (Jeremy Carroll)... and did I forget anybody?
In any case, this was originally copied, unmodified, from the registry draft. It is now replaced.
>
> - chapter 5 is apparently a copy from the registry draft.
> A simple pointer "security considerations are discussed in
> [draft-ietf-ltru-registry]" is better.
[Addison Phillips]
It is NOT a simple copy: language ranges actually represent the thing that you send in your requests. They, and not language tags, are the item addressed by the security section. Better in matching (where ranges are defined) than in the registry draft!!
>
> - chapter 6 is apparently a copy from the registry draft, it
> could be deleted. Probably this kills some more references.
[Addison Phillips]
I removed the second paragraph. The first was slightly tweaked.
>
> - chapter 4 says "this is the first version of this document".
> But its draft -02, not -00.
[Addison Phillips]
Think of publication as an RFC. This is the first version of this document to be an RFC. That will be the ONLY text in this section after the Last Call. The remaining chicken scratch documents the deltas from draft-to-draft.
>
> - chapter 3 doesn't appear in the order recommended in draft
> rfc-editor-rfc2223bis-08 (Acknowledgements, Security, IANA).
> I've seen Bruce check this, and I got this "wrong" elsewhere.
[Addison Phillips]
Where should I put it?!? It isn't clear from the cited draft. I dislike the endless arcana.
>
> - The "Abstract" contains references, but that's not allowed.
> The XML input is apparently invalid, for a nice validator
> see also <http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/>.
> No, I'm not joking, I discussed this on the xml2rfc list.
[Addison Phillips]
GROAN. I really REALLY dislike endless arcana like this. The abstract for the registry draft cites RFC 3066 (duh).
>
> - For the author's addresses I'd add some corresponding URLs,
> e.g. <http://www.inter-locale.com/> - no idea for Mark, IBM
> URLs are in permanent flux...
[Addison Phillips]
We both hate spam. I exposed my email address and that's sufficient.
>
> ...one hour later, <http://purl.net/net/cp> and queries like
> <http://purl.net/net/cp/858> work again. Grmbl.
>
> - The intro defines unused keywords REQUIRED, SHALL, SHALL NOT,
> and OPTIONAL. Bruce checks this.
[Addison Phillips]
Argh. Let him. Let's keep them defined until forced to remove them (the document is early in gestation).
>
> - chapter 2.1.1 mentions en-DE-boont, that's an odd example
> for matching.
[Addison Phillips]
Changed. Now only the tag "de-Deva" is entirely unlikely.
>
> - chapter 2.1.2 says *[ "-" extlang ]
> Bill's checker proposes *( "-" extlang )
> We want *3( "-" extlang )
[Addison Phillips]
Changed per other thread.
>
> It also says ( "x" / "X" ) instead of "x". Same problem in
> the registry draft, AFAIK ("x"/"X") should be "x", reported
> several times here.
[Addison Phillips]
No, it shouldn't, I don't believe. Although the text defines the case equivalence, some scurrilous dogs complained about not including both cases in the ABNF last time around. I'd hate to tangle with it again.
>
> Obscure ABNF issues => TILT, I don't look any further, bye.
[Addison Phillips]
Hopefully better now.
>
>
>
> _______________________________________________
> Ltru mailing list
> Ltru at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.