Subject: Re: [Ltru] Re: Supress & Require Script

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 18 Apr 2005 16:07:54 +0200

I do not understand this SHOULD and MUST issue. If I am correct, what we 
mean is:

1. in every case the script, language (region, referent, style) information 
MUST to be given (depending on the role of the tag). Full stop.
2. in some legacy cases, the script is implied and mentionning it may make 
the application break. We have listed the possible implied scripts from 
experience for your convenience.

This is a warning about an old practice. Not a moral case calling for an 
11th commandment?
jfc

On 06:11 18/04/2005, Frank Ellermann said:
>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
>
>
>
>_______________________________________________
>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: Frank Ellermann <[email-masked]>
Date: Mon, 18 Apr 2005 18:03:42 +0200

JFC (Jefsey) Morfin wrote:
 
> I do not understand this SHOULD and MUST issue.

It's explained in RfC 2119:  "they MUST only be used where it
is actually required for interoperation or to limit behavior
which has potential for causing harm".

If en-US won't match en-Latn-US that's harmful.

> 2. in some legacy cases, the script is implied and
>    mentionning it may make the application break.
>    We have listed the possible implied scripts from

> This is a warning about an old practice.  Not a moral
> case calling for an 11th commandment?

It's a case calling for a SHOULD NOT or a MUST NOT.  The
discussion was about using "MUST NOT ... unless specific
reasons" instead of a simple "SHOULD NOT ...".  I'm the
KISS-fan here, I prefer the simple "SHOULD NOT ...".  Bye

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 18 Apr 2005 20:55:16 +0200

Dear Franck,
sorry I mean the whole issue of using an RFC 2119 wording, whatever it is.

>which has potential for causing harm".

Dear Frank,
I mean, I see no "requirement". I just see that there are legacy cases 
(developped before the proposed new format) which can fail (that depends on 
the library being used). So the only thing to do is to warn the people this 
may happen if they add the script when it is not needed.

As far as I understand, the problem should fade away, when new libraries 
are developped. So, the "implicit_script" is only usueful in case there is 
a problem. This is for the writter of a page. Not for the library 
developper, for who supporting scripts is a MUST from now on?

Being presented that way (I understand correct), i.e. just useful decreases 
a lot the pressure on the registry to be accurate. We only say that when 
someone meets a problem he should report it so we can update the list?

>KISS-fan here, I prefer the simple "SHOULD NOT ...".

I understand the discussion,
- what I question is if it discusses adequately the problem you rose and 
support the solution you propose.
- also, as a developper I know what MUST/MUST NOT mean in a C program. I 
have more problems with SHOULD/SHOULD NOT. But this is to be discussed with 
some proposed code as there may be tricks I did not think of.
jfc