Message-Id: <6.1.2.0.2.20050117204327.07aa36a0@mail.jefsey.com>
Date: Tue, 18 Jan 2005 01:52:48 +0100
To: "Peter Constable" <petercon@microsoft.com>,
	<ietf-languages@iana.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <F8ACB1B494D9734783AAB114D0CE68FE04C8E647@RED-MSG-52.redmon
	d.corp.microsoft.com>
References: <F8ACB1B494D9734783AAB114D0CE68FE04C8E647@RED-MSG-52.redmond.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed;
	x-avg-checked=avg-ok-3D417088
Cc: 
Subject: RE: language tag structure
Precedence: list
Sender: ietf-languages-bounces@alvestrand.no
Errors-To: ietf-languages-bounces@alvestrand.no

Dear Peter,
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
>finding a
> > 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
>linguistic attributes.

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 
architecture generations.

>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.
>How
> > do you want the "I [hart] NY" or the smileys to be read by a web
>service, a
> > 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"
>or "SUV").

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 
vernacular usage.

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.

jfc

_______________________________________________
Ietf-languages mailing list
Ietf-languages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages