Subject: [Ltru] Re: prefixes for date variants

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Sep 2006 23:17:22 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

>> It's true that processors are not expected to go out to the IANA site 
>> and download a new Registry on every usage.  (This isn't necessary 
>> anyway, since an application can check if its copy is up-to-date by 
>> retrieving the File-Date record from IANA -- only 23 bytes, including 
>> CRLF -- and comparing it with the local copy.)
> ...
>
> As a technical contributor...
>
> If this is how folks understand the words that are there, then we need 
> to make the language much stronger in the update. When an application 
> accesses the registry using HTTP, a lot more than 23 bytes worth of 
> load will be inflicted on IANA's infrastructure, which is why we put 
> the SHOULD NOT language in.  The DoS that matters, after all, is the 
> attack on IANA that such an application would inflict.

The load is far less than 630,000 bytes, the projected approximate size 
of the 4646bis Registry.

> Alternatively, if the WG really believes there will be wide-spread use 
> of validating processors requiring current registrations, then I 
> suggest we might need to reconsider the use of more robust 
> technologies, such as those discussed in conjunction with issues like 
> #893, #965, and #968. (https://rt.psg.com, user and password "ietf")

My tag generating and validating app (which I'll make available in the 
next few days, now that the RFCs are published) uses a local version of 
the Registry, packaged as a Windows DLL.  I update the DLL every time 
the Registry is changed, and plan to supply the updated DLLs to users 
for free.  That seems to me a reasonable distribution method that takes 
some degree of burden off the IANA site.

I wouldn't be opposed to discussing incremental updating methods of the 
type Randy referred to.  We created a Registry so that users could have 
a single, uniform repository of all valid subtags.  Having an up-to-date 
copy of the Registry is something that should be encouraged.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  •  UTN #14

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Sep 2006 23:21:58 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

> Congratulations, even if the most important part had to disappear upon 
> publication.  :-)

I still think we should investigate whether a new, huge RFC that will be 
chopped down to 7 pages before publication is the best way to deliver 
the new 4646bis data to IANA.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 09 Sep 2006 11:00:01 +0200

Doug Ewell wrote:
 
> we should investigate whether a new, huge RFC that will be
> chopped down to 7 pages before publication is the best way
> to deliver the new 4646bis data to IANA.

Short RFCs are okay, compare RFC 862 (STD 20).  For some time
I thought that another way would be better for the bulk update,
because it's huge, and the Last Call for RFC 4645 triggered
only two reviews (Bruce + JohnK).

But since Peter proposed to deprecate zh-min as special case,
maybe "4645bis" is the best place to handle such exceptions.

We could ask IANA what they prefer, 6000 update templates in
a file, 6000 registry entries in a file, or 6000 entries in
a "4645bis".  If they don't care managing cruft like zh-min
in a separate "4645bis" instead of "4646bis" could make sense:

Readers of 4646bis are probably not interested in this detail.

Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 9 Sep 2006 16:20:53 -0700

Hi -

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Friday, September 08, 2006 11:21 PM
> Subject: [Ltru] Re: Fw: RFC 4645 on Initial Language Subtag Registry
...
...

As a technical contributor -

Based on how the last round went, I think the WG's decision to
use an internet draft was correct.

I think the WG's decision to publish to send that material through
the RFC publication process was also good, inasmuch as it did elicit
useful comments, and gave us the requisite paper trail to deal with
real or imagined procedural problems.

I think the final decision to elide the interesting parts was
perhaps unfortunate, but also understandable, given the onslaught
the IETF has been suffering.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 9 Sep 2006 16:45:04 -0700

Hi -

> Sent: Friday, September 08, 2006 11:17 PM
> Subject: [Ltru] Re: prefixes for date variants
...
> Having an up-to-date 
...

As a technical contributor, I believe this would be a grave mistake,
unless we *severely* qualify what is meant by "user."  I believe that
vast majority of users have no need whatsoever for language tag validators.
Normal users should never even see language tags, much less be creating them.
Language tags used in protocol should be put there by software as a result
of other user choices.  I think the only folks who should be using tag
validators are the developers of applications which generate language tags.
These are hardly typical "users".

Randy