language tag structure
JFC (Jefsey) Morfin
jefsey at jefsey.com
Tue Jan 18 01:52:48 CET 2005
You try to make the point that my approach includes additions to the
Draft-Philips-languages-08.txt. This is its very "raison d'être". I would
suggest that these additions should be discussed on a dedicated list or at
an IETF WG to set-up.
At 20:19 17/01/2005, Peter Constable wrote:
>The term "encoding" is *not* conventionally used to refer to the script
>used for writing texts, and is certainly not what I was referring to
>when I said we don't want to describe encoding format.
True. I and this is not the way I use it.
>You haven't documented a need. You have asserted there is a need. You
>have not given any usage scenario describing how distinctions of the
>kind you're suggesting would be used.
You confuse my purpose with yours.
I only document a tagging to permit this distinction (missin
Draft-Philips). I discuss a network architecture information document, not
an application related BCP. Usage scenarii are out of my scope: the target
is to free the users not to bind them.
> > OK. I understand that you see no other flaw in my approach than
> > correct wording for an extended script concept.
>!! You cannot obtain consensus by putting words in others' mouths. See
>no flaw? I just finished objecting to several things that you say you
>want to have encompassed by "script". It is a flaw, for instance, to mix
>a data category like file or encoding format in with a data category for
This would be true if your reading had been in tune with what I meant.
>Also, I agree with John that we are not documenting language
>authorities, and that companies such as Microsoft are not language
>authorities. Perhaps your intent is something other than what "language
>authority" suggests to us in English -- an agency that has been
>identified at a societal or governmental level as having authority to
>define policies, conventions and best practices regarding language
>definition and usage.
I am afraid this is supposed to be IETF here. In network architecture and
cultural areas, "authority" means "who is authoritative". It is a key
architectural issue. Its understanding differentiates the nework
>On the other hand, if your intent is simply to describe a conventional
>usage defined within some domain -- e.g. spelling and lexical
>conventions for French used within ISO -- then I think that's an
>acceptable thing to include in a language tag. But I would not refer to
>that as "language authority"; it's a domain of usage.
This is a correct but limited vision (however "for French used within ISO"
does not fit, "for _a_ French used within ISO" would be better but I do not
understand what "within ISO" may mean). If you want two web services to
interelate you cannot expect them to use a "conventional usage", you need
them to share a common language context documented by an authoritative
source they both accept by convention. Interintelligbility cannot directly
result from usage (unless there is a long learning period between AI
systems, but then these systems will become authoritative for them).
> > We also have a lot hieroglyphs being accepted in the day to day life.
> > do you want the "I [hart] NY" or the smileys to be read by a web
> > scanner, etc. if you do not document the forms.
>An icon of a heart is not part of the written form of English; it is an
>icon with a metaphoric meaning. (And in the case of that particular
>metaphor, one that spans many cultures and languages; e.g. one could
>also have written "J'[heart] Paris".)
Absolutely. This is a scripting widely used language extension.
>The use of icons within text is
>not generally conventionalized (though the icons themselves may be) --
>there are not established conventions that can be given identities by
>which (say) an iconic image of a telephone handset can be inserted
>within text to mean "call by telephone", or images of an automobile can
>be inserted within text to mean "automobile" (or "sedan" or "sports-car"
Peter, I am not limited by what is formally conventionalized by some other
standard. I am interested in what I am to document to support real life
In addition to that, I noted that I was unable to study ISO 7000 which
might address some of your concerns?
>We might want to have a subtag along the lines of "rebus" to
>tell us that the text contains some icons in lieu of words; e.g.
>"en-rebus" for "I [heart] NY"; but I can't see making finer distinctions
>than that unless there are identifiable conventions.
Draft-Philips-... does not supports this. So I do not feel I must support
such additional distinction in its way. If that was a need, it would be new
and to be considered.
>Note that a subtag like "rebus" would not represent anything new that
>could not be accommodated by RFC 3066bis.
Proposed RFC 3066 revision please. This is true. The flexibility of an IETF
RFC for information is that there is no problem in adding thousands of
scriptings descriptions to fit vernacular needs if necessary. There would
be a problem if you wanted to support them differently (i.e. adding to your
own requirements). Common sense calls for ISO 15924 to initially be used.
But this is just a default list.
More information about the Ietf-languages