Subject: RE: [Ltru] Re: Proposed Text for Moving Forward

From: "Addison Phillips" <[email-masked]>
Date: Sun, 17 Apr 2005 16:39:50 -0700

Well, one might register scripts in which a language is never written, I suppose......

The problem is when you name the field something other than suppress (or choose your synonym) and have it give the impression that it is a script commonly used to write the language. Then you get:

Zh (commonly written with 'hant' and 'hans')

And you're counting the fields in order to know whether you should use the script. So if someone registers a second script then you get to retag all of your data (bad).

Suppress's rules as I put them down only said that require trumps suppress  and the require set of subtags must be disjoint from the suppress set. We could allow only one suppress easily enough.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Frank Ellermann
> Sent: dimanche 17 avril 2005 13:07
> To: [email-masked]
> Subject: [Ltru] Re: Proposed Text for Moving Forward
> 
> McDonald, Ira wrote:
> 
> > +1
> > Thanks for some good clear thought for a change.  I agree
> > that I hated this counting the field members approach.
> 
> I still don't get the idea of more than one "suppress_script"
> for the same language, how's that supposed to work ?
> 
>                        Bye, Frank
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 17 Apr 2005 17:28:42 -0700

Hi -

This discussion has cycled a few times, and I'd like to see whether
I understand where we are.  I'm not proclaiming consensus yet,
but just testing the waters, hoping that someone will post a chunk
of text (like the helpful proposals in the "Proposed Text for Moving
Forward" thread) that we can agree to.

1) a general consensus has emerged that the "supress_script"
concept is helpful, though it might be good to find a better name
it.  "implicit_script" has been suggested and found some support.

"default script" is strongly opposed, and seems to trigger ratholes.
We might even belabor the point with something like
"do_not_tag_script". :-) * 0.5

2) there seems to be general support for wording the guidelines
on the use of script subtags fairly strongly, using "MUST ... except"
rather than "SHOULD" and giving clear rationale for why they'd
work the way that is proposed.  An important part of this rationale
is coping with material that has already been tagged, and another
important part of this rationale is the desire to work with existing
matching algorithms.

3) it's less clear to me whether we're getting a consensus on
"require_script".  There were clear cases where a "supress_script"
was needed to prevent implementors from doing the "obvious" (but
undesirable) thing with languages like Yiddish and Gothic.  For
"require_script", it seems that the zh-Hant / zh-Hans cases appear
to be the favored examples.  (Presumably because the non-specialist
wouldn't know that the distinction needs to be made.  However, this
leads to the question of whether the non-specialist who is tagging
material would be able to tell the difference.  Do we care?)

Have I missed something major?

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Apr 2005 03:25:36 +0200

Randy Presuhn wrote:
 
> 2) there seems to be general support for wording the
>    guidelines on the use of script subtags fairly strongly,
>    using "MUST ... except" rather than "SHOULD"

Only "rough consensus" for the proposed "MUST NOT ... unless",
see <http://article.gmane.org/gmane.ietf.ltru:1240> - I'd like
a "SHOULD NOT ..." without "unless" clause better.  Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 17 Apr 2005 20:01:46 -0700

Hi -

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, April 17, 2005 6:25 PM
> Subject: [Ltru] Re: Supress & Require Script
>

> a "SHOULD NOT ..." without "unless" clause better.  Bye, Frank
...

My personal opinion...

There *is* a difference between the construct "MUST NOT x unless Y"
and the construct "SHOULD NOT x".  Any "good reason" Z could be
claimed by an implementor as justification for violating the latter.
In the case of the former, Z would be a justification only if it also
satisfied condition Y.  However, I admit that Y could be so broad as
to render the whole thing logically equivalent to a SHOULD.

More important than technical difference between
the two in this case would be the perception of the strength of the
warning.  If folks want to willfully mis-interpret a specification, that's
their problem, there's little we can do about it.  We can, however,
make the specification painfully clear on the points where we're
particularly worried about mis-implementation, either due to the
likelihood of error or the gravity of the consequences.  It's harder
for an implementor to mistakenly violate a "MUST NOT x unless Y"
than a "SHOULD NOT x", even when a logician might say they're the
same.

As co-chair:  *if* "MUST NOT x unless Y" gets us a rough consensus,
and "SHOULD NOT x" breaks that rough consensus, then the choice
is clear to me, and I'd be willing to defend it if asked by the IESG
whether we're in line with RFC 2119.  But at this moment I'm still trying
to see whether this discussion has converged.

A general question: are we at least agreed that this is a case where
we want the document to give a clear rationale for the recommended
behaviour?

(as contributor):
It sounds like we have several examples where we know
the desired behaviour and how to get that behaviour with supress_script,
where the "naive" implementor would, in the absence of supress_script,
likely do the wrong thing.  Including these examples might be helpful.

If we agree on require_script, we should probably do the same for it.

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 17 Apr 2005 20:44:19 -0700

It sounds to me like we have rough consensus for

suppress_script
SHOULD NOT (but maybe a follow-on sentence or so)
no real need for required_script

‎Mark

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Apr 2005 06:11:28 +0200

Randy Presuhn wrote:

> There *is* a difference between the construct "MUST NOT x
> unless Y" and the construct "SHOULD NOT x".  Any "good
> reason" Z could be claimed by an implementor as justification
> for violating the latter.

True, but in the case of Mark's proposal Y degenerated into a
| unless there is a specific reason

That's even less than my hallucinated "specific and good" Z -
the actual wording in RfC 2199 is "valid reasons in particular
circumstances".  If the "specific reasons" are not specified
a plain "SHOULD NOT x" is clearer than the "MUST NOT x unless
specific reasons".

Debbie had "specific reasons" to add scripts whereever she can.
But she had no valid reasons to violate a SHOULD NOT (talking
about my parallel universe of course, probably not Debbie's).

> More important than technical difference between the two in
> this case would be the perception of the strength of the
> warning.

"SHOULD NOT x" is cut-your-throat-and-then-do-x.  The best
excuse is old software implemented before the SHOULD NOT was
introduced.  Or obvious cases like Web cams operating as HTTP
server which simply have no timestamp for a valid Date: header.
Or using a domain literal if there's no FQDN.

"MUST NOT x unless specific reasons" is fuzzy, for me it sounds
like "do what you like, but it's nice that we talked about x".

It would be very different if the reasons are really specified.

> are we at least agreed that this is a case where we want
> the document to give a clear rationale for the recommended
> behaviour?

The MUST vs. SHOULD issue is the only point where I disagree,
anything else in your two articles is fine for me.  Bye, Frank