So, I have nothing against nothing. But what is clear should preferable be clearly described to be clearly understood by the proper person. From what I gather, we agreed that "default" was not the proper idea, because if there was nothing, there was no script. Implicit convey the correct idea. However from what I also gather, we want to teach developers not to use the script in that case.
As a developer I understand "implicit" as something which is here if it is here, but there is no harm in adding anew (by security). I understand "redundant" as something which creates a waste of cpu resources, confusion or may be even, security leak. So I am more careful.
But I also understand that someone registering a tag may see it otherwise. "implicit" is then more neutral, working for both. It is also shorter.
jfc At 14:34 16/04/2005, Peter Constable wrote:
> From: JFC (Jefsey) Morfin [mailto:jefsey at jefsey.com] > As a non English speaker I more or less understand the English of > "Suppress_Script" because I know its history. I am not sure an occasional > developper will understand/remember the meaning of it. Unneeded, needless, > redundant_script would be clearer to me. Keep in mind, we do expect someone to have at least glanced at the RFC. But if "Suppress_Script" really doesn't communicate well enough, then what about "Implied_Script" or "Implicit_Script"? A side note: In a paper I wrote three years ago, I had a section entitled "Default values and implicit tagging", discussing specifically the issue of script subtags. I find it interesting that we started with a suggestion of a field called "Default_Script" and have now come around to a suggestion that it be called "Implicit_Script". FYI, here's an excerpt from the end of that section of that paper: <quote> The choice of whether or not to adopt the use of implicit default semantics amounts to a trade-off between simpler tags and compatibility with existing implementations on the one hand, and identifiers with more predictable forms, more predictable semantics, and therefore no need to maintain a database of implicit relationships on the other hand. </quote> Peter Constable _______________________________________________ Ltru mailing list Ltru at lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________ Ltru mailing list Ltru at lists.ietf.org https://www1.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.