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