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

From: "Addison Phillips" <[email-masked]>
Date: Wed, 15 Jun 2005 09:15:54 -0700

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Jun 2005 20:52:15 +0200

Addison Phillips wrote:

 [editors as contributors]
> No, they don't usually do so. But in making a list, one

This must be one of these cultural things, like voting for
yourself.  Some say that not voting for yourself shows that
even you are afraid that you might be incompetent.  Others
say that you're obviously biassed, and therefore you should
abstain.  Unless it's a tie.  Or whatever.  <shrug />

 [DoS attack]
> mentioned in the matching draft, IIRC.

| 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.

So far I thought that this statement is about the registry, if
it's not, what else does it mean in the context of "matching" ?

 [privacy]
> The privacy issue really pertains to tracking the requests
> people make and those are expressed as ranges.

ACK.

> I'm still putting in the formulation "tags and ranges"

Okay.

> there was much rejoicing. Not only will I have to reorder
> this draft, but also the registry draft.

If you have good reasons for another order, ready for a reply,
then this order is still only a recommendation in an expired
draft - they also don't like numbered references.  Somewhere
you can draw the line and say "enough is enough".  I'm not
sure where, the LEO dictionary offers "running the gauntlet"
for "Spiessrutenlaufen".

>> <abstract>.  It's also a rule in the expired 2223bis-08 4.5

> Both documents cite RFC 3066 (and registry cites RFC 1766),

That is okay.  But you still had a "[11]" and a "[19]" in the
matching-02 abstract.

> 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.

Oops, yes, sorry, I stand corrected.  It was only an effect I
got for enabling <?rfc strict="yes" ?>

Maybe try the online id-nits Web service for such nits, its
author told me that he does NOT check the recommended order
of the sections (not a promise, only a statement :-)

<http://ietf.levkowetz.com/tools/idnits/idnits.pyht>

It doesn't work for old Netscape browsers, but for Lynx 2.8.5
or Firefox (tested by somebody else) it's fine.  Bye, Frank