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

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

Done.  At this time, there are no open issues in the
issue tracker.

Randy

----- Original Message ----- 
From: "Martin J. Dürst" <duerst at it.aoyama.ac.jp>
To: "LTRU Working Group" <ltru at ietf.org>
Cc: "Alexey Melnikov" <alexey.melnikov at isode.com>
Sent: Tuesday, June 16, 2009 1:01 AM
Subject: Re: [Ltru] Remaining issues (59, 61, 63, 62?)


I haven't received any mails disagreeing with these issues, so I would
like to ask Randy to close issues 59, 61, and 63 with the resolutions in
draft -23, and to change issue 62 to a resolution of adding new text as
below, with the change of

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
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru