[hats on]I have counted five people (this includes Randy, who commented on the general agreement with the need of doing something here in private) in favor of adding the two text pieces below, and nobody against.
I would like to ask the editors to integrate these texts into the newest version of their draft, and Randy to close this issue.
Regards, Martin. On 2009/06/10 1:51, Phillips, Addison wrote:
(as contributor) +1. Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. From: mark.edward.davis at gmail.com [mailto:mark.edward.davis at gmail.com] On Behalf Of Mark Davis Sent: Tuesday, June 09, 2009 9:27 AM To: Peter Constable Cc: "Martin J. Dürst"; Phillips, Addison; Alexey Melnikov; LTRU Working Group Subject: Re: [Ltru] Issue #62: (AD #14) DoS potential (was: Re: AD issue #14 (DoS potential) Additional issues with 4646bis raised by an Apps Review Team review) I agree with Peter. Mark On Tue, Jun 9, 2009 at 09:20, Peter Constable<petercon at microsoft.com<mailto:petercon at microsoft.com>> wrote: From: ltru-bounces at ietf.org<mailto:ltru-bounces at ietf.org> [mailto:ltru-bounces at ietf.org<mailto:ltru-bounces at ietf.org>] On Behalf Of "Martin J. Dürst"Although the specification of valid subtags for an extension (see Section 3.7 (Extensions and the Extensions Registry)) MUST be available over the Internet, implementations SHOULD NOT mechanically depend on it being always accessible, to prevent denial-of-service attacks. -- This should also address the IANA registry. I think that's an oversight. I actually thought it said both.Okay. Here is proposed text for insertion just before the currently last paragraph in section 6: Although the Language Subtag Registry and the Language Tag Extensions Registry are available over the Internet, applications SHOULD NOT mechanically depend on it being always accessible, to prevent denial-of-service attacks.That text looks OK to me.I agree that there is no evidence that a language tag implementation currently does frequent downloads. But there is evidence for other cases of frequent downloads, where the frequency of changes is way smaller or non-existent. I therefore suggest to continue the text I proposed above as follows: The registries specified in this document are not suitable for frequent or real-time access to, or retrieval, of the full registry contents. Most applications do not need registry data at all. For the others, being able to validate or canonicalize language tags as of a particular registry date will be sufficient. Also, the registry contents changes only occasionally. Changes are announced to ietf-languages-announcements at iana.org<mailto:ietf-languages-announcements at iana.org>. Changes, or the absence thereof, can also easily be detected by looking at the File-Date record at the start of the registry, or by using features of the protocol used for downloading, without having to download the full registry.That also looks OK to me.It might also be worth discussing how the registry format facilitates "diffing" 2 versions of the registry.It's possible, although once you've parsed the new registry, the diff doesn't matter so much. Note that stability rules generally prevent breaking changes.I think what Alex means is that the diff would significantly reduce the amount of data that needs to be downloaded to update the registry to a new version.But if we're directing implementations not to do real-time automated downloads, then it seems that the amount of data shouldn't be that much of an issue.Overall, I agree that we have discussed this issue before, but I also understand that Alex is concerned, probably not only by himself, but also about the fact that his fellow IESG members might easily bring up this issue as a "discuss". So I think it's better to have it clearly documented in the security section.That seems reasonable, and I think the text you suggested covers the key issues. Peter _______________________________________________ Ltru mailing list Ltru at ietf.org<mailto:Ltru at ietf.org> https://www.ietf.org/mailman/listinfo/ltru
-- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.