From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of "Martin J. Dürst"
That text looks OK to me.
>> 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 also 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.
> >>>>
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.
>>> 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.
That seems reasonable, and I think the text you suggested covers the key issues.
> 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.
Peter
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.