Jovial in-line response 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: ltru-bounces at lists.ietf.org [mailto:ltru-bounces at lists.ietf.org] On > Behalf Of Frank Ellermann > Sent: 2005?6?15? 7:27 > To: ltru at ietf.org > Subject: [Ltru] Re: draft-ietf-ltru-matching-02 > > Addison Phillips wrote: > > > 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. [Addison Phillips] Yes, but good edits are useful to capture. > > >> - 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. [Addison Phillips] No, they don't usually do so. But in making a list, one should be thorough. > > [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):[Addison Phillips] [Addison Phillips] Yes, nearly identical, but that isn't a reason not to have the text. > > Where is the protection of the IANA tag registry against DoS > attacks relevant for the purposes of "tag matching" ? [Addison Phillips] It isn't applicable to matching. The registry is never even mentioned in the matching draft, IIRC. > > | 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. [Addison Phillips] The privacy issue really pertains to tracking the requests people make and those are expressed as ranges. In other words, language tags by themselves do not have privacy issues. If I tag some XML content with xml:lang, that has no privacy issue. Neither is labeling this email with a Content-Language: my "identity" (in the form of my email address) is a much better indicator of who I am. It is a privacy issue when you request things with a token that may be somewhat unique and thus can be tracked. The token is a range, not a tag, and thus matching applications may very well also be tracking applications. > > 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. [Addison Phillips] That is good text. > > > Better in matching (where ranges are defined) than in the > > registry draft!! > > Yes, above I took the registry wording with an s/tags/ranges/. [Addison Phillips] Yep, I'm still putting in the formulation "tags and ranges" (since matching also concerns tags---it is matching tags to 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 [Addison Phillips] And there was much rejoicing. Not only will I have to reorder this draft, but also the registry draft. > > 7c is required. 7d is AFAIK also required, but not in this > draft. BTW, they just discuss this oddity on the IETF list. [Addison Phillips] I saw the thread on null IANA sections. > > [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: [Addison Phillips] Both documents cite RFC 3066 (and registry cites RFC 1766), but not using xref. By the way, the DTD *does* allow xref in the abstract. I'm using XMetal Author, so there is no way for me to create invalid XML. > > | 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 > > sufficient. > > 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. [Addison Phillips] No, the website isn't really a spam generator. But we have been conservative in what we placed in our personal profiles. The Inter-Locale address is useful in this context because it hosts various editing copies. > > [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 ;-) [Addison Phillips] I did go through and do the fixes for that. I left the full list since we're not near last call yet. We may have need of various OPTIONAL keywords :-). > > [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 :-) > I was keelhauled and burnt at the stake in a previous draft over this silly issue, so I'm slightly loathe to remove the case distinctions. Besides, look at the registry draft. _______________________________________________ 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.