On 17:21 25/03/2005, Markus Hofmann said:
Folks,
just checking - should we request to remove the rules language work item
from our charter, or are folks out there willing to start NOW.
Dear Markus,
there is a "detail" wich was not considered and I focus on: it is the
documentation of the language in which the text on wich the rules are to
apply. And also in which language the program is to be entered. No use to
have a P or Sieve language in ASCII for an Arabic, a Chinese, a Russian,
etc. e-mail exchange.
A language is documented by a langtag. I was among those who blocked the
second last call of the proposed RFC 3066 revamp and obtained a WG-ltru to
consider it. One of the major point of contension was the refusal of the
authors to consider the OPES requirements. Like Web Services, we need to
have a clearly defined language to filter. This concerns both the header
(lingual name, subject, etc.) and the content. The author of the Draft (W3C
and Unicode) are interested in two main things as far as I understand:
documenting the language of the page for HTML and XML and defining the
language as part if the UNICODE CLDR effort to define all the locales of
all the OSes.
I committed to present a draft on that. There should be a part on the way
OPES needs to be supported. Interested in comments.
jfc
Thanks,
Markus
Markus Hofmann wrote:
OK, so we had several folks indicating interest in contributing to the
rules work - let's get staretd, we're still behind.
We need to get closure on the Sieve issue, i.e. might sieve with possible
extensions provide a solution? If not, why not? If not, we need to get
back to defining an own language - starting with what we had on "P".
So, where are the interested folks willing to get rolling?
Thanks,
Markus
Markus Hofmann wrote:
Alex Rousskov wrote:
I did not see anybody digging in. At this point, I have to wonder if I
am the only person left interested in the "common rules language"
problem. Did we lose the momentum and interest on this topic? Does it
make sense to continue working on rules (regardless of Seive versus P
question)?
There were a few folks interested in the topic when the charter was
discussed and before various (mostly IETF-imposed) delays put the topic
on the backburner. Should we assume that those folks lost interest
(due to delays or any other reason)?
Folks - we need to know if anyone is still interested in this work.
Doesn't make sense to drag this along without anyone working on it and
without making real progress.
Could anyone interested in the rules language work please speak up, in
particular the ones who expressed interest in contributing to the work
when we re-charted (don't make me go back into the email archives to dig
out the names... :). If we don't hear back, I recommend we fold this activity.
Thanks,
Markus
======================================================
Standardizing Tags for the Identification of Languages should not be a way
to standardize languages and to unify the world under a dominant culture.
======================================================
For your convenience:
RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066
Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt
Charter: http://ietf.org/html.charters/ltru-charter.html
gmane: http://dir.gmane.org/gmane.ietf.ltru
If you were Bcced for information and not familliar with the IETF process:
http://www.ietf.org/rfc/rfc2026.txt
http://www.ietf.org/rfc/rfc2418.txt
http://www.ietf.org/rfc/rfc3934.txt
http://www.ietf.org/rfc/rfc3669.txt
http://www.ietf.org/rfc/rfc3160.txt
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
======================================================
Jon Postel (RFC 1591): "The IANA is not in the business of deciding
what is and what is not a country. The selection of the ISO 3166 list
as a basis for country code top-level domain names was made with
the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."
======================================================
Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
same thing, choose one. If a previous design, in the Internet context
or elsewhere, has successfully solved the same problem, choose the
same solution unless there is a good technical reason not to.
Duplication of the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject improvements."
======================================================
It seems that what works for countries and ISO 3166 since 1978, should
apply to languages and to ISO 693.
======================================================