Subject: RE: [Ltru] draft-ietf-ltru-matching-02

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

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Frank Ellermann
> Sent: 2005?6?13? 15:13
> To: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Jun 2005 16:26:45 +0200

> Some corrections entered as shown below. New copy online.

Okay, but Mark already convinced me that I got Randy wrong in
my premature "last call" frenzy.

>> - the credits are dubious
[...]
> Ahem... and both co-editors.

AFAIK editors do not credit themselves, it's obvious that they
contributed in some way.  But I'm currently at odds with some
of the professional standards of the I"E"SG and studying texts
like RfC 2026 6.5.2 and RfC 3777 chapter 7.

 [security considerations] 
> It is NOT a simple copy: language ranges
[...]
> are the item addressed by the security section.

Almost identical parts (matching -02 vs. registry -04):

| Although the specification of valid subtags for an extension
| MUST be available over the Internet, implementations SHOULD
| NOT mechanically depend on it being always accessible, to
| prevent denial-of-service attacks.

Where is the protection of the IANA tag registry against DoS
attacks relevant for the purposes of "tag matching" ?

| 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.
|
| The evaluation of the exact magnitude of the threat, and
| any possible countermeasures, is left to each application
| protocol.

And how does this almost literal copy from the registry draft
affect any tag "matching" applications ?  It's somehow like
saying "regular expressions might be abused to guess what the
user actually wants".  Now, yes, that's their purpose, and the
privacy issue is addressed in the registry draft.

IMHO all you need is the first paragraph with a pointer to the
registry draft:

| Language ranges used in content negotiation, like any other
| information exchanged on the Internet, might be a source of
| concern because they might be used to infer the nationality
| of the sender, and thus identify potential targets for
| surveillance.  This issue is also addressed in [RFC3066bis].

No fancy stuff about the lack of "security considerations" in
1766 and 3066, just the facts, ready.  Especially don't claim
that this is the _only_ known "security consideration", there
are already more in the registry draft.

> Better in matching (where ranges are defined) than in the
> registry draft!!

Yes, above I took the registry wording with an s/tags/ranges/.

 [recommended order of sections in draft 2223bis -08]
> Where should I put it?!? It isn't clear from the cited draft,
> I dislike the endless arcana.

Me too, I hope that they will settle on one clear document, at
the moment there are at least three (draft-hoffman-rfc-editor-
author-guide, draft-rfc-editor-rfc-2223bis, 1id-guidelines).

And if you think that you might be up to speed Bruce will find
some relevant errata, some of them are acknowledged but still
unpublished.

The "recommended order" in 2223bis-08 (expired February 2005):

    7a.  Contributors              7b.  Acknowledgments
    7c.  Security Considerations   7d.  IANA Considerations
    7e.  Appendixes                7f.  References

7c is required.  7d is AFAIK also required, but not in this
draft.  BTW, they just discuss this oddity on the IETF list.

  [no references in the abstract]
>> I'm not joking, I discussed this on the xml2rfc list.
 
> GROAN. I really REALLY dislike endless arcana like this.
> The abstract for the registry draft cites RFC 3066 (duh).

That's a matter of the DTD, it doesn't allow <xref> in the
<abstract>.  It's also a rule in the expired 2223bis-08 4.5:

| An Abstract should be complete in itself; it should not
| contain citations unless they are completely defined within
| the Abstract.

>> e.g. <http://www.inter-locale.com/>
[...]
> We both hate spam. I exposed my email address and that's

We all do, but some of us love googlebot.  Do you want me to
delete my link to your page, only because an address harvester
might find and follow it ?  I meant the optional <uri>..</uri>
part, not your munged <email>..</email> address, that's fine.

  [unused 2119 keywords]
>> Bruce checks this.
> Argh. Let him.

Okay.  And if Scott has a problem with the lower case variant
as soon as the upper case is defined let them shoot it out ;-)

 [maybe replace ( "x" / "X" ) by "x"]
> No, it shouldn't, I don't believe.

Maybe.  But never ever try to say "x" if you don't want also
"X", they'd bury you under tons of RfCs and "hum" to it.  And
draft taobis-02 is *not* expired, no excuses, no prisoners :-)

                         Bye, Frank