Message-Id: <6.2.1.2.2.20050707021758.05455ae0@mail.afrac.org>
Date: Thu, 07 Jul 2005 02:30:53 +0200
To: "Dylan N. Pierce" <dylanpierce@megared.net.mx>,
	Randy Presuhn <randy_presuhn@mindspring.com>, ltru@ietf.org
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Private Use Tags
In-Reply-To: <42CC31E2.6010100@megared.net.mx>
References: <42CB03D4.20801@megared.net.mx>
	<6.2.1.2.2.20050706001224.05117b90@mail.afrac.org>
	<42CC0B62.9030802@megared.net.mx>
	<00bc01c5825a$eadf56e0$7f1afea9@oemcomputer>
	<42CC31E2.6010100@megared.net.mx>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

At 21:32 06/07/2005, Dylan N. Pierce wrote:
>Sounds pretty accurate to me. Remembering that my point of view is 
>generally always tainted by use-case scenarios, you'll have to forgive my 
>tendency to focus on an infinitude of "What if?" hypotheticals when 
>everyone around me merely wants to ship a finished product; that happens 
>at my home company, as well.

Seems you are a good guy for QA.

>Regarding point one, I imagine it's a case of being too close to the 
>issue. Of /course/ we know they're descriptive. But these things are 
>designed to be used by actual people, and people can be picky. I'm sure 
>Mr. Morfin is not unique in that regard. If something as simple as 
>specifying, "These tags are descriptive, not prescriptive, and do not 
>represent a limiting factor in languages or variations an application may 
>support," could head off a perceived slight by the unrepresented, that 
>doesn't seem to be an excessively high cost.

Good start. I think it could do more. But good thing.

>Regarding two, actually, I'm in complete agreement with you; I didn't mean 
>my side trip down that road to be taken as a point of contention with the 
>current draft. Rather, it was more a direct response to jfc's concerns 
>about ever-spiraling artificial languages, to serve as a sort of 
>affirmation that yes, the number of artificial languages will most likely 
>continue to grow, and our job isn't to do anything about that other than 
>design a mechanism which can describe it. I have no argument that the 
>current mechanism seems to fulfill that need.

Here I object.
- it is for human/human only. I do not know what it means nowadays.
- please read at the practical limitations imposed via ISO

>So no, please don't misunderstand me; I'm not campaigning for a complete 
>linguistic analysis in the tag. I'm campaigning for increased 
>compatibility by having a clear, machine-readable way of informing those 
>people who are already taking advantage of private-use tags that the 
>particular private tag they are looking at is in fact the one they meant 
>to look at. That kind of clarity and assurance, I believe, would benefit 
>everyone.

This is called a semantic + vocabulary. This is not complex to achieve and 
there are many ways. But we are here engaged into the RFC 3066 format. The 
Draft wants a more strict semantic. A more strict semantic means more 
possible conflicts. You then reduce the risk in reducing the scope (your 
initial definition). Now, you want to extend the scope in adding reduced 
scopes: this is good as it gives more possibilities while not enlarging the 
risks of conflicts. But you are limited by the format ...

Our approach to that is to say (it was suggested here) we take "x-", reduce 
its constraints and document it. If developers do not support our extension 
it will not work, what is not a problem since our system does not want to 
be compatible in the "x-" part.

We could probably find a compromise. For everyone position to be supported. 
See my other mail.
jfc




_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru