What is keeping Sieve WG chairs busy

[Alexey Melnikov <[e-mail]>]

Just to update the WG on why chairs were so silent recently:

1). IMAP flags was submitted to IESG and received several comments (much 
more than the author originally anticipated). The comments were 
addressed, new revision was issues and the document got approved for 
publication.
2). IETF LC for subaddress has ended. Gen-Art review comments were 
received and we believe Ken has adequately responded to them. Ken will 
be publishing a new revision of the draft before it can be submitted to 
IESG.
3). Cyrus is slowly working on spamtest revision. Hopefully the next 
revision will be ready for IETF wide LC.
4). Alexey was making sure that draft-newman-i18n-comparator-11.txt 
doesn't break Sieve.
5). Cyrus and Alexey are getting ready for IESG writeup for 3028bis. 
List of issues to be resolved can be found here:
 <http://sieve.info/draft-3028bis>

Cyrus and Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4ULu5Hr002109; Tue, 30 May 2006 14:56:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4ULu50M002107; Tue, 30 May 2006 14:56:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4ULu3Bp002079 for <[e-mail]>; Tue, 30 May 2006 14:56:03 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 30 May 2006 22:56:00 +0100
Message-ID: <[e-mail]>
Date: Tue, 30 May 2006 22:55:09 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: What is keeping Sieve WG chairs busy
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just to update the WG on why chairs were so silent recently:

1). IMAP flags was submitted to IESG and received several comments (much 
more than the author originally anticipated). The comments were 
addressed, new revision was issues and the document got approved for 
publication.
2). IETF LC for subaddress has ended. Gen-Art review comments were 
received and we believe Ken has adequately responded to them. Ken will 
be publishing a new revision of the draft before it can be submitted to 
IESG.
3). Cyrus is slowly working on spamtest revision. Hopefully the next 
revision will be ready for IETF wide LC.
4). Alexey was making sure that draft-newman-i18n-comparator-11.txt 
doesn't break Sieve.
5). Cyrus and Alexey are getting ready for IESG writeup for 3028bis. 
List of issues to be resolved can be found here:
 <http://sieve.info/draft-3028bis>

Cyrus and Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UHwfMa054131; Tue, 30 May 2006 10:58:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4UHwfgX054130; Tue, 30 May 2006 10:58:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UHweiN054108 for <[e-mail]>; Tue, 30 May 2006 10:58:41 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 30 May 2006 18:58:35 +0100
Message-ID: <[e-mail]>
Date: Tue, 30 May 2006 18:57:59 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: Status of Sieve Include extension
References: <1148767597.11000.7.camel@localhost>
In-Reply-To: <1148767597.11000.7.camel@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>Hi folks,
>
>I'm going through the status of a couple of the Sieve extensions on my
>TODO list, and I haven't seen any updates to draft-daboo-sieve-include
>in a while. I think I might have asked about this sometime last year? I
>don't really recall. Anyways, what's the scoop on include?
>  
>
I am also interested in this work, even though it is not in the WG charter.

I think Cyrus is currently busy updating spamtest in preparation for 
submission to IESG.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UHAO5G022260; Tue, 30 May 2006 10:10:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4UHAOYL022259; Tue, 30 May 2006 10:10:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UHAMxF022227 for <[e-mail]>; Tue, 30 May 2006 10:10:23 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 30 May 2006 10:10:21 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1149009021; h=Date: 	 From:Subject:MIME-version:Content-type; b=vl7Am2JyCLOvHCw+u/cjywuiv mXZENBTOYphRVuJ3xPkt/dTWiPreWHPYXC6y5UZffW0XZOpfQKPH/Ji93n1og==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 30 May 2006 10:10:19 -0700 (PDT)
To: [e-mail]
Message-id: <[e-mail]>
Date: Tue, 30 May 2006 10:08:23 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Minor issue in draft-ietf-sieve-spamtestbis-02.txt
In-reply-to: "Your message dated Sat, 27 May 2006 15:06:37 -0700" <1148767597.11000.7.camel@localhost>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <1148767597.11000.7.camel@localhost>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I just noticed that although the draft makes heavy use of the relational :value
match type, it says nothing about how :count should be handled. I suggest
adding a note to say that the "count value" is 1 if there's a spamtest or
virustest result to check, 0 otherwise.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UH8LeN020901; Tue, 30 May 2006 10:08:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4UH8LSh020900; Tue, 30 May 2006 10:08:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UH8Kt1020850 for <[e-mail]>; Tue, 30 May 2006 10:08:21 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 30 May 2006 10:08:16 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1149008896; h=Date: 	 From:Subject:MIME-version:Content-type; b=AtgosZ+o+OO1A5pvXN+UxX218 jxknhcxluBqdYQoVvoIsuHv1Q9/mC13/MjD/bGNcmaMrVVvFUowV0VNVPA6rA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 30 May 2006 10:08:15 -0700 (PDT)
Cc: [e-mail]
To: Aaron Stone <[e-mail]>
Message-id: <[e-mail]>
Date: Tue, 30 May 2006 10:01:02 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Status of Sieve Include extension
In-reply-to: "Your message dated Sat, 27 May 2006 15:06:37 -0700" <1148767597.11000.7.camel@localhost>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <1148767597.11000.7.camel@localhost>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I'm going through the status of a couple of the Sieve extensions on my
> TODO list, and I haven't seen any updates to draft-daboo-sieve-include
> in a while. I think I might have asked about this sometime last year? I
> don't really recall. Anyways, what's the scoop on include?

I'm also curious about the status of the environment extension draft. Is
anyone working on it?

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4RM6Fmn036517; Sat, 27 May 2006 15:06:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4RM6FL4036515; Sat, 27 May 2006 15:06:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4RM6E5U036457 for <[e-mail]>; Sat, 27 May 2006 15:06:14 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.14] (dsl3-63-249-106-4.cruzio.com [63.249.106.4]) by mail.serendipity.cx (Postfix) with ESMTP id 45E276024E3D for <[e-mail]>; Sat, 27 May 2006 15:06:09 -0700 (PDT)
Subject: Status of Sieve Include extension
From: Aaron Stone <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Sat, 27 May 2006 15:06:37 -0700
Message-Id: <1148767597.11000.7.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,

I'm going through the status of a couple of the Sieve extensions on my
TODO list, and I haven't seen any updates to draft-daboo-sieve-include
in a while. I think I might have asked about this sometime last year? I
don't really recall. Anyways, what's the scoop on include?

Thanks,
Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HKs2ME077659; Wed, 17 May 2006 13:54:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HKs22E077658; Wed, 17 May 2006 13:54:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wrk187.corp.jabber.com (corp-fw-main.jabber.com [207.182.164.14]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HKs0BD077632 for <[e-mail]>; Wed, 17 May 2006 13:54:01 -0700 (MST) (envelope-from [e-mail])
Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 8F40D4DEE49; Wed, 17 May 2006 14:54:18 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Wed, 17 May 2006 14:54:17 -0600
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308)
MIME-Version: 1.0
To: Dave Cridland <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-notify-xmpp-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020804090003090204000000"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms020804090003090204000000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Cridland wrote:
> 
> On Wed May 17 11:35:21 2006, Alexey Melnikov wrote:
>>>> Personally, I'd be happiest with a URI to the new message, where
>>>> possible, but i appreciate there's security concerns there.
>>>>    
>>> What form would such a URI take?
>>>  
>> Can be an IMAP (draft-ietf-lemonade-rfc2192bis-02.txt) or HTTP URL.
>>
>>
> Could reasonably be a mailto: URL, too, which might merely identify the
> email address the mail arrived at, as a fallback. 

True. Or, presumably, a pop: URI.

> (OMA's EMN format uses
> a non-IANA registered scheme for that kind of thing, too).

Non-IANA-registered schemes are scary to me.

>>> IMHO the account and message identification considerations belong in
>>> draft-ietf-sieve-notify rather than in the XMPP "profile" thereof (which
>>> would simply provide an instantiation of those considerations).
>>>  
>> Maybe you are right, but I don't think that draft-ietf-sieve-notify
>> can prescribe any particular URI type, because this would vary from
>> one deployment/implementation to another.

Sure. Presumably we can say that the account and message SHOULD be
identified by a URI, but that the scheme to use or prefer shall be
determined by local service policy.

> It could say "Notifications SHOULD include a URL for the recipient to
> use as a hint for locating the message. Where the nature of the
> notification allows, this SHOULD be marked in a machine-readable manner
> (such as an attribute in XML)."

I'd strike the parenthetical clause in sieve-notify and in the xmpp
profile say something about how to encapsulate such a URI in an
appropriate XMPP extension (e.g., JEP-0066).

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEa415NF1RSzyt3NURAoAQAKCk6HiaZ55W/ZYRGDA0Bte9S4RZuACgzSEK
/7PJORgA7sZKp+DOov85Q94=
=GzCi
-----END PGP SIGNATURE-----

--------------ms020804090003090204000000
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC
BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw
MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu
ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW
F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno
mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb
RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM
UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N
UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS
MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG
AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE
LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG
SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl
O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ
L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA
NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c
DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd
1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy
2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH
FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn
BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO
GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC
AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw
Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w
NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI
hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp
bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP
fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R
e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq
ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ
yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n
b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC
MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF
RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi
BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy
QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC
AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI
6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE
cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E
+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P
Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991
Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4
AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU
3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk
Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve
N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT
B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg
Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu
b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDYwNTE3MjA1NDE3WjAjBgkqhkiG9w0BCQQxFgQUoMniUGUafyEqXNOu
iasEghPveB8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB
gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v
cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW
EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD
VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT
GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj
ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAH23Vt0wlBOHhqQNGBkBBOts+VuFd947
bK0m+JK7DpGXuYWPmwehSWe2d3zWB1XW4+IltVorwaQwf2wLfklGzC5801YhAfQ0wJY4qWhU
81cqExDL/7JbRJc9sMcqyaAl0IwESUp/oeTAN62lJtlByGn+t0TjNX9SMr+UMmCoX3dxPzMW
FONP2SUVXk3JiKd0q+1anQPYlPPl4z7PvnG0Ny7GXHqmMJbzHCkK2aM8MCtQ30rCmbBUorpx
oXQCfecUzUNVtNu2hH7YPjmK+IchYxeH+ZAKydFnKb9w65jNN1G7IGcq6w41r/pkhQ9Cvf+e
CnlmmLVlnO0el5n0HzabOtEAAAAAAAA=
--------------ms020804090003090204000000--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HDJPs9074506; Wed, 17 May 2006 06:19:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HDJPc6074505; Wed, 17 May 2006 06:19:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rutherford.zen.co.uk (rutherford.zen.co.uk [212.23.3.142]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HDJOCo074498 for <[e-mail]>; Wed, 17 May 2006 06:19:25 -0700 (MST) (envelope-from [e-mail])
Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FgLvv-00074V-24; Wed, 17 May 2006 13:19:23 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 1B5C4498007; Wed, 17 May 2006 14:20:23 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03478-10; Wed, 17 May 2006 14:20:18 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id ACA9E498006; Wed, 17 May 2006 14:20:18 +0100 (BST)
Date: Wed, 17 May 2006 14:19:17 +0100
Subject: Re: I-D ACTION:draft-ietf-sieve-notify-xmpp-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: <[e-mail]>, Peter Saint-Andre <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Rutherford-IP: [217.155.137.60]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed May 17 11:35:21 2006, Alexey Melnikov wrote:
>>> Personally, I'd be happiest with a URI to the new message, where
>>> possible, but i appreciate there's security concerns there.
>>>    
>> What form would such a URI take?
>>  
> Can be an IMAP (draft-ietf-lemonade-rfc2192bis-02.txt) or HTTP URL.
> 
> 
Could reasonably be a mailto: URL, too, which might merely identify 
the email address the mail arrived at, as a fallback. (OMA's EMN 
format uses a non-IANA registered scheme for that kind of thing, too).


>> IMHO the account and message identification considerations belong 
>> in
>> draft-ietf-sieve-notify rather than in the XMPP "profile" thereof 
>> (which
>> would simply provide an instantiation of those considerations).
>>  
> Maybe you are right, but I don't think that draft-ietf-sieve-notify 
> can prescribe any particular URI type, because this would vary from 
> one deployment/implementation to another.
> 
> 
It could say "Notifications SHOULD include a URL for the recipient to 
use as a hint for locating the message. Where the nature of the 
notification allows, this SHOULD be marked in a machine-readable 
manner (such as an attribute in XML)."

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HAZla6036127; Wed, 17 May 2006 03:35:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HAZlM3036126; Wed, 17 May 2006 03:35:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HAZifl036110 for <[e-mail]>; Wed, 17 May 2006 03:35:46 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 17 May 2006 11:35:28 +0100
Message-ID: <[e-mail]>
Date: Wed, 17 May 2006 11:35:21 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Saint-Andre <[e-mail]>
CC: Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-notify-xmpp-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Saint-Andre wrote:

>Dave Cridland wrote:
>
>>I think I might be the first person to comment about this on the list...
>>    
>>
>Quite possibly. :-)
>  
>
>>It seems odd that the XMPP message stanza used here has no obvious
>>identification as a notification 
>>    
>>
>Typically, notifications in XMPP are sent using type='headline'
>(indicating that no response is expected).
>  
>
>>specifically, XMPP, being XML based,
>>could hold (for instance) an OMA EMN, or some other XML element which
>>indicated that it was a notification, and ideally provided some
>>identification of what the account involved was.
>>    
>>
>Something like the following?
>
>imap:user@host
>  
>
IMAP-like URL

imap://user@host
?

>>Personally, I'd be happiest with a URI to the new message, where
>>possible, but i appreciate there's security concerns there.
>>    
>>
>What form would such a URI take?
>  
>
Can be an IMAP (draft-ietf-lemonade-rfc2192bis-02.txt) or HTTP URL.

>IMHO the account and message identification considerations belong in
>draft-ietf-sieve-notify rather than in the XMPP "profile" thereof (which
>would simply provide an instantiation of those considerations).
>  
>
Maybe you are right, but I don't think that draft-ietf-sieve-notify can 
prescribe any particular URI type, because this would vary from one 
deployment/implementation to another.

>>If such an XML element were to be put in place, I'd find it nicer it it
>>contained the urgency as a normal XML attribute, rather than SHIM. I
>>just don't like SHIM.
>>    
>>
>I would not have deep objections to coming up with a more XML-ish format
>(XMPP extension) for urgency.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GMtcx9081512; Tue, 16 May 2006 15:55:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GMtc2b081511; Tue, 16 May 2006 15:55:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wrk187.corp.jabber.com (corp-fw-main.jabber.com [207.182.164.14]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GMtbBj081487 for <[e-mail]>; Tue, 16 May 2006 15:55:37 -0700 (MST) (envelope-from [e-mail])
Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id EC00C4DE5CB; Tue, 16 May 2006 16:55:54 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Tue, 16 May 2006 16:55:54 -0600
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308)
MIME-Version: 1.0
To: Dave Cridland <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-notify-xmpp-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040805030305060607010701"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms040805030305060607010701
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Cridland wrote:
> 
> On Wed Jan 18 21:50:02 2006, [e-mail] wrote:
>>     Title        : Sieve Notification Mechanism: xmpp
>>     Author(s)    : P. Saint-Andre, A. Melnikov
>>     Filename    : draft-ietf-sieve-notify-xmpp-00.txt
>>     Pages        : 7
>>     Date        : 2006-1-18
> 
> I think I might be the first person to comment about this on the list...

Quite possibly. :-)

> It seems odd that the XMPP message stanza used here has no obvious
> identification as a notification 

Typically, notifications in XMPP are sent using type='headline'
(indicating that no response is expected).

> specifically, XMPP, being XML based,
> could hold (for instance) an OMA EMN, or some other XML element which
> indicated that it was a notification, and ideally provided some
> identification of what the account involved was.

Something like the following?

imap:user@host

> Personally, I'd be happiest with a URI to the new message, where
> possible, but i appreciate there's security concerns there.

What form would such a URI take?

IMHO the account and message identification considerations belong in
draft-ietf-sieve-notify rather than in the XMPP "profile" thereof (which
would simply provide an instantiation of those considerations).

> If such an XML element were to be put in place, I'd find it nicer it it
> contained the urgency as a normal XML attribute, rather than SHIM. I
> just don't like SHIM.

I would not have deep objections to coming up with a more XML-ish format
(XMPP extension) for urgency.

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEalh6NF1RSzyt3NURApmgAKDK74l54gvxgPp+gSSbG4ihVvsAPQCdEAUG
TidAC0Q2pIdLgZli7G2bpj0=
=VTrh
-----END PGP SIGNATURE-----

--------------ms040805030305060607010701
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC
BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw
MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu
ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW
F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno
mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb
RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM
UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N
UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS
MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG
AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE
LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG
SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl
O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ
L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA
NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c
DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd
1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy
2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH
FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn
BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO
GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC
AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw
Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w
NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI
hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp
bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP
fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R
e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq
ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ
yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n
b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC
MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF
RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi
BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy
QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC
AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI
6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE
cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E
+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P
Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991
Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4
AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU
3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk
Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve
N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT
B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg
Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu
b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDYwNTE2MjI1NTU0WjAjBgkqhkiG9w0BCQQxFgQUE+a4PMO7Eg7ixze1
GbsA9K6/fGMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB
gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v
cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW
EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD
VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT
GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj
ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAKShsjkZLvXPPJSA5MRqfg7pRdduqjc/
HC4QgAEVUzAl1C8QiOCZMWEk5Dn5RA5vSjeBlYcbl7ldH6yqEwDm5sexC7HrQ0KfbcHGbrBy
j+jm4/foKjpxKTeGfKmabv9b7sz/ySvibkgCC9nuSHakKNhxKO/FuxOypylk2kYS4Yn6e3Dq
y5cwksLFze2TrYeaHTa7ZaBbcFjaeqLxfmNRg8NbOVluTP5V/RCWko6PyhZWipZIPYYj92/b
TyYyG13UIBGZ6WOwKwjKY/Qd2U0PgcwMJJ6078Y9dXAN6MgqFOCGGorje35brvAm6KX8A5Fs
ZjDWh7QU/f8Wmy8eQi0rviMAAAAAAAA=
--------------ms040805030305060607010701--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GJbwHv042189; Tue, 16 May 2006 12:37:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GJbwVt042188; Tue, 16 May 2006 12:37:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GJbuP8042171 for <[e-mail]>; Tue, 16 May 2006 12:37:56 -0700 (MST) (envelope-from [e-mail])
Received: by ug-out-1314.google.com with SMTP id y2so52927uge for <[e-mail]>; Tue, 16 May 2006 12:37:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HNfC4SumHGj6zkrUYzpW9gLOHGsBhTRxQlLUyDhh35y9Icm6spThrCYgF8sGvNN2YVTyaMP0esJCUF/MkN+LU7d+aswF5Ojcx9T/hXfOrFMhHI4CPAgJngS9hQgH/Gpb4gtTwWJgoTAGtppoI+EJk31kRkCJQ/UlbcLBi2Ta4zQ=
Received: by 10.67.87.10 with SMTP id p10mr3583903ugl; Tue, 16 May 2006 12:37:55 -0700 (PDT)
Received: by 10.67.22.18 with HTTP; Tue, 16 May 2006 12:37:54 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 16 May 2006 12:37:54 -0700
From: "Mark Davis" <[e-mail]>
To: "Arnt Gulbrandsen" <[e-mail]>
Subject: Re: draft-newman-i18n-collation-09.txt just posted
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_41077_30668366.1147808274668"
References: <sRwcdKPdn+O/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Google-Sender-Auth: 3cec1b948dcf471c
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_41077_30668366.1147808274668
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
Content-Disposition: inline

VGhhbmtzLiBJJ20gYXQgdGhlIFVUQyBtZWV0aW5nIHJpZ2h0IG5vdywgYW5kIHdlIHdlcmUganVz
dCB0YWxraW5nIGFib3V0CnRoaXMuIEluIGdlbmVyYWwgdGhlIGNvbW1pdHRlZSBpcyBxdWl0ZSBo
YXBweSB3aXRoIHRoZSBjaGFuZ2VzIGFuZApkaXJlY3Rpb24uCgpUaGUgcmVtYWluaW5nIHNlcmlv
dXMgaXNzdWUgaXMgdGhlIGNvbWJpbmF0b3JpY3MuIFlvdSBoYXZlIGEgcXVlc3Rpb24gb24gdGhl
Cm9wZW4gaXNzdWUgYXNraW5nIGlmIHRoZSBuZXcgRFREIHNvbHZlcyB0aGUgaXNzdWUsIGJ1dCBh
cyBmYXIgYXMgSSBjYW4gdGVsbAppdCBkb2VzIG5vdC4KClRoZSBjb21iaW5hdG9yaWNzIGFyZSB2
ZXJ5IGxhcmdlIGZvciBDTERSLiAoU2VlCmh0dHA6Ly93d3cudW5pY29kZS5vcmcvZHJhZnQvcmVw
b3J0cy90cjM1L3RyMzUuaHRtbCNMb2NhbGVfSURzKS4gSGVyZSBpcyBhCmJhY2stb2YtdGhlLWVu
dmVsb3BlIGNhbGN1bGF0aW9uOgotIFRoZXJlIGFyZSBhIGNvdXBsZSBvZiBodW5kcmVkIGxvY2Fs
ZXMgYW5kIGdyb3dpbmcgKApodHRwOi8vdW5pY29kZS5vcmcvY2xkci9hcHBzL3N1cnZleSkKLSBN
YW55IGhhdmUgdmFyaWFudHM7IHNvIGFsbCBvZiB0aGUgR2VybWFuIG9uZXMgY2FuIGhhdmUgInBo
b25lYm9vayIgZm9yCmV4YW1wbGUuIFRoYXQgcHJvYmFibHkgYWRkcyBhbm90aGVyIDUwIGNvbWJp
bmF0aW9ucywgc28gY2FsbCBpdCBhcm91bmQgMzAwLgotIEFsbCBjYW4gYmUgcGFyYW1ldGVyaXpl
ZDogd2l0aCB0aGUgZm9sbG93aW5nIG51bWJlcnMgb2Ygc2V0dGluZ3M6CiA1IHN0cmVuZ3RoLCAy
IGFsdGVybmF0ZXMsIDIgZGlyZWN0aW9ucywgMiBub3JtYWxpemF0aW9ucywgMiBjYXNlTGV2ZWxz
LCAzCmNhc2VGaXJzdHMsIDIgaGlyZ2FuYSwgMiBudW1lcmljLCBmb3IgYSB0b3RhbCBvZiA5NjAg
Y29tYmluYXRpb25zLgogU2luY2UgdGhlc2UgYXJlIHBhcmFtZXRlcnMsIHRoZXkgY2FuIGVhY2gg
YmUgY29tYmluZWQgd2l0aCBhbGwgdGhlIGxvY2FsZXMsCnNvIHRoYXQgZ2l2ZXMgYWJvdXQgMzAs
MDAwIGRpZmZlcmVudCByZWdpc3RyYXRpb25zLgotIFRoaXMgZG9lc24ndCBhY2NvdW50IGZvciB0
aGUgdmFyaWFibGVUb3AgcGFyYW1ldGVyLCB3aGljaCB0YWtlcyBhIHN0cmluZywKYW5kIGlzIGF0
IGxlYXN0IHRoZW9yZXRpY2FsbHksIHVuYm91bmRlZC4KCkknbSBzdXJlIHdoYXQgd2UgZG9uJ3Qg
d2FudCB0byBzZWUgaXMgMzAsMDAwIGVudHJpZXMgaW4gdGhlIGZvcm0gZGlzY3Vzc2VkCmluIDcu
NS4gRXhhbXBsZSBJbml0aWFsIFJlZ2lzdHJ5IFN1bW1hcnkKCldoYXQgSSBzdWdnZXN0IGJlIGRv
bmUgaW5zdGVhZCBpcyB0aGF0IGEgc2V0IG9mIHBhcmFtZXRlcnMgYmUgcmVnaXN0ZXJlZC4KVGh1
cyB3ZSBjb3VsZCBoYXZlIHRoZSBlcXVpdmFsZW50IG9mOgoKQ0xEUi1QYXJhbWV0ZXJzOgogIGxv
Y2FsZT1hYSwgYWFfREosIGFhX0VSLCBhYV9FUl9TQUFITywgYWFfRVQsIC4uLiwgenVfWkEKICBj
b2xsYXRpb249cGhvbmVib29rLCAuLi4sIGdiMjMxMmhhbgogIGNvbFN0cmVuZ3RoPXByaW1hcnks
IHNlY29uZGFyeSwgdGVydGlhcnksIHF1YXRlcm5hcnksIGlkZW50aWNhbAogIC4uLgogIHZhcmlh
YmxlVG9wPSh1PHVuaWNvZGVDb2RlUG9pbnQ+KSsKClRoZW4gdGhlIGNvcnJlc3BvbmRpbmcgbGlu
ZSBpbiA3LjUgY291bGQgYmU6CgogICAgIGk7YmFzaWM7dWNhPTUuMC4wO3V2PTUuMC4wO0NMRFIt
UGFyYW1ldGVycyAgICBlLCBvLCBzICAgaTE4bgoKQlRXLCBJJ20gZ29pbmcgdG8gYmUgZ29uZSB1
bnRpbCBKdW5lIDcsIHNvIHdvbid0IGJlIGFibGUgdG8gcmVzcG9uZCB1bnRpbAp0aGVuLgoKVGhl
cmUgYXJlIGEgZmV3IG90aGVyIGFyZWFzIHdoZXJlIEkgaGF2ZSByZW1hcmtzIG9uIHRoZSBsYW5n
dWFnZS4gSW4KcGFydGljdWxhciwgdGhlIGhhbmRsaW5nIG9mIHRoZSBlcnJvciBzdHJpbmdzIG5l
ZWRzIHNvbWUgZnVydGhlciBmaXhlcy4gRm9yCmV4YW1wbGUsIHRoZSBmb2xsb3dpbmcgc3RhdGVt
ZW50IGlzIGZhbHNlOgoKNC4yLjMuICBPcmRlcmluZwouLi4KSXQgTVVTVCBiZSB0cmFuc2l0aXZl
IGFuZCB0cmljaG90b21vdXMuCgpUaGUgd2F5IHRvIGhhbmRsZSB0aGlzIGlzIHRvIHNheSB0aGF0
IGEgY29sbGF0aW9uIGlzIGRlZmluZWQgb3ZlciBhIGRvbWFpbgpvZiBzdHJpbmdzLiBBbnkgc3Ry
aW5nIG91dHNpZGUgb2YgdGhhdCBkb21haW4gd2lsbCBpcyBjYWxsZWQgImludmFsaWQiLCBhbmQK
cmV0dXJuIGFuIGVycm9yIHZhbHVlIHdoZW4gdXNlZCB3aXRoIGFueSBvcGVyYXRpb24uIFRoZW4g
eW91IGNhbiB0cnVlbHkgc2F5OgoKRm9yIGFsbCBzdHJpbmdzIGluIGl0cyBkb21haW4sIGl0IE1V
U1QgaXQgYmUgdHJhbnNpdGl2ZSBhbmQgdHJpY2hvdG9tb3VzLgoKTWFyawoKCk9uIDUvMTYvMDYs
IEFybnQgR3VsYnJhbmRzZW4gPGFybnRAZ3VsYnJhbmRzZW4ucHJpdi5ubz4gd3JvdGU6Cj4KPiBB
cm50IEd1bGJyYW5kc2VuIHdyaXRlczoKPiA+IE1hcmsgRGF2aXMgd3JpdGVzOgo+ID4+IC4uLgo+
ID4+IEF0IGEgcXVpY2sgZ2xhbmNlLCBpdCBhcHBlYXJzIHRoYXQgYSBudW1iZXIgb2YgY29tbWVu
dHMgaGF2ZSBiZWVuCj4gPj4gaW5jb3Jwb3JhdGVkLgo+ID4KPiA+IEl0IGlzIHBvc3NpYmxlIHRo
YXQgc29tZSBvZiBteSBjaGFuZ2VzIGRvbid0IHNhdGlzZnkgeW91LiBJIGhhZAo+ID4gY29uZmxp
Y3RpbmcgcmVxdWVzdHMgZm9yIG1hbnkgdGhpbmdzLiBGZWVsIGZyZWUgdG8gcmVwZWF0LCByZXBo
cmFzZQo+ID4gb3IgYWRkIGFyZ3VtZW50cy4KPgo+IEluIC0xMCAod2hpY2ggSSdsbCBzZW5kIG9m
ZiBvbmNlIEkgZmluaXNoIHdvcmsgdGhpcyBldmVuaW5nKSBJJ3ZlIG1hZGUKPiBhbm90aGVyIGZl
dyBjaGFuZ2VzLgo+Cj4gPj4+ICAgICAgID4gMi40IFNvcnQgS2V5cwo+ID4+Pgo+ID4+PiBUaGUg
dXNlIG9mIHRoZSB0ZXJtICJjb2xsYXRpb24gY2Fub25pY2FsaXphdGlvbiIgdG8gcmVmZXIgdG8g
c29ydAo+ID4+PiBrZXlzIGlzIHZlcnkgbWlzbGVhZGluZy4gLi4uCj4gPgo+ID4gQ2hhbmdlZDsg
dGhlIHRleHQgbm93IHNwZWFrcyBvZiBzb3J0IGtleXMuIEknbSBhZnJhaWQgdGhlcmUgc3RpbGwg
YXJlCj4gPiBpbnN0YW5jZXMgb2YgdGhlIG9sZCB0ZXJtIGFyb3VuZCwgSSBmb3VuZCBvbmUgdG9k
YXkuCj4KPiBJbiAtMTAsIGFsbCBzaG91bGQgYmUgZGVhZC4KPgo+ID4+PiBUaGUgdGVybSAnZXJy
b3InIGlzIGFsc28gcHJvYmxlbWF0aWMsIHNpbmNlIHdoYXQgaXMgcmVhbGx5IGF0IGlzc3VlCj4g
Pj4+IGlzIGEgcXVlc3Rpb24gb2YgZG9tYWluLiBGb3IgYWxsIHRob3NlIHN0cmluZ3MgaW4gdGhl
IGRvbWFpbiwKPiA+Pj4gZWl0aGVyICdlcXVhbCcgb3IgJ25vdF9lcXVhbCcgc2hvdWxkIGJlIHJl
dHVybmVkIGZyb20gdGhlIGVxdWFsaXR5Cj4gPj4+IGZ1bmN0aW9uLiBGb3IgYW55IHN0cmluZyBu
b3QgaW4gdGhlIGRvbWFpbiwgJ3VuZGVmaW5lZCcgc2hvdWxkIGJlCj4gPj4+IHJldHVybmVkLgo+
ID4KPiA+IE5vdCBjaGFuZ2VkLiBCYWNrIGluIEZlYnJ1YXJ5LCBJIGFncmVlZCB0aGF0ICJlcnJv
ciIgd2FzIG5vdCBpZGVhbCwKPiA+IGJ1dCBkaWQgbm90IHNlZSAidW5kZWZpbmVkIiBhcyBiZXR0
ZXIsIGFuZCBjb3VsZCBub3QgZmluZCBhIHJlYWxseQo+ID4gYXB0IHRlcm0uIFRoZSBjb2xsYXRp
b25zIHdlcmUgYSBsaXR0bGUgdG9vIHdlbGwtZGVmaW5lZCBpbiB0aGUKPiA+ICJ1bmRlZmluZWQi
IGNhc2VzIHRoZW4uCj4gPgo+ID4gSG93ZXZlciwgaW4gLTEwLCBJIHRoaW5rIHRoZXkgcmVhbGx5
IHdpbGwgYmUgdW5kZWZpbmVkIG91dHNpZGUgdGhlaXIKPiA+IGRvbWFpbiwgc28gSSdsbCBjaGFu
Z2UgdG8gdXNpbmcgInVuZGVmaW5lZCIgaW5zdGVhZCBvZiAiZXJyb3IiLiAoSSdtCj4gPiByZW1v
dmluZyB0aGUgYml0cyB0aGF0IGZhbGwgYmFjayB0byBpO29jdGV0LikKPgo+IENoYW5nZWQuIFRo
ZSBmYWxsYmFjayB0byBpO29jdGV0IGlzIG5vdyBpbiB0aGUgc2VydmVyLCBpZiB0aGUgcHJvdG9j
b2wKPiByZXF1aXJlcyBpdC4KPgo+IFRoaXMgbWVhbnMgdGhhdCBpZiBhIHNlcnZlciBjYW4gZXNj
YXBlIGltcGxlbWVudGluZyBpO29jdGV0LCBpdCBjYW4ga2VlcAo+IGFsbCBpdHMgc3RyaW5ncyBp
biBVQ1MtMiBvciBVQ1MtNCBpbnRlcm5hbGx5LCBldmVuIGFzIGl0IGltcGxlbWVudHMKPiBjb2xs
YXRpb25zIHdoaWNoIGFyZSBkZWZpbmVkIGluIHRlcm1zIG9mIG9jdGV0cy4KPgo+IEFybnQKPgo=
------=_Part_41077_30668366.1147808274668
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

VGhhbmtzLiBJJ20gYXQgdGhlIFVUQyBtZWV0aW5nIHJpZ2h0IG5vdywgYW5kIHdlIHdlcmUganVz
dCB0YWxraW5nIGFib3V0IHRoaXMuIEluIGdlbmVyYWwgdGhlIGNvbW1pdHRlZSBpcyBxdWl0ZSBo
YXBweSB3aXRoIHRoZSBjaGFuZ2VzIGFuZCBkaXJlY3Rpb24uPGJyPjxicj5UaGUgcmVtYWluaW5n
IHNlcmlvdXMgaXNzdWUgaXMgdGhlIGNvbWJpbmF0b3JpY3MuIFlvdSBoYXZlIGEgcXVlc3Rpb24g
b24gdGhlIG9wZW4gaXNzdWUgYXNraW5nIGlmIHRoZSBuZXcgRFREIHNvbHZlcyB0aGUgaXNzdWUs
IGJ1dCBhcyBmYXIgYXMgSSBjYW4gdGVsbCBpdCBkb2VzIG5vdC4KPGJyPjxicj5UaGUgY29tYmlu
YXRvcmljcyBhcmUgdmVyeSBsYXJnZSBmb3IgQ0xEUi4gKFNlZSA8YSBocmVmPSJodHRwOi8vd3d3
LnVuaWNvZGUub3JnL2RyYWZ0L3JlcG9ydHMvdHIzNS90cjM1Lmh0bWwjTG9jYWxlX0lEcyI+aHR0
cDovL3d3dy51bmljb2RlLm9yZy9kcmFmdC9yZXBvcnRzL3RyMzUvdHIzNS5odG1sI0xvY2FsZV9J
RHM8L2E+KS4gSGVyZSBpcyBhIGJhY2stb2YtdGhlLWVudmVsb3BlIGNhbGN1bGF0aW9uOgo8YnI+
LSBUaGVyZSBhcmUgYSBjb3VwbGUgb2YgaHVuZHJlZCBsb2NhbGVzIGFuZCBncm93aW5nICg8YSBo
cmVmPSJodHRwOi8vdW5pY29kZS5vcmcvY2xkci9hcHBzL3N1cnZleSI+aHR0cDovL3VuaWNvZGUu
b3JnL2NsZHIvYXBwcy9zdXJ2ZXk8L2E+KTxicj4tIE1hbnkgaGF2ZSB2YXJpYW50czsgc28gYWxs
IG9mIHRoZSBHZXJtYW4gb25lcyBjYW4gaGF2ZSAmcXVvdDtwaG9uZWJvb2smcXVvdDsgZm9yIGV4
YW1wbGUuIFRoYXQgcHJvYmFibHkgYWRkcyBhbm90aGVyIDUwIGNvbWJpbmF0aW9ucywgc28gY2Fs
bCBpdCBhcm91bmQgMzAwLgo8YnI+LSBBbGwgY2FuIGJlIHBhcmFtZXRlcml6ZWQ6IHdpdGggdGhl
IGZvbGxvd2luZyBudW1iZXJzIG9mIHNldHRpbmdzOjxicj4mbmJzcDs1IHN0cmVuZ3RoLCAyIGFs
dGVybmF0ZXMsIDIgZGlyZWN0aW9ucywgMiBub3JtYWxpemF0aW9ucywgMiBjYXNlTGV2ZWxzLCAz
IGNhc2VGaXJzdHMsIDIgaGlyZ2FuYSwgMiBudW1lcmljLCBmb3IgYSB0b3RhbCBvZiA5NjAgY29t
YmluYXRpb25zLjxicj4mbmJzcDtTaW5jZSB0aGVzZSBhcmUgcGFyYW1ldGVycywgdGhleSBjYW4g
ZWFjaCBiZSBjb21iaW5lZCB3aXRoIGFsbCB0aGUgbG9jYWxlcywgc28gdGhhdCBnaXZlcyBhYm91
dCAzMCwwMDAgZGlmZmVyZW50IHJlZ2lzdHJhdGlvbnMuIAo8YnI+LSBUaGlzIGRvZXNuJ3QgYWNj
b3VudCBmb3IgdGhlIHZhcmlhYmxlVG9wIHBhcmFtZXRlciwgd2hpY2ggdGFrZXMgYSBzdHJpbmcs
IGFuZCBpcyBhdCBsZWFzdCB0aGVvcmV0aWNhbGx5LCB1bmJvdW5kZWQuPGJyPjxicj5JJ20gc3Vy
ZSB3aGF0IHdlIGRvbid0IHdhbnQgdG8gc2VlIGlzIDMwLDAwMCBlbnRyaWVzIGluIHRoZSBmb3Jt
IGRpc2N1c3NlZCBpbiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsiPgo8L3Nw
YW4+Ny41LiAgRXhhbXBsZSBJbml0aWFsIFJlZ2lzdHJ5IFN1bW1hcnk8YnI+PGJyPldoYXQgSSBz
dWdnZXN0IGJlIGRvbmUgaW5zdGVhZCBpcyB0aGF0IGEgc2V0IG9mIHBhcmFtZXRlcnMgYmUgcmVn
aXN0ZXJlZC4gVGh1cyB3ZSBjb3VsZCBoYXZlIHRoZSBlcXVpdmFsZW50IG9mOjxicj48YnI+Q0xE
Ui1QYXJhbWV0ZXJzOjxicj4mbmJzcDsgbG9jYWxlPWFhLCBhYV9ESiwgYWFfRVIsIGFhX0VSX1NB
QUhPLCBhYV9FVCwgLi4uLCB6dV9aQQo8YnI+Jm5ic3A7IGNvbGxhdGlvbj1waG9uZWJvb2ssIC4u
LiwgZ2IyMzEyaGFuPGJyPiZuYnNwOyBjb2xTdHJlbmd0aD1wcmltYXJ5LCBzZWNvbmRhcnksIHRl
cnRpYXJ5LCBxdWF0ZXJuYXJ5LCBpZGVudGljYWw8YnI+Jm5ic3A7IC4uLjxicj4mbmJzcDsgdmFy
aWFibGVUb3A9KHUmbHQ7dW5pY29kZUNvZGVQb2ludCZndDspKzxicj48YnI+VGhlbiB0aGUgY29y
cmVzcG9uZGluZyBsaW5lIGluIDcuNSBjb3VsZCBiZTo8YnI+Cjxicj48cHJlPiAgICAgaTtiYXNp
Yzt1Y2E9NS4wLjA7dXY9NS4wLjA7Q0xEUi1QYXJhbWV0ZXJzICAgIGUsIG8sIHMgICBpMThuPGJy
PjwvcHJlPkJUVywgSSdtIGdvaW5nIHRvIGJlIGdvbmUgdW50aWwgSnVuZSA3LCBzbyB3b24ndCBi
ZSBhYmxlIHRvIHJlc3BvbmQgdW50aWwgdGhlbi48YnI+PHR0PjwvdHQ+PGJyPlRoZXJlIGFyZSBh
IGZldyBvdGhlciBhcmVhcyB3aGVyZSBJIGhhdmUgcmVtYXJrcyBvbiB0aGUgbGFuZ3VhZ2UuIElu
IHBhcnRpY3VsYXIsIHRoZSBoYW5kbGluZyBvZiB0aGUgZXJyb3Igc3RyaW5ncyBuZWVkcyBzb21l
IGZ1cnRoZXIgZml4ZXMuIEZvciBleGFtcGxlLCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpcyBm
YWxzZToKPGJyPjxicj48cHJlPjQuMi4zLiAgT3JkZXJpbmc8YnI+Li4uPGJyPkl0IE1VU1QgYmUg
dHJhbnNpdGl2ZSBhbmQgdHJpY2hvdG9tb3VzLjwvcHJlPlRoZSB3YXkgdG8gaGFuZGxlIHRoaXMg
aXMgdG8gc2F5IHRoYXQgYSBjb2xsYXRpb24gaXMgZGVmaW5lZCBvdmVyIGEgZG9tYWluIG9mIHN0
cmluZ3MuIEFueSBzdHJpbmcgb3V0c2lkZSBvZiB0aGF0IGRvbWFpbiB3aWxsIGlzIGNhbGxlZCAm
cXVvdDtpbnZhbGlkJnF1b3Q7LCBhbmQgcmV0dXJuIGFuIGVycm9yIHZhbHVlIHdoZW4gdXNlZCB3
aXRoIGFueSBvcGVyYXRpb24uIFRoZW4geW91IGNhbiB0cnVlbHkgc2F5Ogo8YnI+PGJyPjxwcmU+
Rm9yIGFsbCBzdHJpbmdzIGluIGl0cyBkb21haW4sIGl0IE1VU1QgaXQgYmUgdHJhbnNpdGl2ZSBh
bmQgdHJpY2hvdG9tb3VzLjxicj48L3ByZT5NYXJrPGJyPjxicj48YnI+PGRpdj48c3BhbiBjbGFz
cz0iZ21haWxfcXVvdGUiPk9uIDUvMTYvMDYsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5B
cm50IEd1bGJyYW5kc2VuPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFybnRAZ3VsYnJhbmRzZW4u
cHJpdi5ubyI+CmFybnRAZ3VsYnJhbmRzZW4ucHJpdi5ubzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48
YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNv
bGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGlu
Zy1sZWZ0OiAxZXg7Ij5Bcm50IEd1bGJyYW5kc2VuIHdyaXRlczo8YnI+Jmd0OyBNYXJrIERhdmlz
IHdyaXRlczoKPGJyPiZndDsmZ3Q7IC4uLjxicj4mZ3Q7Jmd0OyBBdCBhIHF1aWNrIGdsYW5jZSwg
aXQgYXBwZWFycyB0aGF0IGEgbnVtYmVyIG9mIGNvbW1lbnRzIGhhdmUgYmVlbjxicj4mZ3Q7Jmd0
OyBpbmNvcnBvcmF0ZWQuPGJyPiZndDs8YnI+Jmd0OyBJdCBpcyBwb3NzaWJsZSB0aGF0IHNvbWUg
b2YgbXkgY2hhbmdlcyBkb24ndCBzYXRpc2Z5IHlvdS4gSSBoYWQ8YnI+Jmd0OyBjb25mbGljdGlu
ZyByZXF1ZXN0cyBmb3IgbWFueSB0aGluZ3MuIEZlZWwgZnJlZSB0byByZXBlYXQsIHJlcGhyYXNl
Cjxicj4mZ3Q7IG9yIGFkZCBhcmd1bWVudHMuPGJyPjxicj5JbiAtMTAgKHdoaWNoIEknbGwgc2Vu
ZCBvZmYgb25jZSBJIGZpbmlzaCB3b3JrIHRoaXMgZXZlbmluZykgSSd2ZSBtYWRlPGJyPmFub3Ro
ZXIgZmV3IGNoYW5nZXMuPGJyPjxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgJmd0OyAyLjQgU29ydCBLZXlzPGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7
Jmd0OyZndDsgVGhlIHVzZSBvZiB0aGUgdGVybSAmcXVvdDtjb2xsYXRpb24gY2Fub25pY2FsaXph
dGlvbiZxdW90OyB0byByZWZlciB0byBzb3J0Cjxicj4mZ3Q7Jmd0OyZndDsga2V5cyBpcyB2ZXJ5
IG1pc2xlYWRpbmcuIC4uLjxicj4mZ3Q7PGJyPiZndDsgQ2hhbmdlZDsgdGhlIHRleHQgbm93IHNw
ZWFrcyBvZiBzb3J0IGtleXMuIEknbSBhZnJhaWQgdGhlcmUgc3RpbGwgYXJlPGJyPiZndDsgaW5z
dGFuY2VzIG9mIHRoZSBvbGQgdGVybSBhcm91bmQsIEkgZm91bmQgb25lIHRvZGF5Ljxicj48YnI+
SW4gLTEwLCBhbGwgc2hvdWxkIGJlIGRlYWQuCjxicj48YnI+Jmd0OyZndDsmZ3Q7IFRoZSB0ZXJt
ICdlcnJvcicgaXMgYWxzbyBwcm9ibGVtYXRpYywgc2luY2Ugd2hhdCBpcyByZWFsbHkgYXQgaXNz
dWU8YnI+Jmd0OyZndDsmZ3Q7IGlzIGEgcXVlc3Rpb24gb2YgZG9tYWluLiBGb3IgYWxsIHRob3Nl
IHN0cmluZ3MgaW4gdGhlIGRvbWFpbiw8YnI+Jmd0OyZndDsmZ3Q7IGVpdGhlciAnZXF1YWwnIG9y
ICdub3RfZXF1YWwnIHNob3VsZCBiZSByZXR1cm5lZCBmcm9tIHRoZSBlcXVhbGl0eQo8YnI+Jmd0
OyZndDsmZ3Q7IGZ1bmN0aW9uLiBGb3IgYW55IHN0cmluZyBub3QgaW4gdGhlIGRvbWFpbiwgJ3Vu
ZGVmaW5lZCcgc2hvdWxkIGJlPGJyPiZndDsmZ3Q7Jmd0OyByZXR1cm5lZC48YnI+Jmd0Ozxicj4m
Z3Q7IE5vdCBjaGFuZ2VkLiBCYWNrIGluIEZlYnJ1YXJ5LCBJIGFncmVlZCB0aGF0ICZxdW90O2Vy
cm9yJnF1b3Q7IHdhcyBub3QgaWRlYWwsPGJyPiZndDsgYnV0IGRpZCBub3Qgc2VlICZxdW90O3Vu
ZGVmaW5lZCZxdW90OyBhcyBiZXR0ZXIsIGFuZCBjb3VsZCBub3QgZmluZCBhIHJlYWxseQo8YnI+
Jmd0OyBhcHQgdGVybS4gVGhlIGNvbGxhdGlvbnMgd2VyZSBhIGxpdHRsZSB0b28gd2VsbC1kZWZp
bmVkIGluIHRoZTxicj4mZ3Q7ICZxdW90O3VuZGVmaW5lZCZxdW90OyBjYXNlcyB0aGVuLjxicj4m
Z3Q7PGJyPiZndDsgSG93ZXZlciwgaW4gLTEwLCBJIHRoaW5rIHRoZXkgcmVhbGx5IHdpbGwgYmUg
dW5kZWZpbmVkIG91dHNpZGUgdGhlaXI8YnI+Jmd0OyBkb21haW4sIHNvIEknbGwgY2hhbmdlIHRv
IHVzaW5nICZxdW90O3VuZGVmaW5lZCZxdW90OyBpbnN0ZWFkIG9mICZxdW90O2Vycm9yJnF1b3Q7
LiAoSSdtCjxicj4mZ3Q7IHJlbW92aW5nIHRoZSBiaXRzIHRoYXQgZmFsbCBiYWNrIHRvIGk7b2N0
ZXQuKTxicj48YnI+Q2hhbmdlZC4gVGhlIGZhbGxiYWNrIHRvIGk7b2N0ZXQgaXMgbm93IGluIHRo
ZSBzZXJ2ZXIsIGlmIHRoZSBwcm90b2NvbDxicj5yZXF1aXJlcyBpdC48YnI+PGJyPlRoaXMgbWVh
bnMgdGhhdCBpZiBhIHNlcnZlciBjYW4gZXNjYXBlIGltcGxlbWVudGluZyBpO29jdGV0LCBpdCBj
YW4ga2VlcAo8YnI+YWxsIGl0cyBzdHJpbmdzIGluIFVDUy0yIG9yIFVDUy00IGludGVybmFsbHks
IGV2ZW4gYXMgaXQgaW1wbGVtZW50czxicj5jb2xsYXRpb25zIHdoaWNoIGFyZSBkZWZpbmVkIGlu
IHRlcm1zIG9mIG9jdGV0cy48YnI+PGJyPkFybnQ8YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K
------=_Part_41077_30668366.1147808274668--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GILDZU026119; Tue, 16 May 2006 11:21:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GILDNf026118; Tue, 16 May 2006 11:21:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GILCAn026097; Tue, 16 May 2006 11:21:12 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 2303C4AC3A; Tue, 16 May 2006 20:21:11 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 16 May 2006 20:25:19 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-newman-i18n-collation-09.txt just posted
Cc: Mark Davis <[e-mail]>, [e-mail]
References: <sRwcdKPdn+O/[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen writes:
> Mark Davis writes:
>> ...
>> At a quick glance, it appears that a number of comments have been 
>> incorporated.
>
> It is possible that some of my changes don't satisfy you. I had 
> conflicting requests for many things. Feel free to repeat, rephrase 
> or add arguments.

In -10 (which I'll send off once I finish work this evening) I've made 
another few changes.

>>>       > 2.4 Sort Keys
>>>
>>> The use of the term "collation canonicalization" to refer to sort 
>>> keys is very misleading. ...
>
> Changed; the text now speaks of sort keys. I'm afraid there still are 
> instances of the old term around, I found one today.

In -10, all should be dead.

>>> The term 'error' is also problematic, since what is really at issue 
>>> is a question of domain. For all those strings in the domain, 
>>> either 'equal' or 'not_equal' should be returned from the equality 
>>> function. For any string not in the domain, 'undefined' should be 
>>> returned.
>
> Not changed. Back in February, I agreed that "error" was not ideal, 
> but did not see "undefined" as better, and could not find a really 
> apt term. The collations were a little too well-defined in the 
> "undefined" cases then.
>
> However, in -10, I think they really will be undefined outside their 
> domain, so I'll change to using "undefined" instead of "error". (I'm 
> removing the bits that fall back to i;octet.)

Changed. The fallback to i;octet is now in the server, if the protocol 
requires it.

This means that if a server can escape implementing i;octet, it can keep 
all its strings in UCS-2 or UCS-4 internally, even as it implements 
collations which are defined in terms of octets.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GGHWnX098201; Tue, 16 May 2006 09:17:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GGHWwo098200; Tue, 16 May 2006 09:17:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GGHUDT098180; Tue, 16 May 2006 09:17:31 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id B1C794AC3A; Tue, 16 May 2006 18:17:29 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 16 May 2006 18:21:37 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-newman-i18n-collation-09.txt just posted
Cc: John Cowan <[e-mail]>, Mark Davis <[e-mail]>, [e-mail]
References: <sRwcdKPdn+O/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John Cowan writes:
> Instead of the requestor sending the request to IANA, who sends it to 
> the Collation Reviewer for discussion on the list, and then the 
> Collation Reviewer sends it back to IANA for registration (or 
> doesn't), remove the first pass through IANA.

Fine. Done.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4F1DE5w074408; Sun, 14 May 2006 18:13:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4F1DEME074407; Sun, 14 May 2006 18:13:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4F1DC8m074390 for <[e-mail]>; Sun, 14 May 2006 18:13:13 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-120.messagelabs.com!1147655591!8731340!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 23832 invoked from network); 15 May 2006 01:13:11 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-8.tower-120.messagelabs.com with SMTP; 15 May 2006 01:13:11 -0000
Received: from [135.210.81.143] (unknown[135.210.81.143](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060515011310gw10010024e> (Authid: tony); Mon, 15 May 2006 01:13:10 +0000
Message-ID: <[e-mail]>
Date: Sun, 14 May 2006 21:13:17 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Port 2000
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

#3.

Arnt Gulbrandsen wrote:
> 
> IANA registration is pending, or so the latest draft says. Well, what'll
> the draft say if IANA won't hand out port 2000?
> 
> I see three possibilities:
> 
> 1. Advise servers to listen to a standard port, and "MAY also listen to
> 2000 for legacy compatibility". Advise servers to try the standard port,
> then 2000?
> 
> 2. Advise servers to listen to a standard port, site admins to add a SRV
> record, and client to look for the SRV record and fall back to port 2000
> if there is none?
> 
> 3. Mention only the IANA-assigned port, not 2000, and pretend to ignore
> that all servers listen to port 2000 too, and every client falls back to
> 2000?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4DJkhQk041802; Sat, 13 May 2006 12:46:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4DJkhCI041801; Sat, 13 May 2006 12:46:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4DJkfhg041787 for <[e-mail]>; Sat, 13 May 2006 12:46:42 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 9547C4AC32; Sat, 13 May 2006 21:46:37 +0200 (CEST)
Message-Id: <9WUouwjK/[e-mail]>
Date: Sat, 13 May 2006 21:50:31 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: sieve/managesieve/time and ACL
Cc: Ned Freed <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed writes, answering me:
>> I believe that managesieve, as well as pretty much every other piece 
>> of software, should perform all the sanity checks it easily can. If 
>> putscript can easily check more than just syntax, it should.
>
> Again, this check seems like it forces an unnecessary ordering on how 
> users set things up. I don't think that's a good idea.

I agree with you in general, or so I think, but this is a fairly extreme 
case. If you're uploading a sieve script that runs fileinto on someone 
else's mailbox, I don't think it's unreasonable to make that someone 
grant permission first.

A more regular case, such as fileinto a nonexistent mailbox in the 
user's own mailbox subtree, is different IMO. It's conveivable that the 
MUA issues PUTSCRIPT first, then uses IMAP to CREATE the necessary 
mailbox(es) if PUTSCRIPT goes through. It's also reasonable that the 
mailbox is created on delivery.

But the extreme case is different: It's difficult to conceive of an MUA 
that does PUTSCRIPT, then logs in via IMAP as a different user and does 
SETACL to grant permission.

I think that this applies to all circumstances which ensure that the 
sieve cannot work as specified if made active now and which cannot be 
corrected by the user within the system. Possible candiates (many of 
which are hard to test):
1. redirect to a nonexistent domain
2. redirect to a nonexistent local address
3. fileinto a mailbox with a name that the local software does not support
4. fileinto a mailbox to which the user does not have the insert right 
and to which the user cannot himself grant the insert right
5. fileinto a mailbox which does not exist and which cannot be created 
by the user

If the managesieve draft ends up mentioning checks on anything other 
than pure syntax, then I think no. 3 above is a good example.

>> Yes (in a more general form, ideally).
>
> In any case, some discussion of how to handle error conditions that 
> creep in between sieve evaluation and execution of the resulting 
> actions would be fine.

Do you mean evaluation by managesieve during putscript, or evaluation by 
the sieve processor when a message is received? I agree in either case.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4DEVWs5075641; Sat, 13 May 2006 07:31:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4DEVWXa075640; Sat, 13 May 2006 07:31:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4DEVUhI075632 for <[e-mail]>; Sat, 13 May 2006 07:31:30 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 13 May 2006 07:31:24 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1147530548; h=Date: 	 From:Subject:MIME-version:Content-type; b=lCxq+CiXekTuYy3Yr1PdWKzr4 P1TfnHX/XiMaR4p9GysGip5AOQTt+KhFHRdN12SsQoOGdXZyWTyYwWtMN7oPA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 13 May 2006 07:31:22 -0700 (PDT)
Cc: [e-mail], Ned Freed <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Message-id: <[e-mail]>
Date: Sat, 13 May 2006 07:27:10 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: sieve/managesieve/time and ACL
In-reply-to: "Your message dated Fri, 12 May 2006 19:59:59 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Ned Freed writes:
> > The implication here is that you might want to check fileinto validity
> > in managesieve.

> Right, with emphasis on the might. I'm all in favour if picking
> low-hanging fruit.

> >  I'm very dubious about this being a good idea - in addition to ACLs
> > changing after the fact, there's also the issue of uploading the
> > sieve referring to the mailbox before the mailbox is created.

> I believe that managesieve, as well as pretty much every other piece of
> software, should perform all the sanity checks it easily can. If
> putscript can easily check more than just syntax, it should.

Again, this check seems like it forces an unnecessary ordering on how users
set things up. I don't think that's a good idea.

> > I also suspect that in many architectures it would be quite difficult
> > to perform such a check. It certainly is next to impossible to do a
> > meaningful check of this sort in ours.

> Then don't do it ;)

I wouldn't even if it was easy to do.

> >> What should happen when a message arrives and the script wants to
> >> fileinto? I can't find any mention at all of access control in 3028bis,
> >> far less of access control which changes after the sieve is blessed by
> >> managesieve.

> > We handle this case essentially by converting the fileinto into a
> > keep. I don't thinking requiring such behavior is a good idea,
> > however, we might want to point out the issue and suggest this as one
> > way to deal with it.

> Yes (in a more general form, ideally).

In any case, some discussion of how to handle error conditions that creep
in between sieve evaluation and execution of the resulting actions would
be fine.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CJo9Pt040510; Fri, 12 May 2006 12:50:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CJo93G040509; Fri, 12 May 2006 12:50:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CJo8Cg040485 for <[e-mail]>; Fri, 12 May 2006 12:50:09 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k4CJo167018162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 May 2006 19:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FedeD-00016Y-Nd; Fri, 12 May 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-imapflags-05.txt 
Message-Id: <[e-mail]>
Date: Fri, 12 May 2006 15:50:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: SIEVE Email Filtering: IMAP flag Extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sieve-imapflags-05.txt
	Pages		: 0
	Date		: 2006-5-12
	
Recent discussions have shown that it is desirable to set different
   IMAP (RFC 3501) flags on message delivery.  This can be done, for
   example, by a Sieve interpreter that works as a part of a Mail
   Delivery Agent.

   This document describes an extension to the Sieve mail filtering
   language for setting IMAP flags. The extension allows to set both
   IMAP system flags and IMAP keywords.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-imapflags-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-imapflags-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-imapflags-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-imapflags-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CHuDHI017301; Fri, 12 May 2006 10:56:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CHuD24017300; Fri, 12 May 2006 10:56:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CHuBuv017293 for <[e-mail]>; Fri, 12 May 2006 10:56:12 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id EE0864AC3A; Fri, 12 May 2006 19:56:10 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Fri, 12 May 2006 19:59:59 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: sieve/managesieve/time and ACL
Cc: Ned Freed <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed writes:
> The implication here is that you might want to check fileinto validity 
> in managesieve.

Right, with emphasis on the might. I'm all in favour if picking 
low-hanging fruit.

>  I'm very dubious about this being a good idea - in addition to ACLs 
> changing after the fact, there's also the issue of uploading the 
> sieve referring to the mailbox before the mailbox is created.

I believe that managesieve, as well as pretty much every other piece of 
software, should perform all the sanity checks it easily can. If 
putscript can easily check more than just syntax, it should.

> I also suspect that in many architectures it would be quite difficult 
> to perform such a check. It certainly is next to impossible to do a 
> meaningful check of this sort in ours.

Then don't do it ;)

>> What should happen when a message arrives and the script wants to
>> fileinto? I can't find any mention at all of access control in 3028bis,
>> far less of access control which changes after the sieve is blessed by
>> managesieve.
>
> We handle this case essentially by converting the fileinto into a 
> keep. I don't thinking requiring such behavior is a good idea, 
> however, we might want to point out the issue and suggest this as one 
> way to deal with it.

Yes (in a more general form, ideally).

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CFOgsa087489; Fri, 12 May 2006 08:24:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CFOgpA087488; Fri, 12 May 2006 08:24:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CFOfGk087482 for <[e-mail]>; Fri, 12 May 2006 08:24:41 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 12 May 2006 08:24:39 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1147447346; h=Date: 	 From:Subject:MIME-version:Content-type; b=luqm7scxZwD+B3pBcJxkDXMBU Vdz82ex1NRo9n2nKFSES54bA0dhnBc3+u/JLDGxC0sSzo1wZAin0hBZBAJr1Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 12 May 2006 08:24:37 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail]
To: Cyrus Daboo <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 12 May 2006 08:22:01 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: sieve/managesieve/time and ACL
In-reply-to: "Your message dated Fri, 12 May 2006 11:18:54 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Ned,

> --On May 12, 2006 7:57:53 AM -0700 Ned Freed <[e-mail]> wrote:

> >> What should happen when a message arrives and the script wants to
> >> fileinto? I can't find any mention at all of access control in 3028bis,
> >> far less of access control which changes after the sieve is blessed by
> >> managesieve.
> >
> > We handle this case essentially by converting the fileinto into a keep.
> > I don't thinking requiring such behavior is a good idea, however, we might
> > want to point out the issue and suggest this as one way to deal with it.

> That was better than simply treating the fileinto as a run time error and
> doing an implicit keep?

Actually, yes, it is better, since the runtime error would prevent other
actions from being taken.

In any case, turning this into a runtime error is not an option since sieve
execution is completed long before any sort of check of mailbox validity is
possible.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CFO2iM087450; Fri, 12 May 2006 08:24:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CFO2kM087449; Fri, 12 May 2006 08:24:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from xrelay04.mail2web.com (xrelay04.mail2web.com [168.144.1.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CFO2jD087443 for <[e-mail]>; Fri, 12 May 2006 08:24:02 -0700 (MST) (envelope-from [e-mail])
Received: from [168.144.251.112] (helo=M2W010.mail2web.com) by xrelay04.mail2web.com with smtp (Exim 4.50) id 1FeZUj-0005wx-Po; Fri, 12 May 2006 11:24:00 -0400
Message-ID: <[e-mail]>
X-Priority: 3
Reply-To: [e-mail]
X-Originating-IP: 66.53.219.141
X-URL: http://mail2web.com/
From: "[e-mail]" <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Date: Fri, 12 May 2006 11:23:25 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Subject: Re: sieve/managesieve/time and ACL
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4CFO2jD087444
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Folks,
I don't know how I ended up on your email list, but can you please take me
off today.
thank you and let me know.
[e-mail]




Original Message:
-----------------
From: Cyrus Daboo [e-mail]
Date: Fri, 12 May 2006 10:36:36 -0400
To: [e-mail], [e-mail]
Subject: Re: sieve/managesieve/time and ACL



Hi Arnt,

--On May 12, 2006 4:33:40 PM +0200 Arnt Gulbrandsen 
<[e-mail]> wrote:

> suppose I upload a script to the server using managesieve. A perfectly
> fine script which contain only a fileinto command for the mailbox
> /mumble/stumble. The next day, someone who doesn't like me changes the
> ACL on /mumble/stumble such that I no longer have the right to insert
> messages into it.
>
> What should happen when a message arrives and the script wants to
> fileinto? I can't find any mention at all of access control in 3028bis,
> far less of access control which changes after the sieve is blessed by
> managesieve.

If fileinto fails an implicit keep occurs - so it will end up in your INBOX.

-- 
Cyrus Daboo


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CFJ3wE087118; Fri, 12 May 2006 08:19:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CFJ3KK087117; Fri, 12 May 2006 08:19:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CFJ2KV087110 for <[e-mail]>; Fri, 12 May 2006 08:19:02 -0700 (MST) (envelope-from [e-mail])
Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 7C0DAD611D6; Fri, 12 May 2006 11:19:01 -0400 (EDT)
Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Fri, 12 May 2006 11:19:02 -0400
X-Sasl-enc: cse3xyWiZqyv6Z7PO3956Dp8v9pEw29mjtkUXPcPJWA3 1147447141
Received: from caldav.apple.com (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id E0468109; Fri, 12 May 2006 11:18:59 -0400 (EDT)
Date: Fri, 12 May 2006 11:18:54 -0400
From: Cyrus Daboo <[e-mail]>
To: Ned Freed <[e-mail]>, Arnt Gulbrandsen <[e-mail]>
cc: [e-mail]
Subject: Re: sieve/managesieve/time and ACL
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Ned,

--On May 12, 2006 7:57:53 AM -0700 Ned Freed <[e-mail]> wrote:

>> What should happen when a message arrives and the script wants to
>> fileinto? I can't find any mention at all of access control in 3028bis,
>> far less of access control which changes after the sieve is blessed by
>> managesieve.
>
> We handle this case essentially by converting the fileinto into a keep.
> I don't thinking requiring such behavior is a good idea, however, we might
> want to point out the issue and suggest this as one way to deal with it.

That was better than simply treating the fileinto as a run time error and 
doing an implicit keep?

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CF4b52086509; Fri, 12 May 2006 08:04:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CF4bX3086508; Fri, 12 May 2006 08:04:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CF4YXd086502 for <[e-mail]>; Fri, 12 May 2006 08:04:35 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 12 May 2006 08:04:32 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1147446139; h=Date: 	 From:Subject:MIME-version:Content-type; b=pwZtMgZ1ynZ4zHSNtxZH3eFGy 1Lpd/yMJPe/ElzYtW3QfbiMK1ZvkJdb2pKs3sF37TUVnLeWt/X+aA2QVWWh4g==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 12 May 2006 08:04:30 -0700 (PDT)
Cc: [e-mail]
To: Arnt Gulbrandsen <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 12 May 2006 07:57:53 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: sieve/managesieve/time and ACL
In-reply-to: "Your message dated Fri, 12 May 2006 16:33:40 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi,

> suppose I upload a script to the server using managesieve. A perfectly
> fine script which contain only a fileinto command for the mailbox
> /mumble/stumble. The next day, someone who doesn't like me changes the
> ACL on /mumble/stumble such that I no longer have the right to insert
> messages into it.

The implication here is that you might want to check fileinto validity
in managesieve. I'm very dubious about this being a good idea - in addition
to ACLs changing after the fact, there's also the issue of uploading the
sieve referring to the mailbox before the mailbox is created.

I also suspect that in many architectures it would be quite difficult to
perform such a check. It certainly is next to impossible to do a meaningful
check of this sort in ours.

> What should happen when a message arrives and the script wants to
> fileinto? I can't find any mention at all of access control in 3028bis,
> far less of access control which changes after the sieve is blessed by
> managesieve.

We handle this case essentially by converting the fileinto into a keep.
I don't thinking requiring such behavior is a good idea, however, we might
want to point out the issue and suggest this as one way to deal with it.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CEai88085697; Fri, 12 May 2006 07:36:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CEaiqU085696; Fri, 12 May 2006 07:36:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CEahwE085689 for <[e-mail]>; Fri, 12 May 2006 07:36:43 -0700 (MST) (envelope-from [e-mail])
Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 02A65D61C36; Fri, 12 May 2006 10:36:42 -0400 (EDT)
Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Fri, 12 May 2006 10:36:42 -0400
X-Sasl-enc: I5X/hvid0FLUkH/OE0iHN4jlIje8GwxlTi2y88kJl3FJ 1147444602
Received: from caldav.apple.com (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 662F483; Fri, 12 May 2006 10:36:40 -0400 (EDT)
Date: Fri, 12 May 2006 10:36:36 -0400
From: Cyrus Daboo <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: sieve/managesieve/time and ACL
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Arnt,

--On May 12, 2006 4:33:40 PM +0200 Arnt Gulbrandsen 
<[e-mail]> wrote:

> suppose I upload a script to the server using managesieve. A perfectly
> fine script which contain only a fileinto command for the mailbox
> /mumble/stumble. The next day, someone who doesn't like me changes the
> ACL on /mumble/stumble such that I no longer have the right to insert
> messages into it.
>
> What should happen when a message arrives and the script wants to
> fileinto? I can't find any mention at all of access control in 3028bis,
> far less of access control which changes after the sieve is blessed by
> managesieve.

If fileinto fails an implicit keep occurs - so it will end up in your INBOX.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CETsSm085475; Fri, 12 May 2006 07:29:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CETs4p085474; Fri, 12 May 2006 07:29:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CETqjA085468 for <[e-mail]>; Fri, 12 May 2006 07:29:53 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E31104AC3A for <[e-mail]>; Fri, 12 May 2006 16:29:51 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Fri, 12 May 2006 16:33:40 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: sieve/managesieve/time and ACL
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

suppose I upload a script to the server using managesieve. A perfectly 
fine script which contain only a fileinto command for the mailbox 
/mumble/stumble. The next day, someone who doesn't like me changes the 
ACL on /mumble/stumble such that I no longer have the right to insert 
messages into it.

What should happen when a message arrives and the script wants to 
fileinto? I can't find any mention at all of access control in 3028bis, 
far less of access control which changes after the sieve is blessed by 
managesieve.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CDSVfi082844; Fri, 12 May 2006 06:28:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CDSVEd082843; Fri, 12 May 2006 06:28:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CDSTWh082834 for <[e-mail]>; Fri, 12 May 2006 06:28:30 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 12 May 2006 14:28:23 +0100
Message-ID: <[e-mail]>
Date: Fri, 12 May 2006 14:28:14 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: Port 2000
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> IANA registration is pending, or so the latest draft says. Well, 
> what'll the draft say if IANA won't hand out port 2000?

I assume you are talking about Manage Sieve protocol.

> I see three possibilities:
>
> 1. Advise servers to listen to a standard port, and "MAY also listen 
> to 2000 for legacy compatibility". Advise servers to try the standard 
> port, then 2000?
>
> 2. Advise servers to listen to a standard port, site admins to add a 
> SRV record, and client to look for the SRV record and fall back to 
> port 2000 if there is none?
>
> 3. Mention only the IANA-assigned port, not 2000, and pretend to 
> ignore that all servers listen to port 2000 too, and every client 
> falls back to 2000?

Either 1 or 2 would work for me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CDFOmA082261; Fri, 12 May 2006 06:15:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CDFOlc082260; Fri, 12 May 2006 06:15:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CDFNWO082252 for <[e-mail]>; Fri, 12 May 2006 06:15:24 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3C4E54AC3A; Fri, 12 May 2006 15:15:22 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Fri, 12 May 2006 15:19:10 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Port 2000
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

IANA registration is pending, or so the latest draft says. Well, what'll 
the draft say if IANA won't hand out port 2000?

I see three possibilities:

1. Advise servers to listen to a standard port, and "MAY also listen to 
2000 for legacy compatibility". Advise servers to try the standard 
port, then 2000?

2. Advise servers to listen to a standard port, site admins to add a SRV 
record, and client to look for the SRV record and fall back to port 
2000 if there is none?

3. Mention only the IANA-assigned port, not 2000, and pretend to ignore 
that all servers listen to port 2000 too, and every client falls back 
to 2000?

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4BDc4Aj023959; Thu, 11 May 2006 06:38:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4BDc4ac023957; Thu, 11 May 2006 06:38:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.ccil.org (mercury.ccil.org [192.190.237.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4BDc2aG023945; Thu, 11 May 2006 06:38:03 -0700 (MST) (envelope-from [e-mail])
Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FeBMf-0003aS-9I; Thu, 11 May 2006 09:38:01 -0400
Date: Thu, 11 May 2006 09:38:01 -0400
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], [e-mail], Mark Davis <[e-mail]>, [e-mail]
Subject: Re: draft-newman-i18n-collation-09.txt just posted
Message-ID: <[e-mail]>
References: <sRwcdKPdn+O/[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
From: John Cowan <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I propose that the procedure specified in draft-newman-i18n-collation-09
for getting new collations approved should be changed to the procedure
used for new language tags.  Instead of the requestor sending the
request to IANA, who sends it to the Collation Reviewer for discussion
on the list, and then the Collation Reviewer sends it back to IANA for
registration (or doesn't), remove the first pass through IANA.

Have people post directly to the list and work out the details.  When the
requestor thinks it's ready, the Collation Reviewer wakes up and then
either sends the latest draft of the request to IANA or else sends a
rejection (with reasons) to the list.  This lowers the load on IANA.

This scheme has worked very well for [e-mail] for the
past 11 years.

-- 
John Cowan  [e-mail]   http://ccil.org/~cowan
"The exception proves the rule."  Dimbulbs think: "Your counterexample proves
my theory."  Latin students think "'Probat' means 'tests': the exception puts
the rule to the proof."  But legal historians know it means "Evidence for an
exception is evidence of the existence of a rule in cases not excepted from."



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AMNAaV084699; Wed, 10 May 2006 15:23:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4AMNALc084698; Wed, 10 May 2006 15:23:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pythagoras.zen.co.uk (pythagoras.zen.co.uk [212.23.3.140]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AMN7DK084690 for <[e-mail]>; Wed, 10 May 2006 15:23:09 -0700 (MST) (envelope-from [e-mail])
Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1Fdx5F-0001UV-Re; Wed, 10 May 2006 22:23:05 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id C8232498007; Wed, 10 May 2006 23:23:06 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07253-09; Wed, 10 May 2006 23:23:03 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 9F0F9498006; Wed, 10 May 2006 23:23:01 +0100 (BST)
Date: Wed, 10 May 2006 23:22:59 +0100
Subject: Re: comparators and "error"
References: <[e-mail]> <[e-mail]> <[e-mail]> <oyvlQ4PzQ3IFvV/ROIj/[e-mail]>
In-Reply-To: <oyvlQ4PzQ3IFvV/ROIj/[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Pythagoras-IP: [217.155.137.60]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed May 10 20:09:17 2006, Arnt Gulbrandsen wrote:
> 
> Dave Cridland writes:
>> I'm really not so sure. On the face of it, it sounds like bad 
>> design, but I think there's at least two cases here - an attempt 
>> to compare "fish" and "bicycle", and an attempt to compare "fish" 
>> and "2". I have a feeling this is an important distinction.
> 
> It is precisely the distinction between "neither input is valid" 
> and "one input is valid, the other not".
> 
>> Arguably, "fish" is equal in numeric value to "bicycle" - they 
>> both have no numeric value, so it's the same as comparing NIL and 
>> NIL with "i;octet".
> 
> Or as comparing null with null in SQL.
> 
>> Equally, "2" has a numeric value of 2, whereas "fish" does not, so 
>> they are unequal - like comparing NIL and an existing string with 
>> "i;octet".
> 
> Or as comparing 2 with null in SQL. And wouldn't you know, SQL is 
> different from ACAP in this respect.

Good for SQL... ACAP's definitions regarding this are a lot less 
clear.


> I'd rather not venture into this dark and confusing maze of 
> null/nil semantics. These are choices for the protocol to make, say 
> I.
> 
> 
I think - but I'm not absolutely sure - that the question has already 
been settled.

In RFC2244, section 3.4, which is the authoritative definition of 
comparators:

1) "i;octet" specifically states that NIL is equal only to itself. 
(Second paragraph in its definition, last sentence)

2) "i;ascii-casemap" specifically states that it applies a mapping 
then does "i;octet". So NIL==NIL again.

3) "i;ascii-numeric" then complicates my argument, because "All 
values which do not begin with a US-ASCII digit are considered equal 
with an ordinal value higher than all non-NIL single-valued 
attributes" - that certainly seems to mean "fish" == "bicycle", but 
I'm not sure if it means "fish" != NIL or "fish" == NIL. It says 
nothing to me about whether NIL == NIL.


> Instead, I think I'll add a fourth operator, valid, which indicates 
> whether a given string is valid input for the collation. It's not 
> really necessary. indomain(a) is true if and only if a=a. But it 
> sounds sensible. Permits protocols to differentiate between one and 
> two invalid inputs if they want to, without resorting to hacks like 
> a=a.

I'm entirely happy to have an additional operator, however, I'd 
prefer to standardize the behaviour somewhat. In particular, I'd 
quite like it settled as to whether NIL==NIL in general, and whether 
invalid input is equal to NIL - at the very least as a default.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AJ5fJf075992; Wed, 10 May 2006 12:05:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4AJ5f4N075991; Wed, 10 May 2006 12:05:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AJ5d3F075984 for <[e-mail]>; Wed, 10 May 2006 12:05:39 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id B5B5F4AC32; Wed, 10 May 2006 21:05:37 +0200 (CEST)
Message-Id: <oyvlQ4PzQ3IFvV/ROIj/[e-mail]>
Date: Wed, 10 May 2006 21:09:17 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: comparators and "error"
Cc: Alexey Melnikov <[e-mail]>, Dave Cridland <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland writes:
> I'm really not so sure. On the face of it, it sounds like bad design, 
> but I think there's at least two cases here - an attempt to compare 
> "fish" and "bicycle", and an attempt to compare "fish" and "2". I 
> have a feeling this is an important distinction.

It is precisely the distinction between "neither input is valid" and 
"one input is valid, the other not".

> Arguably, "fish" is equal in numeric value to "bicycle" - they both 
> have no numeric value, so it's the same as comparing NIL and NIL with 
> "i;octet".

Or as comparing null with null in SQL.

> Equally, "2" has a numeric value of 2, whereas "fish" does not, so 
> they are unequal - like comparing NIL and an existing string with 
> "i;octet".

Or as comparing 2 with null in SQL. And wouldn't you know, SQL is 
different from ACAP in this respect.

x=> select 42 as answer where 2=2;
  answer
--------
      42
(1 row)

x=> select 42 as answer where 2!=0;
  answer
--------
      42
(1 row)

Makes sense so far? Let's compare things with null a little:

x=> select 42 as answer where 2=null;
  answer
--------
(0 rows)

x=> select 42 as answer where 2!=null;
  answer
--------
(0 rows)

x=> select 42 as answer where not(2=null);
  answer
--------
(0 rows)

x=> select 42 as answer where null=null;
  answer
--------
(0 rows)

I'd rather not venture into this dark and confusing maze of null/nil 
semantics. These are choices for the protocol to make, say I.

Instead, I think I'll add a fourth operator, valid, which indicates 
whether a given string is valid input for the collation. It's not 
really necessary. indomain(a) is true if and only if a=a. But it sounds 
sensible. Permits protocols to differentiate between one and two 
invalid inputs if they want to, without resorting to hacks like a=a.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AHUWTU070964; Wed, 10 May 2006 10:30:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4AHUWju070963; Wed, 10 May 2006 10:30:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from heisenberg.zen.co.uk (heisenberg.zen.co.uk [212.23.3.141]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AHUUTb070957 for <[e-mail]>; Wed, 10 May 2006 10:30:30 -0700 (MST) (envelope-from [e-mail])
Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FdsW5-0002Js-6l; Wed, 10 May 2006 17:30:29 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id BC123498002; Wed, 10 May 2006 18:42:14 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28778-03; Wed, 10 May 2006 18:42:06 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id D88AD498003; Wed, 10 May 2006 18:42:05 +0100 (BST)
Date: Wed, 10 May 2006 18:30:19 +0100
Subject: Re: comparators and "error"
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: <[e-mail]>, Arnt Gulbrandsen <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Heisenberg-IP: [217.155.137.60]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed May 10 15:02:40 2006, Alexey Melnikov wrote:
> 
> Arnt Gulbrandsen wrote:
> 
>> I've been doing some editing on the draft, trying out how some 
>> things suggested look in prose.
>> 
>> 1. It seems useful to me that e.g. ascii-numeric can distinguish 
>> between comparing nonequal numbers and comparing out-of-scope 
>> input.
>> 
>> Take the equality operation as an example:
>> 
>> "Match" means that the collation knows how to work on the input, 
>> and the two inputs are equal as defined by the collation.
>> "No-match" means that the collation knows how, and the two are 
>> unequal.
>> "Error" means that it doesn't know how to.
>> 
>> Conflating the two latter cases smells of bad design to me, even 
>> though the difference may not be useful in every case.
> 
> I agree.
> 
> 
I'm really not so sure. On the face of it, it sounds like bad design, 
but I think there's at least two cases here - an attempt to compare 
"fish" and "bicycle", and an attempt to compare "fish" and "2". I 
have a feeling this is an important distinction.

Arguably, "fish" is equal in numeric value to "bicycle" - they both 
have no numeric value, so it's the same as comparing NIL and NIL with 
"i;octet".

Equally, "2" has a numeric value of 2, whereas "fish" does not, so 
they are unequal - like comparing NIL and an existing string with 
"i;octet".

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AEHAMG061408; Wed, 10 May 2006 07:17:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4AEHANF061407; Wed, 10 May 2006 07:17:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AEH980061400 for <[e-mail]>; Wed, 10 May 2006 07:17:10 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id BFBA14AC3C; Wed, 10 May 2006 16:17:08 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Wed, 10 May 2006 16:20:46 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: comparators and "error"
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> 2. Even though a collation specification distinguishes between 
>> "no-match" and "error", there's no requirement that all protocols 
>> must. If the distinction between "no-match" and "error" is pointless 
>> in e.g. sieve, can't simply sieve treat the two as equal? Ie. 
>> "match" is true, "no-match" is false and "error" is false?
>
> Yes, that is a possibility.
>
> Maybe we should add a new match type :failedmatch which can help 
> distinguish the no-match case from the error?

Mark Davis suggested renaming "error" as "undefined". I disagreed then, 
but I think I agree now.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AE3FkS060986; Wed, 10 May 2006 07:03:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4AE3Ej3060985; Wed, 10 May 2006 07:03:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AE3D0P060979 for <[e-mail]>; Wed, 10 May 2006 07:03:14 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 10 May 2006 15:02:57 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 May 2006 15:02:40 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: comparators and "error"
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> I've been doing some editing on the draft, trying out how some things 
> suggested look in prose.
>
> 1. It seems useful to me that e.g. ascii-numeric can distinguish 
> between comparing nonequal numbers and comparing out-of-scope input.
>
> Take the equality operation as an example:
>
> "Match" means that the collation knows how to work on the input, and 
> the two inputs are equal as defined by the collation.
> "No-match" means that the collation knows how, and the two are unequal.
> "Error" means that it doesn't know how to.
>
> Conflating the two latter cases smells of bad design to me, even 
> though the difference may not be useful in every case.

I agree.

> 2. Even though a collation specification distinguishes between 
> "no-match" and "error", there's no requirement that all protocols 
> must. If the distinction between "no-match" and "error" is pointless 
> in e.g. sieve, can't simply sieve treat the two as equal? Ie. "match" 
> is true, "no-match" is false and "error" is false?

Yes, that is a possibility.

Maybe we should add a new match type :failedmatch which can help 
distinguish the no-match case from the error?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AD5Z0H058603; Wed, 10 May 2006 06:05:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4AD5ZLd058602; Wed, 10 May 2006 06:05:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4AD5TFx058586; Wed, 10 May 2006 06:05:32 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 0FF624AC32; Wed, 10 May 2006 15:05:19 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Wed, 10 May 2006 15:08:53 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-newman-i18n-collation-09.txt just posted
Cc: Mark Davis <[e-mail]>, [e-mail]
References: <sRwcdKPdn+O/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4AD5YFx058591
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mark Davis writes:
> The release of this is timely (we didn't get notified of a 07 or 08 
> draft), since the Unicode Technical Committee is meeting next week, 
> and can discuss it.
>
> Could you indicate which of the items raised in the email of 
> 2006-02-21 from the Unicode Technical Committee have been addressed 
> in this release (and if not accepted then why)? That would help 
> greatly with the review. (I couldn't find any archive for discussion 
> of draft-newman-i18n-comparator where that email could be publicly 
> linked from, so I am appending it at the end of this message.) At a 
> quick glance, it appears that a number of comments have been 
> incorporated.

Lots. Some not. See below.

It is possible that some of my changes don't satisfy you. I had 
conflicting requests for many things. Feel free to repeat, rephrase or 
add arguments.

> Mark
>
> BTW, despite the subject of the message, the document is at 
> http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-09.txt. 
> It helps to send out a link, especially if the name (comparator vs 
> collation) is wrong ;-)

Mea culpa. My apologies.

...
>> To:   Network Working Group
>> Re:   draft-newman-i18n-comparator
>> Date:         2006-02-21
>> From:         Unicode Technical Committee
>>
>> The Unicode Technical Committee has reviewed the document 
>> http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-06.txt. 
>> While UTC is in favor of the goal, there are a number of problems 
>> with the document. The main problems are outlined below. Once these 
>> are addressed, then further review can continue.
>>
>>     Details
>>
>>       > 2.1 Definitions
>>
>>         Content
>>
>> The document needs to include the definitions of the technical terms 
>> used in the document,  including all those that may not be familiar 
>> to implementers, such as "trichotomous" and "collation identifiers". 
>> In particular, the notion of a substring is /prima facie/ quite 
>> simple, but there are complications that require a clear definition. 
>> The text in the document does not make clear that there may be more 
>> than one match for a substring in a string, and that the matches can 
>> overlap. It says "the starting offset", for example, when there may 
>> be multiple ones.

Changed.

>> Moreover, language sensitive matches have additional complications 
>> which need to be called out. For more information, see 
>> http://www.unicode.org/reports/tr10/#Searching

Not really changed. As I recall, I added a little bit of text.

>>         Format
>>
>> If there is a "Definitions" section, readers have a reasonable 
>> expectation that that section should contain all the required 
>> definitions. However, a number of definitions are scattered within 
>> the text. One of two approaches should be taken
>>
>>    1. Move all the definitions into this section.
>>    2. Remove the definitions section, but clearly call out in the text
>>       the definitions of  each terms on its own line.
>>
>> Mixing these two styles is needlessly confusing for readers.

Not changed; I'm going by what confuses reviewers.

>>       > 2.4 Sort Keys
>>
>> The use of the term "collation canonicalization" to refer to sort 
>> keys is very misleading. ...

Changed; the text now speaks of sort keys. I'm afraid there still are 
instances of the old term around, I found one today.

>> > 3.2
>>
>> This specifies that clients that support disconnected operation 
>> should not use wildcards while clients that provide collation 
>> operations only when connected to the server may use wildcards.

This restrinction has been lifted.

>> The EBNF syntax shown in section 3.2 says that the collation-wild 
>> must not exceed 255 characters total while the section 3.1 specifies 
>> that the collation name must not exceed 254 characters.

Brought into sync.

>> It seems having the same maximum possible length for both collation 
>> name and wildcard string would be desirable for actual 
>> implementations.

I picked 254, not 255, but I confess I cannot remember why.

>>       > 4.2.1 Equality
>>
>> It needs to be made clear that the return values are not physically 
>> the strings "match", etc. but enumerated values such as /equal/ and  
>> /not_equal/.

Changed. Also other similar changes.

>> One extremely important point is that for a given comparator, the 
>> equality function must be synchronized with the ordering function.

I've done this and all the other equivalences/connections/implications I 
could see.

>> The term 'error' is also problematic, since what is really at issue 
>> is a question of domain. For all those strings in the domain, either 
>> 'equal' or 'not_equal' should be returned from the equality 
>> function. For any string not in the domain, 'undefined' should be 
>> returned.

Not changed. Back in February, I agreed that "error" was not ideal, but 
did not see "undefined" as better, and could not find a really apt 
term. The collations were a little too well-defined in the "undefined" 
cases then.

However, in -10, I think they really will be undefined outside their 
domain, so I'll change to using "undefined" instead of "error". (I'm 
removing the bits that fall back to i;octet.)

>> There is a typo at the 4'th line of the second paragraph of the 
>> section 4.2 saying "... For example, an collation" which should be 
>> changed to "... For example, a collation" instead.

Fixed.

>>       > 4.2.2 Substring
>>
>> Prefix and suffix matching are not fully spelled out.

I think they are now.

>> The operations and their results must be clarified. And as noted 
>> before, it is very important to precisely define the substring 
>> operations, especially the starting offset and ending offset. It 
>> also must be clarified whether what is being asked for is the first 
>> possible matching location in the string, the last, or the nth one.

Partly changed. I didn't do the bits you ask for in the last sentence. I 
can add an open issue.

>>       > 4.3.3 Ordering
>>
>> > It MUST be transitive and trichotomous.
>>
>> As above, these should be defined.

I did not, since I think this document is the wrong place to define 
these terms.

>> The exposition in this section would be simpler if you also defined 
>> "reversible", whereby f(a,b) = less iff f(b,a) = greater.

The exposition changed enough as a result of other commens that I 
isregarded this comment.

>> An 'undefined' value can be allowed if, as per equality above, it 
>> means that at least one of the operands is outside of the domain. 
>> The function then imposes a total order on all strings in the 
>> domain; moreover, a wrapper can easily convert the function to a 
>> total order over all strings by putting all items outside the domain 
>> either below or above the ones in the domain -- or even excluding 
>> them,/ at its choice./

I'm doing something like this in -10. (Removing the fallback to i;octet.)

>> [Note: it is very important to avoid the confusion between 
>> "identical" and "equal". According to a caseless compare, "Mark" and 
>> "mark" are equal; however, the strings are not identical.]

Changed all over the place.

>> [Either 'ordering function' or 'comparison function' should be used 
>> consistently, not sometimes 'collations'].

Changed.

>>       > 4.3.  Internal Canonicalization Algorithm
>>
>> This section is difficult to understand.

Changed; I hope the new text is better.

>>       > 4.4.  Use of Lookup Tables
>>
>> It is not at all clear what is meant by "customizable lookup tables".

Clarified and partly removed.

>>       > 4.5.  Multi-Value Attributes
>>
>> This is very unclear.

Deleted.

>> This is a very important feature that needs to be spelled out in 
>> detail, and clearly reflected in the template for registration. In 
>> particular, the template should have provision for multiple 
>> attributes, with the ability to specify the acceptable operands for 
>> that attribute. (See below). The specification of the operands could 
>> be either a list of values, or a regular expression (with the former 
>> preferred). Suggested regular expression syntax would be Perl or XML 
>> Schema.

I asked Martin Dürst and you to provide a new DTD. Martin said okay, I 
don't remember whether you answered. I think the DTD should come before 
this.

>>       > 5.1Character Encoding
>>
>>    The protocol specification has to make sure that it is clear on which
>>    characters (rather than just octets) the collations are used.  This
>>    can be done by specifying the protocol itself in terms of characters
>>    (e.g. in the case of a query language), by specifying a single
>>    character encoding for the protocol (e.g.  UTF-8 [3]), or by
>>    carefully describing the relevant issues of character encoding
>>    labeling and conversion.  In the later case, details to consider
>>    include how to handle unknown charsets, any charsets which are
>>    mandatory-to-implement, any issues with byte-order that might apply,
>>    and any transfer encodings which need to be supported.
>>
>> If a collation is able to advertise itself as being able to handle, 
>> say, SJIS and UTF-8, then there should a required description of a 
>> protocol for indicating that and for communicating which encodings 
>> are handled, and how it handles error conditions (such as a charset 
>> outside of those it can handle. Otherwise, it is difficult to 
>> understand how this paragraph would be applied in practice.
>>
>>       > 5.3
>>
>> The section 5.3 specifies:
>>
>>     The protocol MUST specify how comparisons behave in the absence of
>>     explicit collation negotiation or when a collation of "*" is
>>     requested. The protocol MAY specify that the default collation
>>     used in such circumstances is sensitive to server configuration.
>>
>> and the section 3.2 specifies:
>>
>>     ... If the wildcard string matches multiple collations, the server
>>     SHOULD select the collation with the broadest scope (preferably
>>     international scope), the most recent table versions and the
>>     greatest number of supported operations. A single wildcard
>>     character ("*") refers to the application protocol collation
>>     behavior that would occur if no explicit negotiation were used.
>>
>> These appear inconsistent.

Changed.

>>       7.5.  Example Initial Registry Summary
>>
>> The sample registry would suffer a combinatorial explosion if 
>> parameters are not handled differently.
...

This is the DTD issue.

>> > 11.  Security Considerations
>>
>> This is insufficient. It should at least point to the problems 
>> related in UCA and in 
>> http://www.unicode.org/reports/tr36/tr36-4.html (note that that 
>> document has been approved by the UTC and will be posted as an 
>> approved version soon.)

It now refers.

>>     General
>>
>> One of the real problems with the IANA character registry is that the 
>> entries are underspecified. It quite often occurs that two vendors 
>> implement the same IANA charset conversion different ways, leading 
>> to significant interoperability problems and text corruption. See, 
>> for example, 
>> http://www.w3.org/Submission/japanese-xml/#ambiguity_of_yen.
>>
>> We have the real concern that this registry could lead down the same path.

Noted.

>> > collation, it has to say so
>>
>> There are places where the text should be clarified, as to whether a 
>> MUST or SHOULD is implied; this is just an example.
>>
>> > "comparator" vs "collator"
>>
>> Either one term or the other should be used consistently.

Collator, now.

>> > Unicode 3.2
>>
>> Unicode 3.2 is obsolete; the the reference versions for the Collation 
>> Registry should be Unicode 5.0 and UCA 5.0, since those will be 
>> approved and published by the time the Internet Application Protocol 
>> Collation Registry has completed its review and been approved.

I'll update to the then-current versions immediately before submitting 
the final draft as an RFC.

>> Because of the use of NamePrep, it is probably the case that Unicode 
>> 3.2 also needs to be included, but strongly recommended for usage 
>> only by protocols or systems dependent on NamePrep. Note that as of 
>> UCA 4.0 and beyond, the version number of UCA is guaranteed to be 
>> identical with the version number of Unicode that it is defined for.
>>
>> > Versioning
>>
>> This is tricky, and should be clarified. In many instances, it is 
>> sufficient to use an unversioned collator, such as simply "UCA". In 
>> other cases, there are requirements to use a specific version, or a 
>> version of at least X. This needs to be described.

IETF documents should have only immutable references. Thus, I can 
reference "UCAv14", but not "UCA", because the latter moves to v15, v16 
and onwards.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49MhnQo027083; Tue, 9 May 2006 15:43:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k49MhnVe027082; Tue, 9 May 2006 15:43:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49MhmS4027070; Tue, 9 May 2006 15:43:48 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id DE9C44AC28; Wed, 10 May 2006 00:43:46 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Wed, 10 May 2006 00:47:22 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-newman-i18n-collation-09.txt just posted
Cc: John Cowan <[e-mail]>, [e-mail]
References: <sRwcdKPdn+O/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John Cowan writes:
> Arnt Gulbrandsen scripsit:
>>  As far as I know, this addresses, ignores or adds open issues for 
>>  all requests. If something is ignored, that's because other people 
>>  wanted the opposite, or because I overlooked it when I went over 
>>  all the mail this week. I'm sorry about it in either case.
>>
>>  Review, please.
>
> Posted where? Neither rfc-editor.org nor ietf.org seems to have it.

http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-09.txt 
has it. Sorry. I posted that only an hour or two after the i-d editor 
told me it was posted (at that URL), which must have been too quickly 
for most mirrors.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49MhWXv027066; Tue, 9 May 2006 15:43:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k49MhW91027063; Tue, 9 May 2006 15:43:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k49MhVCD027051 for <[e-mail]>; Tue, 9 May 2006 15:43:31 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 19053 invoked from network); 9 May 2006 22:43:29 -0000
Received: from unknown (HELO ?172.18.103.239?) (unknown) by unknown with SMTP; 9 May 2006 22:43:29 -0000
X-pair-Authenticated: 216.239.45.4
Message-ID: <[e-mail]>
Date: Tue, 09 May 2006 15:43:23 -0700
From: Mark Davis <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: draft-newman-i18n-collation-09.txt just posted
References: <sRwcdKPdn+O/[e-mail]>
In-Reply-To: <sRwcdKPdn+O/[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The release of this is timely (we didn't get notified of a 07 or 08 
draft), since the Unicode Technical Committee is meeting next week, and 
can discuss it.

Could you indicate which of the items raised in the email of 2006-02-21 
from the Unicode Technical Committee have been addressed in this release 
(and if not accepted then why)? That would help greatly with the review. 
(I couldn't find any archive for discussion of 
draft-newman-i18n-comparator where that email could be publicly linked 
from, so I am appending it at the end of this message.) At a quick 
glance, it appears that a number of comments have been incorporated.

Mark

BTW, despite the subject of the message, the document is at 
http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-09.txt. 
It helps to send out a link, especially if the name (comparator vs 
collation) is wrong ;-)

BTW, it was pointed out to us that the original email shouldn't have 
been sent to "Network Working Group", even though that is the name at 
the top of 
http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-09.txt

Arnt Gulbrandsen wrote:
>
> As far as I know, this addresses, ignores or adds open issues for all 
> requests. If something is ignored, that's because other people wanted 
> the opposite, or because I overlooked it when I went over all the mail 
> this week. I'm sorry about it in either case.
>
> Review, please.
>
> Arnt

=================

Mark Davis wrote:
> To: 	Network Working Group
> Re: 	draft-newman-i18n-comparator
> Date: 	2006-02-21
> From: 	Unicode Technical Committee
>
> The Unicode Technical Committee has reviewed the document 
> http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-06.txt. 
> While UTC is in favor of the goal, there are a number of problems with 
> the document. The main problems are outlined below. Once these are 
> addressed, then further review can continue.
>
>
>     Details
>
>
>       > 2.1 Definitions
>
>
>         Content
>
> The document needs to include the definitions of the technical terms 
> used in the document,  including all those that may not be familiar to 
> implementers, such as "trichotomous" and "collation identifiers". In 
> particular, the notion of a substring is /prima facie/ quite simple, 
> but there are complications that require a clear definition. The text 
> in the document does not make clear that there may be more than one 
> match for a substring in a string, and that the matches can overlap. 
> It says "the starting offset", for example, when there may be multiple 
> ones.
>
> Moreover, language sensitive matches have additional complications 
> which need to be called out. For more information, see 
> http://www.unicode.org/reports/tr10/#Searching
>
>
>         Format
>
> If there is a "Definitions" section, readers have a reasonable 
> expectation that that section should contain all the required 
> definitions. However, a number of definitions are scattered within the 
> text. One of two approaches should be taken
>
>    1. Move all the definitions into this section.
>    2. Remove the definitions section, but clearly call out in the text
>       the definitions of  each terms on its own line.
>
> Mixing these two styles is needlessly confusing for readers.
>
>
>       > 2.4 Sort Keys
>
> The use of the term "collation canonicalization" to refer to sort keys 
> is very misleading. The term "canonicalization" implies that the 
> results are still text in some fashion, whereas a sortkey is simply a 
> string of octets generated from a given string by a specific 
> comparator, whereby the binary comparison (ordering) of two sort keys 
> is guaranteed to match *that* comparator's compare function for the 
> original strings. The octets may have no readily discernable relation 
> to the original text. For example, the ICU sort keys generated for the 
> following strings are:
>
> cote 	2c 44 4e 30 01 08 01 08 00
> côté 	2c 44 4e 30 01 85 93 85 8d 01 0a 00
> Αραβικά 	5c 20 52 20 22 36 3a 20 01 80 8d 01 8f 0b 00
>
> See 
> http://www-950.ibm.com/software/globalization/icu/demo/locales/en/?_=el&d_=en&x=col 
> <http://www-950.ibm.com/software/globalization/icu/demo/locales/en/?_=el&d_=en&x=col> 
> for other examples.
>
> > 3.2
>
> This specifies that clients that support disconnected operation should 
> not use wildcards while clients that provide collation operations only 
> when connected to the server may use wildcards.
>
> It appears the restrictions are may not be really needed and the 
> restrictions may need to be deleted from the draft. Otherwise, it 
> would really helpful if the rationale behind the restrictions are 
> provided at the draft.
>
> The EBNF syntax shown in section 3.2 says that the collation-wild must 
> not exceed 255 characters total while the section 3.1 specifies that 
> the collation name must not exceed 254 characters.
>
> It seems having the same maximum possible length for both collation 
> name and wildcard string would be desirable for actual implementations.
>
>
>       > 4.2.1 Equality
>
> It needs to be made clear that the return values are not physically 
> the strings "match", etc. but enumerated values such as /equal/ and  
> /not_equal/. The document could describe a notation used for them, 
> such as single quotes, since italic is not available in RFCs. 
> Similarly, the results of the ordering function should be specified as 
> an enumeration with three values: /less/, /equal/, /greater./ The 
> mapping actual API return values in implementations to these 
> enumerated values can be outside of the scope of this document. For 
> example, the mapping might take -1 onto /less/ in one implementation, 
> or anything negative onto /less/ in another implementation.
>
> One extremely important point is that for a given comparator, the 
> equality function must be synchronized with the ordering function. 
> That is, it must return 'equal' if and only if the ordering function 
> returns 'equal'. Otherwise any coordinated usage of the functions will 
> fail. This also implies that either 'error' is allowed for both 
> functions or for neither.
>
> The term 'error' is also problematic, since what is really at issue is 
> a question of domain. For all those strings in the domain, either 
> 'equal' or 'not_equal' should be returned from the equality function. 
> For any string not in the domain, 'undefined' should be returned. That 
> avoids coherency problems. Then the requirements are clear:
>
>     * if A and B are in the domain, then the result of an equality
>       test is either /equal/ or /not_equal/
>     * if A or B (or both) are not in the domain, then the result of an
>       equality test is /undefined/.
>
> There is a typo at the 4'th line of the second paragraph of the 
> section 4.2 saying "... For example, an collation" which should be 
> changed to "... For example, a collation" instead.
>
>
>       > 4.2.2 Substring
>
> Prefix and suffix matching are not fully spelled out. The operations 
> and their results must be clarified. And as noted before, it is very 
> important to precisely define the substring operations, especially the 
> starting offset and ending offset. It also must be clarified whether 
> what is being asked for is the first possible matching location in the 
> string, the last, or the nth one.
>
>
>       > 4.3.3 Ordering
>
> > It MUST be transitive and trichotomous.
>
> As above, these should be defined. The exposition in this section 
> would be simpler if you also defined "reversible", whereby f(a,b) = 
> less iff f(b,a) = greater. Then the statement would be:
>
>     It MUST be transitive, trichotomous, and reversible.
>
> >When the collation is used with a
>    "-" prefix, the result of the ordering function of the collation MUST
>    be reversed.
>
> => When the collation is used with a
>    "-" prefix, the result of the ordering function of the collation 
> when applied to two strings A and B  MUST
>    be the same as the result with a "+" prefix applied to B and A.
>
> An 'undefined' value can be allowed if, as per equality above, it 
> means that at least one of the operands is outside of the domain. The 
> function then imposes a total order on all strings in the domain; 
> moreover, a wrapper can easily convert the function to a total order 
> over all strings by putting all items outside the domain either below 
> or above the ones in the domain -- or even excluding them,/ at its 
> choice./
>
>  > In general, collations SHOULD NOT return "0" unless the two strings 
> are identical.
>
> => The ordering function MUST return 'equal' if and only if the equality function returns 'equal'
>
> [Note: it is very important to avoid the confusion between "identical" 
> and "equal". According to a caseless compare, "Mark" and "mark" are 
> equal; however, the strings are not identical.]
>
> [Either 'ordering function' or 'comparison function' should be used 
> consistently, not sometimes 'collations'].
>
>
>       > 4.3.  Internal Canonicalization Algorithm
>
> This section is difficult to understand. It appears that goal is that 
> any registration must specify sufficient detail, both data and 
> algorithm, so as to enable someone to reproduce the results. But it is 
> not at all clear that that is the goal. And that would make the 
> registration require, in some cases, a huge accompanying document. To 
> duplicate the results of CLDR collators, for example, would require 
> the UCA specification, plus the LDML specification, plus all the 
> relevant data in the CLDR repository.
>
>
>       > 4.4.  Use of Lookup Tables
>
> It is not at all clear what is meant by "customizable lookup tables".
>
>
>       > 4.5.  Multi-Value Attributes
>
> This is very unclear. It describes attributes as applying to only 
> equality (since it only refers to "match" vs "no-match" (and 
> forgetting "error")).
>
> This is a very important feature that needs to be spelled out in 
> detail, and clearly reflected in the template for registration. In 
> particular, the template should have provision for multiple 
> attributes, with the ability to specify the acceptable operands for 
> that attribute. (See below). The specification of the operands could 
> be either a list of values, or a regular expression (with the former 
> preferred). Suggested regular expression syntax would be Perl or XML 
> Schema.
>
>
>       > 5.1Character Encoding
>
>    The protocol specification has to make sure that it is clear on which
>    characters (rather than just octets) the collations are used.  This
>    can be done by specifying the protocol itself in terms of characters
>    (e.g. in the case of a query language), by specifying a single
>    character encoding for the protocol (e.g.  UTF-8 [3]), or by
>    carefully describing the relevant issues of character encoding
>    labeling and conversion.  In the later case, details to consider
>    include how to handle unknown charsets, any charsets which are
>    mandatory-to-implement, any issues with byte-order that might apply,
>    and any transfer encodings which need to be supported.
>
> If a collation is able to advertise itself as being able to handle, 
> say, SJIS and UTF-8, then there should a required description of a 
> protocol for indicating that and for communicating which encodings are 
> handled, and how it handles error conditions (such as a charset 
> outside of those it can handle. Otherwise, it is difficult to 
> understand how this paragraph would be applied in practice.
>
>
>       > 5.3
>
> The section 5.3 specifies:
>
>     The protocol MUST specify how comparisons behave in the absence of
>     explicit collation negotiation or when a collation of "*" is
>     requested. The protocol MAY specify that the default collation
>     used in such circumstances is sensitive to server configuration.
>
> and the section 3.2 specifies:
>
>     ... If the wildcard string matches multiple collations, the server
>     SHOULD select the collation with the broadest scope (preferably
>     international scope), the most recent table versions and the
>     greatest number of supported operations. A single wildcard
>     character ("*") refers to the application protocol collation
>     behavior that would occur if no explicit negotiation were used.
>
> These appear inconsistent.
>
>
>       7.5.  Example Initial Registry Summary
>
> The sample registry would suffer a combinatorial explosion if 
> parameters are not handled differently. For example, with CLDR 
> collations, there can be hundreds of locales, six different strength 
> settings; four different case-first settings; three different 
> alternate settings, backwards settings, normalization settings, case 
> level settings, hiragana settings, and numeric settings; plus a 
> variable-top setting which has a string as an operand. Registering the 
> combinations that people are allowed to use would be untenable.
>
> http://www.unicode.org/draft/reports/tr35/tr35.html#Setting_Options
>
> Instead, as remarked above, the allowable attribute values need to be 
> associated with the registered name in a machine-readable form.
>
> > 11.  Security Considerations
>
> This is insufficient. It should at least point to the problems related 
> in UCA and in http://www.unicode.org/reports/tr36/tr36-4.html (note 
> that that document has been approved by the UTC and will be posted as 
> an approved version soon.)
>
>
>     General
>
> One of the real problems with the IANA character registry is that the 
> entries are underspecified. It quite often occurs that two vendors 
> implement the same IANA charset conversion different ways, leading to 
> significant interoperability problems and text corruption. See, for 
> example, http://www.w3.org/Submission/japanese-xml/#ambiguity_of_yen.
>
> We have the real concern that this registry could lead down the same path.
>
> > collation, it has to say so
>
> There are places where the text should be clarified, as to whether a 
> MUST or SHOULD is implied; this is just an example.
>
> > "comparator" vs "collator"
>
> Either one term or the other should be used consistently.
>
> > Unicode 3.2
>
> Unicode 3.2 is obsolete; the the reference versions for the Collation 
> Registry should be Unicode 5.0 and UCA 5.0, since those will be 
> approved and published by the time the Internet Application Protocol 
> Collation Registry has completed its review and been approved.
>
> Because of the use of NamePrep, it is probably the case that Unicode 
> 3.2 also needs to be included, but strongly recommended for usage only 
> by protocols or systems dependent on NamePrep. Note that as of UCA 4.0 
> and beyond, the version number of UCA is guaranteed to be identical 
> with the version number of Unicode that it is defined for.
>
> > Versioning
>
> This is tricky, and should be clarified. In many instances, it is 
> sufficient to use an unversioned collator, such as simply "UCA". In 
> other cases, there are requirements to use a specific version, or a 
> version of at least X. This needs to be described.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49L50ET023986; Tue, 9 May 2006 14:05:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k49L50B0023984; Tue, 9 May 2006 14:05:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.ccil.org (mercury.ccil.org [192.190.237.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49L4xea023965; Tue, 9 May 2006 14:04:59 -0700 (MST) (envelope-from [e-mail])
Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FdZ4o-00068v-Mn; Tue, 09 May 2006 16:45:02 -0400
Date: Tue, 9 May 2006 16:45:02 -0400
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: draft-newman-i18n-collation-09.txt just posted
Message-ID: <[e-mail]>
References: <sRwcdKPdn+O/[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <sRwcdKPdn+O/[e-mail]>
User-Agent: Mutt/1.3.28i
From: John Cowan <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen scripsit:

> As far as I know, this addresses, ignores or adds open issues for all 
> requests. If something is ignored, that's because other people wanted 
> the opposite, or because I overlooked it when I went over all the mail 
> this week. I'm sorry about it in either case.
> 
> Review, please.

Posted where?  Neither rfc-editor.org nor ietf.org seems to have it.

-- 
John Cowan  [e-mail]  http://ccil.org/~cowan
The penguin geeks is happy / As under the waves they lark
The closed-source geeks ain't happy / They sad cause they in the dark
But geeks in the dark is lucky / They in for a worser treat
One day when the Borg go belly-up / Guess who wind up on the street.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49KAwwI022204; Tue, 9 May 2006 13:10:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k49KAwMW022202; Tue, 9 May 2006 13:10:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49KAt9Y022191; Tue, 9 May 2006 13:10:57 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 73C1A4AC28; Tue,  9 May 2006 22:10:53 +0200 (CEST)
Message-Id: <sRwcdKPdn+O/[e-mail]>
Date: Tue, 9 May 2006 22:14:28 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: draft-newman-i18n-collation-09.txt just posted
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As far as I know, this addresses, ignores or adds open issues for all 
requests. If something is ignored, that's because other people wanted 
the opposite, or because I overlooked it when I went over all the mail 
this week. I'm sorry about it in either case.

Review, please.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49EhM7o006646; Tue, 9 May 2006 07:43:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k49EhMBD006645; Tue, 9 May 2006 07:43:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49EhLj3006635 for <[e-mail]>; Tue, 9 May 2006 07:43:21 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k49EhF1I002194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 May 2006 14:43:15 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FdTQh-0006Tg-Db; Tue, 09 May 2006 10:43:15 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'Sieve Email Filtering -- Subaddress Extension' to Proposed  Standard (draft-ietf-sieve-rfc3598bis) 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 09 May 2006 10:43:15 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the Sieve Mail Filtering Language WG to 
consider the following document:

- 'Sieve Email Filtering -- Subaddress Extension '
   <draft-ietf-sieve-rfc3598bis-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2006-05-23.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-04.txt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44Ja0XZ012644; Thu, 4 May 2006 12:36:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k44Ja0WX012643; Thu, 4 May 2006 12:36:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pythagoras.zen.co.uk (pythagoras.zen.co.uk [212.23.3.140]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44JZxYM012635 for <[e-mail]>; Thu, 4 May 2006 12:35:59 -0700 (MST) (envelope-from [e-mail])
Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FbjcD-0000dP-Of for [e-mail]; Thu, 04 May 2006 19:35:57 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 883B0498003 for <[e-mail]>; Thu,  4 May 2006 20:46:43 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31828-08 for <[e-mail]>; Thu, 4 May 2006 20:46:39 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id D5728498002 for <[e-mail]>; Thu,  4 May 2006 20:46:37 +0100 (BST)
Date: Thu, 04 May 2006 20:35:51 +0100
Subject: Re: I-D ACTION:draft-ietf-sieve-notify-xmpp-00.txt 
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Pythagoras-IP: [217.155.137.60]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed Jan 18 21:50:02 2006, [e-mail] wrote:
> 	Title		: Sieve Notification Mechanism: xmpp
> 	Author(s)	: P. Saint-Andre, A. Melnikov
> 	Filename	: draft-ietf-sieve-notify-xmpp-00.txt
> 	Pages		: 7
> 	Date		: 2006-1-18

I think I might be the first person to comment about this on the 
list...

It seems odd that the XMPP message stanza used here has no obvious 
identification as a notification - specifically, XMPP, being XML 
based, could hold (for instance) an OMA EMN, or some other XML 
element which indicated that it was a notification, and ideally 
provided some identification of what the account involved was.

Personally, I'd be happiest with a URI to the new message, where 
possible, but i appreciate there's security concerns there.

If such an XML element were to be put in place, I'd find it nicer it 
it contained the urgency as a normal XML attribute, rather than SHIM. 
I just don't like SHIM.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42JnucU075275; Tue, 2 May 2006 12:49:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42Jnudh075274; Tue, 2 May 2006 12:49:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rutherford.zen.co.uk (rutherford.zen.co.uk [212.23.3.142]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Jntp7075268 for <[e-mail]>; Tue, 2 May 2006 12:49:55 -0700 (MST) (envelope-from [e-mail])
Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1Fb0sc-0005sc-3N; Tue, 02 May 2006 19:49:54 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E3FF0498003; Tue,  2 May 2006 21:00:19 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13923-03; Tue, 2 May 2006 21:00:14 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 5E970498002; Tue,  2 May 2006 21:00:14 +0100 (BST)
Date: Tue, 02 May 2006 20:49:48 +0100
Subject: Re: comparators and "error"
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Rutherford-IP: [217.155.137.60]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue May  2 16:43:44 2006, Arnt Gulbrandsen wrote:
> 2. Even though a collation specification distinguishes between 
> "no-match" and "error", there's no requirement that all protocols 
> must. If the distinction between "no-match" and "error" is 
> pointless in e.g. sieve, can't simply sieve treat the two as equal? 
> Ie. "match" is true, "no-match" is false and "error" is false?

I need to think on your argument some more, but note that there's two 
forms of "error"

A) You tried to compare a valid input string against an invalid input 
string.

B) You tried to compare two invalid input strings.

It's only case A that's really occured much in the wild, and that's 
because only one mechanism - Sieve variables - allows for that case 
to happen except in moments of silliness.

Specifically, one operand for a comparator is usually provided by the 
client (in ACAP) or the script creator (in Sieve). With Sieve 
variables, both can be derived from the message, which presumably 
isn't known in advance.

I suspect that for Sieve, case A is obviously not a fatal error, and 
probably indicates a non-match. Case B is a little trickier - there's 
a reasonable argument that it ought to result in a match. ("Blue" and 
"Yellow" do have equally non-existent numeric value, after all, and 
they collate equally at the end, and "i;octet" has that funny bit 
about the equality of two NIL values in ACAP, which of course you're 
all familiar with.)

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Fej49062611; Tue, 2 May 2006 08:40:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42FejFl062610; Tue, 2 May 2006 08:40:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42FeioL062604 for <[e-mail]>; Tue, 2 May 2006 08:40:44 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 7819A4AC35; Tue,  2 May 2006 17:40:43 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 2 May 2006 17:43:44 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: comparators and "error"
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've been doing some editing on the draft, trying out how some things 
suggested look in prose.

1. It seems useful to me that e.g. ascii-numeric can distinguish between 
comparing nonequal numbers and comparing out-of-scope input.

Take the equality operation as an example:

"Match" means that the collation knows how to work on the input, and the 
two inputs are equal as defined by the collation.
"No-match" means that the collation knows how, and the two are unequal.
"Error" means that it doesn't know how to.

Conflating the two latter cases smells of bad design to me, even though 
the difference may not be useful in every case.

2. Even though a collation specification distinguishes between 
"no-match" and "error", there's no requirement that all protocols must. 
If the distinction between "no-match" and "error" is pointless in e.g. 
sieve, can't simply sieve treat the two as equal? Ie. "match" is true, 
"no-match" is false and "error" is false?

Arnt