Subject: Re: [Ltru] prefixes for date variants

From: "Doug Ewell" <[email-masked]>
Date: Wed, 6 Sep 2006 23:29:27 -0700

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> I think the correct response to our problems here, as Mark pointed 
> out, is to REMOVE the validation requirement of checking the variant 
> prefix. Checking the prefix fundamentally means that no prefix can be 
> added to a variant in the future (since existing validating tag 
> processors will reject the new tags). That is bad. This change would 
> reduce variant prefixes to their intended behavior (which is 
> informative).

Existing tag processors will reject the new tags only if they are 
utilizing an outdated copy of the Registry.  Such a processor would also 
reject the now-valid tag "zza" if its copy of the Registry is older than 
2006-08-29.  The same situation applies to variant prefixes.

We could remove the validation requirement in Section 2.2.9 and still 
leave the passages in Sections 2.2.5 and 3.1, which use words like 
"suitable" and "appropriate."  This would put the use of variants with 
non-recommended prefixes into the same moral category as deprecated 
subtags and explicitly specified Suppress-Scripts, which feels like the 
Right Thing.

> "Date" variants, like any other semi-generic variant, can therefore 
> acquire new prefixes. I think there are shades of "redefining meaning" 
> that are being advised against above (and note that the text says that 
> the redefinition will "probably" be rejected, not a guarantee or 
> requirement that it be rejected).

I believe the use case we had in mind at the time was indeed something 
like "western", and the premise was that it would be virtually assured 
of rejection.  I could try looking this up in the archives.

At the very least, I think we should not go searching for variants that 
can be reused.  If a scenario for reuse should materialize, like the 
Great Zaza Spelling Reform of 1996, then so be it.  But I for one am 
glad that the Armenian variants have been changed to apply narrowly to 
Armenian.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
Editor, draft-ietf-ltru-initial

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 7 Sep 2006 09:07:59 -0700

Hi -

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, September 06, 2006 11:29 PM
> Subject: Re: [Ltru] prefixes for date variants
...
> 2006-08-29.  The same situation applies to variant prefixes.
...

A reminder - the registry draft says:

   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 it being always accessible, to
   prevent denial-of-service attacks.

Consequently, as a technical contributor I think "utilizing an outdated copy"
should be considered an extremely likely scenario.  Furthermore, it may be
worth thinking about when (if ever) a validating processor is really needed.

Randy

---

From: John Cowan <[email-masked]>
Date: Thu, 7 Sep 2006 12:11:34 -0400

Randy Presuhn scripsit:

> Consequently, as a technical contributor I think "utilizing an outdated
> copy" should be considered an extremely likely scenario.  Furthermore,
> it may be worth thinking about when (if ever) a validating processor
> is really needed.

A validating parser will be useful in validating a process's output
(be conservative in what you send) rather than its input (be liberal
in what you accept).

-- 
There are three kinds of people in the world:   John Cowan
those who can count,                            [email-masked]
and those who can't.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Sep 2006 18:18:14 +0200

On Thu, Sep 07, 2006 at 12:11:34PM -0400,
 John Cowan <[email-masked]> wrote 

> (be conservative in what you send) rather than its input (be liberal

Since I plan to start a validating parser soon (tm), I'm puzzled. What
does "being liberal" means when processing input language tags?

Imagine that a process receives uk-Latb-UA. It is well-formed but not
valid (typo in the script). I presumed that the sender of this tag
would prefer to receive a message "Invalid language tag (subtag Latb
is not registered)" rather than "No document found". Don't you agree?

---

From: Peter Constable <[email-masked]>
Date: Thu, 7 Sep 2006 09:34:11 -0700

A validating parser when a developer is creating tags for use in some
implementation -- there is no immediate DoS scenario, and they'd get
warned of the need to check tags that may not be conformant.

Peter (two of those who claims he can count :-)

> -----Original Message-----
> From: John Cowan [mailto:[email-masked]]
> Sent: Thursday, September 07, 2006 9:12 AM
> To: Randy Presuhn
> Cc: LTRU Working Group

---

From: John Cowan <[email-masked]>
Date: Fri, 8 Sep 2006 14:26:01 -0400

> is not registered)" rather than "No document found". Don't you agree?

I certainly don't reject this view.  I don't know how to decide, without
a particular case, whether the benefits of improved error reporting
improve the costs of validation.

For myself, I primarily think in terms of a publish-subscribe rather
than a client-server model, where a document tagger neither knows nor
cares exactly who will consume the document, but is concerned that it
be correct.

-- 
No,  John.  I want formats that are actually       John Cowan
useful, rather than over-featured megaliths that   http://www.ccil.org/~cowan
address all questions by piling on ridiculous      [email-masked]
internal links in forms which are hideously
over-complex. --Simon St. Laurent on xml-dev

---

From: Martin Duerst <[email-masked]>
Date: Mon, 11 Sep 2006 18:52:11 +0900

>is not registered)" rather than "No document found". Don't you agree?

Yes, but this looks like purely a quality of service issue.
It would be a bad idea to require a protocol to do this.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]