Re: [Ltru] Remaining issues (59, 61, 63, 62?)

["Martin J. Dürst" <duerst at it.aoyama.ac.jp>]

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