Message-Id: <6.2.3.4.2.20050912011545.05340ea0@mail.afrac.org>
Date: Mon, 12 Sep 2005 04:08:53 +0200
To: ltru@ietf.org
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] a question I received
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: iesg@iesg.org
Precedence: list
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

I am asked what this has to do with the Draft. I just try different 
ways and help to explain why the langtags defined by the Draft are 
not end to end. Two key informations are not in the proposed format 
(referent and context) nor is the date for comparison with registry. 
Many other sub-informations are also not transported from the 
author's end to the reader's end.

If the WG standadisers do not see it, users do. Users are most 
probably more literary oriented people (authors, sales, newsmen, 
artists and site designers, etc.), trained/informed by people of some 
education, probably not using English (they less need langtags). 
Having another user (not what Peter Constable calls an "end user") 
sharing with me the need to use langtags in a heavy and delayed 
applications, could be a real help for me to document why the Draft 
does not deliver what _we_ (users) need and expect.

Non-English mother tongue literary academics are the typical 
"affected parties" (like me and my organisation) the Internet 
standard process (RFC 2026/1.2 is quoted here) wants to consider the 
needs, within the framework of the widespread community consensus, 
and to serve with specifications of high quality in spite of the 
difficulty of evaluating the utility of particular specifications for 
an Internet community (where English is a minority language: 61.6% of 
the Internet users do not speak English). The WG takes users needs as 
an opposition, and wants to impose on us/them a commercial scheme we 
do not trust and which does fit the bill. Before addressing our needs 
ourselves as suggested by John, I make a last try.

If I review the proposed deliverable as one of its future users and 
along the RFC 2066/1.2 criteria:
- of  technical excellence: the ABNF is improved, the "0-", we need 
to support all what the ABNF does not provide, is still missing.
- with a prior implementation and testing. We cannot test: a simple 
reading shows that it does not provide our needed 5 elements.
- with clear, concise, and easily understood documentation. hmmm. A 
long text to impeach the resolution of our needs.
- with openness and fairness - IMO that part is not achieved yet!
- and timeliness. I am sorry but all this is overdue when compared to 
market's needs and expectations. This is why we need to stop 
disputing the details of a now cleaner but low interest ABNF (if it 
is not much used it is not because it was poorly defined. It was 
because it is a provider's solution and it does not fit the users 
needs. The provider's end has the missing elements it cannot 
transport to the receiver's end. The langtag protocol is only of use 
when the information it does not transport is not considered.

jfc


>On 15:17 11/09/2005, r&d afrac said:
>>I received the following from a WG Member (I rephrase it by 
>>netiquette, because it might disclose the author):
>>
>>" http://news.bbc.co.uk/2/hi/uk_news/magazine/4172085.stm
>>Do you know if there is another non-English mother tongue Member 
>>with litterary accademic background in this WG?"
>>I never asked.
>>
>>jfc
>>
>>
>>
>>
>>_______________________________________________
>>Ltru mailing list
>>Ltru@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru