From: 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. 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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.