frequent or real-time access to, or retrieval, of the full registry to frequent or real-time access to, or retrieval of, the full registry Regards, Martin. On 2009/06/12 19:54, Martin J. Dürst wrote:
Dear WG members, With draft -23 going to the IESG telechat, we have reached another important milestone in the long jurney of this WG. Thanks to everybody! On 2009/06/12 18:28, Alexey Melnikov wrote:Martin J. Dürst wrote:Dear WG, As you can see, we have a new version of 4646bis, number 23. Please refrain from any comments until I know exactly how Alex wants to proceed from here. In the tracker, issues 59, 61, and 63 are still open, but I hope we can close them soon.I like resolution for issues 59, 61, and 63. Thanks to everybody.This is great news. If anybody from the WG strongly disagrees with how these issues were resolved, please speak up soon. Otherwise, I'll ask Randy to close them. (If you think the wording can be slightly improved, or if you just okay or just can live with the solution taken (and of course also if you like the solution), please refrain from commenting.)Text for 62 in -23 is a big improvement, but I like to add the extra text you suggested. This can be done as an RFC Editor note.For everybody's reference, here's the text that we currently have in -23: To prevent denial-of-service attacks, applications SHOULD NOT depend on either the Language Subtag Registry or the Language Tag Extensions Registry being always accessible. Additionally, although the specification of valid subtags for an extension (see Section 3.7) MUST be available over the Internet, implementations SHOULD NOT mechanically depend on those sources being always accessible. 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 others, being able to validate or canonicalize language tags as of a particular registry date will be sufficient, as the registry contents change 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. And here is the text I proposed to add, in response to Alex's request: First part, to go after the mailing list address: This mailing list is intended for interested organizations and individuals, not for bulk subscription to trigger automatic software updates. The size of the registry makes it unsuitable for automatic software updates. Implementers considering integrating the Language Subtag Registry in an automatic updating scheme are strongly advised to distribute only suitably encoded differences, and only via their own infrastructure, not directly from IANA. Second part, goes at the end: At the time of publication of this document IANA is making the Language Tag registry available over HTTP 1.1. The proper way to update a local copy of the Language Subtag Registry using HTTP 1.1 is to use a conditional GET [RFC2616]. RFC 2616 will have to be added as a reference. The overall text (with an additional paragraph break) would look as follows: To prevent denial-of-service attacks, applications SHOULD NOT depend on either the Language Subtag Registry or the Language Tag Extensions Registry being always accessible. Additionally, although the specification of valid subtags for an extension (see Section 3.7) MUST be available over the Internet, implementations SHOULD NOT mechanically depend on those sources being always accessible. 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 others, being able to validate or canonicalize language tags as of a particular registry date will be sufficient, as the registry contents change only occasionally. Changes are announced to <ietf-languages-announcements at iana.org>. This mailing list is intended for interested organizations and individuals, not for bulk subscription to trigger automatic software updates. The size of the registry makes it unsuitable for automatic software updates. Implementers considering integrating the Language Subtag Registry in an automatic updating scheme are strongly advised to distribute only suitably encoded differences, and only via their own infrastructure, not directly from IANA. 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. At the time of publication of this document IANA is making the Language Tag registry available over HTTP 1.1. The proper way to update a local copy of the Language Subtag Registry using HTTP 1.1 is to use a conditional GET [RFC2616]. As above, please speak up if you can't live with this text (both the part that's already in and the new additions which will be handled by an RFC Editor's note), but otherwise, please refrain from posting. On this issue, the current resolution in the tracker is different from what we have in -23. Randy, can you please update the tracker? Regards, Martin.
-- #-# 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.