Subject: Re: [Fwd: interest in the rules language]

From: Markus Hofmann <[email-masked]>
Date: Wed, 23 Mar 2005 00:37:08 -0500

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
>

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 25 Mar 2005 11:21:22 -0500

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.

Thanks,
   Markus

Markus Hofmann wrote:
> 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".
> 
>>> 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)?
>>>
>> 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
>>
>

---

From: jfcm <[email-masked]>
Date: Sat, 26 Mar 2005 03:58:43 +0100

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

>>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".
>>>>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)?
>>>
>>>
>>>
>>>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.
======================================================