Message-Id: <6.2.1.2.2.20050730162947.0398c580@mail.afrac.org>
Date: Sat, 30 Jul 2005 17:04:36 +0200
To: "LTRU Working Group" <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use
  tags
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

Dear Martin,
The problem is simple: this document claims for an exclusive it does not 
support. Exclusive is acceptable if it warranties liberty, stability, 
innovation capacity, equal opportunity for all. Oherwise it is exclusion.

You both acknowledge the right to liberty and you deny it. What is 
interesting is that you do not even ask yourself about the oddity of 
writting a "BCP" opposing documented use and running code. Are you not 
afraid looking a fool when you will be opposed commercial catalogs during 
the IESG last call and appeals ...

At 09:00 30/07/2005, Martin Duerst wrote:
> >At 14:28 29/07/2005, Erkki Kolehmainen wrote:
> >>re your note of 28.7.2005 to Doug Ewell, the following quotation is to 
> me an undisputable hard fact:
> >>  No private-use scheme can ever assure that it will not conflict with 
> another private-use scheme.  That is why they are private! [DE]
> >
> >This pure non-sense!
>
>No, it's not.

Such affirmation should be documented as I did it. Saying that my (correct, 
read ISO 11173, I know ...) example is incorrect proves nothing.

> >The fact that they are private and they permit conflict are orthogonal. 
> I will take a simple example: Domain Names are private yet they cannot 
> conflict. Because we organised the name space for that. As I indicated 
> (and documented) there are many ways to specify the organisation of the 
> "x-" name space so it is both private and conflict free.
>
>Domain names are not private. There is, as far as I know, no 'private use' 
>domain in the global DNS. There are domains that are delegated, to CCTLDs, 
>to organizations, and so on, and within these, these entities may further 
>delegate. That's not at all the same as private use.

Please then define "private use" if not free usage within a private zone 
namespace (IETF) or value domain ISO?

>Private use, in the DNS, would mean e.g. that a .private domain is created,

????

>where anybody could input their own subdomains without a central check.

Central check ??? I am a ccTLD Registry Manager. I  impose no constraints 
on the registrants I serve except protocol's hexatridecimal. It is true we 
are to work very hard to correct, in the field, the impraticalities you 
(partly unwillingly) co-imposed us through IDNA...

>Two different entities could both create mydomain.private. In DNS, this is 
>of course possible in local experiments (so it's truely private), but
>not in the globally visible DNS.

Yes. This is why a domain name can be used as a unique identifier in an 
item scheme (ISO 11 ... I know)

>If you want careful delegation for language tags, then what you need to do 
>is to create some careful proposal and apply for a one-letter prefix
>(other than x).

"Delegation" is a Mokapertis' concept to manage the academic havoc he had 
to connect to "my" naming system. I never delegated anything to ARPA: I 
said "ARPA" is what you want?  there is no one else yet using it?  Vida, 
please register it so others know where they are. And Vida Stafford nicely 
did it, as she managed all the other "TLD"s for years.

What you are describing here is an ICANN dream, or a left-over of the 
Legacy Days.

What I say is simple (and would think the author of docs on URI would 
understand it). It is:

1. To warranty the possibility of non conflicting private use you can:
- either organise it
- or permit others to organise it.

2. If you want to know how this is going to be organised, you look at what 
is a (item) scheme (ISO 117... I know, but aslo some RFCs) and you go by 
the book. Now you can create your own language-scheme registry or you can 
accept existing unique IDs as roots for these schemes.

> >I am only sorry that you comment Doug remarks and my remark on its 
> proposition, rather than the answer I made Doug requested.
>
>Last call is not about having questions answered, it is about making
>comments, usually with concrete suggestions for improval.

Doug challenged me to show his solution could not fit the need. I shown it. 
The ball was in his field. I see he sent it out.

> >I understand why, but so will IETF/IESG/IAB/GAC/WTO/IANA. I would be 
> interested in your comment on the problem rather than a repetition of 
> your ideas.
> >
> >>... and the following highly commendable:
> >>  The scheme proposed in the current draft does prevent conflicts with 
> existing parsers that conform to RFC 3066. [DE]
> >
> >The "highly commendable" is an odd hyperbole. It is correct, or it is not.
> >
> >It is correct only if private use is removed from RFC 3066. The current 
> draft does NOT prevent conflicts with existing parser that conform to RFC 
> 3066 in the private area. This is precisely this claim which is wrong, 
> which is objected by  the previous claim above (you cannot say both: 
> there will always be conflicts and at the same time you prevent 
> conflicts). This reality is not an enhancement called by the Charter.
>
>The above sentence refers to syntactical conflicts. The earlier sentence
>refers to usage conflicts. These are different things.

:-) No big deal, but even a lawyer would turn me right on this one. Reread it.

> >We are here in a search of a consensus. So, we are not really interested 
> in what you support or not: we are interested in what to do for both of 
> us to agree.
>
>To be exact, rough consensus. This does not mean that everybody has to agree.

Bravi for the exclusensus!
JFC wants to agree with everyone, why would we care?

> >I said the two simple things for that:
> >
> >1. not to claim to replace RFC 3066. I do not make it a critical point 
> for the user community however. RFC 3066 is an error. Replacing an error 
> by another error is no big damage. It is however critical for the IETF to 
> decide if it will document the Multilingual Internet or not, as no 
> serious non-US industry aficionado will use that system. We are making 
> IDNA again. Your decision, at the end of the day I am not concerned. I 
> think Harald documented enough, and Brian Carpenter's responses and 
> attitude seem to confirm, and this WG-ltru main topic of interest 
> documented it: IETF is simply not able to understand the problem and 
> should not get into it.
>
>I think there are three different goal that one may look at:
>
>1) a system that allows everybody to use their language(s)
>2) a system that allows to tag any language in use, in a way for others 
>(humans and systems) to determine that language
>3) a system that allows anybody to create tags they personally like to tag 
>any language

This could do, but I will note that the wording implies a vision 
(disrespect IMO) of others I object. This is not an ethical arena, so I 
will not dispute it, but this has technical implications. There are many 
things these goals overlook: in what do you think this wording is IETF 
specific and could not be ISO or Leonardo da Vinci's?

This is typograph language, not networking standardiser.

Let phrase it another limited way you should be able to accept:

1) a system supporting end to end interoperability (what you would probably 
call internationalisation)
2) a system supporting brain to brain interintelligility (what you would 
probably accept to call multilingualisation)
3) a system supporting community interculturation (what you will probably 
object if I call it vernacularisation)

I use "supporting" because you do not refer to tags in (1). I do not refer 
to language because I do not know what a language is, nor a text, nor a 
character, nor a script, etc. in a computer network environment. I will 
take a single example. Script means to scratch the medium to memorise
a part of the content (stone, clay, paper, etc.) to be read by human. Today 
script (and this is your main problem) means a form of temporary 
representation to help the reading through a machine assistant and which 
belong to the content's "architext" (technical source of the text) attributes.

>1) is mostly possible now (with the exception of some languages for
>    which scripts or letters are not yet encoded, which is an extremely
>    low percentage of users, and is being worked on (mostly by the
>    Unicode consortium))

! most of the language are oral.

I an not interested in Unicode consortium here (however I am a paying 
member of it). It is only concerned as in support of ISO 10620 and 15924. 
Unless you consider CLDR? CLDR is certainly a contentious political and 
commercial point. But CLDR is only quoted in Charter. And its boss refused 
to document it and its Copyright policy.

This affirmation shows also a deep lack of information of the matter 
considered (for external future readers).
- today a few hundred languages are documented
- there are 7500 plus extensions in ISO 639-3 and 20.000 in ISO 639-6.
- difficult to discuss since the language concept is not defined - even by 
your WG's draft, and ISO 639-4 is not published.

>2) is what this WG is about. With all the extensibility, my understanding
>    is that we have a very good base.

We do not discuss the base in here. We discuss the semantic of the tag 
permitting its use. This tag wanting to be exlusive is built according a 
non acceptable scarcity not permitting an elementary support except in 
accepting the dominant publisher default context as a forced reference.

You can have any color if it is black.

>3) may be what you want. It may sound great, but it's not helpful
>    for interoperability, and it's not a goal for this WG (although
>    with private tags, it's actually possible with the current draft).

Incredible!

- "it sounds great" but a absurdity about interoperability .... did you 
simply read the filtering part???
- "this is not a goal for this WG" so I fordide it forever for the Internet
- "it is actually possible" (what means it is legitimate) this is why I 
make sure it is not practically feasible.

>There is of course nobody claiming that it is forbidden to anybody to
>create language tags (or any other tags) to their liking. But

Incedible!

Yes, there is one: you!
You make sure that this is forbidden to anyone through the sentence 
"replacing RFC 3066". Or in refusing to consider the last call text I 
propose if you want to keep that sentence.

> >I think that if this is the attitude, some wording should be reviewed by 
> the authors, to protect their future pride.
> >2. no to use a joke to exclude the real world. This joke uses  two 
> elements: "x-" and "8alpha". They are orthogonal. There can be three 
> responses to that:
> >
> >- either to make "x-" free from limitations. You oppose: it is not 
> compatible to RFC 3066. I say I do not care (I am the user) but you want 
> to force me to do what you want. For my good sake, so I stay compatible 
> with the past I never had.
>
>You are not *the* user. You are one of many users.

funny.
Future readers please note the contempt for the user I am and the users I 
defend and represent for 27 years. Hopefully we went through some other 
cases like that :-)

> >- either to create "0-" as a new zero constraint area. This has no 
> problem of retrofit.
>
>Is it allowed by the RFC 3066 grammar?

? I do not understand what the RFC 3066 grammar has to do with the 
_addition_ of an escape sequence. ????

> >The only opposition could be that the authors lose their grip on 
> language tags and industry. But they claim they are not commercially and 
> politically biased. So there is definitely no problem.
> >
> >- either to keep the existing text to make sure it will probably never 
> be used. The inconvenience for some will certainly be real, and the load 
> imposed on us to oppose will be heavy. But the protection granted to many 
> many more is worth it. All the more than Liberty does not mean for us to 
> win anytime soon, or even to win. Just to delay the mistake until the 
> better solutions we work on have taken off and the existing other 
> solutions which are not aware of the threat have been informed (I note 
> that since this Draft claims to be compatible with RFC 3066, nothing 
> impeach the W3C to make it a W3C document tomorrow, or the IESG to make 
> it a complement to RFC 3066 as we propose it).
> >
> >I would not want to be in Randy and Martin shoes today. "0- or not 0-"
>
>I'm wearing sandals today, and am feeling well in them :-).

For further readers, please note that Mercurio wore scandals with a typo 
today :-)

Fun apart, you decide or yourself. I suppose you want to have your final 
text ready for August 2nd, last time. Beware that with the Draft editor 
delays, you are now turning late.

Just tell us when the Last Call over, so I can work on its statistics.
jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru