Subject: New Channel Draft Is Out
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 29 Nov 2001 16:47:48 -0700
List-Id: <ietf-imapext.imc.org>

draft-nerenberg-imap-channel-01.txt is now in the I-D repositories.

I've changed the syntax of the body part specifiers and added
a grammar.

--lyndon

From: "Shapira, Noam" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: draft-shapira-snap-02.txt
Date: Thu, 29 Nov 2001 09:33:19 +0200
Sender: [email-masked]

Hi all,

As some of you might have seen, SNAP third version has been submitted.

You can find the new draft in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt.

The new draft holds in it some changes that take in consideration the
remarks and recommendations I got on the different mailing list (the changes
are documented in the draft).

I would be most thankful to get some more remarks/observations on the new
draft on the mailing list.

I will be attending IETF 52 (Salt Lake City) and present (in VPIM WG) the
changes I have done.

Thanks

Noam

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shapira-snap-02.txt
Date: Mon, 26 Nov 2001 06:16:51 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Simple Notification and Alarm Protocol (SNAP)
	Author(s)	: N. Shapira et al.
	Filename	: draft-shapira-snap-02.txt
	Pages		: 28
	Date		: 21-Nov-01
	
This memo suggests a protocol for messaging notification in
which a messaging system (e.g. email server, voice mail system, 
etc.) notifies a notification service, and through it the user,
that changes have occurred in a user's mailbox (new message
arrived, mailbox is full, etc.). The protocol aims to provide the
end-user with unified notification of events occurring on different
messaging systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-shapira-snap-02.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-shapira-snap-02.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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-shapira-snap-02.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 19 Nov 2001 14:07:49 -0800
To: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: ANNOTATE issue #1: mirrored IMAP flags
Sender: [email-masked]

At 11:16 AM -0500 11/19/01, Cyrus Daboo wrote:

>From the minutes:
>
>    Q: Should IMAP flags be mirrored in annotations?

>Here are some questions to answer:
>
>- Do we mind having more than one way to do things? Note that for 
>flags there are already two different ways to read them - using 
>FETCH or SEARCH.

In general I agree that having two ways to do the same thing is bad; 
it makes the protocol more complex, and leads to implementation (or 
even protocol) bugs.

But in this specific case, I think the benefits of easier 
extensibility and shared vs. personal make it worth doing.

>
>- Do we want to have flags split into personal vs shared without the 
>need to rely on separate ACL bits to control each one? (We would 
>rely on the one ACL bit indicating whether annotations can be shared 
>or not).

I think this makes it simpler, and so I'd support it.

-- 

Date: Mon, 19 Nov 2001 15:33:23 -0500
From: Lawrence Greenfield <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, Cyrus Daboo <[email-masked]>
Subject: Re: ANNOTATE Issue #2: Unsolicited annotation responses
Sender: [email-masked]

   Date: Mon, 19 Nov 2001 11:31:53 -0500
   From: Cyrus Daboo <[email-masked]>

   1) Unsolicited ANNOTATION response only happen after the first ANNOTATION 
   command is issued by the client.

   2) The client turns on unsolicited ANNOTATION fetch responses via a 
   parameter to the SELECT/EXAMINE commands.

I think that (2) is cleaner and more predictable than #1.

(1) is a switch, but a hidden one. (2) makes it explicit, where it
might as well be.  This can also mean that if there's any annotation
data to be sent on SELECT, they don't have to be hidden in 
* OK [ANNOTATEME xxx].  It also makes it clear that the annotation
responses are on only until the next SELECT/EXAMINE/CLOSE.

Larry

From: Steve Hole <[email-masked]>
Date: Mon, 19 Nov 2001 09:43:09 -0700
To: Cyrus Daboo <[email-masked]>
Subject: Re: ANNOTATE Issue #2: Unsolicited annotation responses
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Mon, 19 Nov 2001 11:31:53 -0500 Cyrus Daboo <[email-masked]> wrote:

> 
> From the minutes:
> 
>     Q: Unsolicited annotation responses
> 
>     - Room agreeds that unsolicited responses are only cache invalidations,
>     they aren't the data
>     - Take to list the issue of whether they should
>     they come only after an annotate command has been issued

The CONDSTORE extension suffers from pretty much the same issue ... not 
too much of a surprise.
 
> 1) Unsolicited ANNOTATION response only happen after the first ANNOTATION 
> command is issued by the client.

This is what Alexey and I settled on as a proposal for CONDSTORE.  If we 
ask for MODSEQ data via a FETCH, then it will issue the unsolicited MODSEQ
responses from that time on.

We have implemented this behaviour, and it seems to work well.   Either 
you are interested in this information or not.   If you are, you will ask 
for it right away (usually).   What is clear is that once you ask for it, 
you really want unsolicited changes to flags to include corresponding 
MODSEQ changes.   Doing it otherwise made for some very complicated 
processing logic in the client code and fetch roundtrip behaviours that 
were far from optimal (I tried it out just too see how nasty it would be).

So, based on the test implementation that we did for CONDSTORE, I would 
recommend option 1.

Cheers.

---
Steve Hole
Chief Technology Officer -  - Billing and Payment Systems
ACI Worldwide - MessagingDirect
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Mon, 19 Nov 2001 11:41:58 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE Issue #3:
Sender: [email-masked]

>From the minutes:

    Q: Should the 's' bit be used for "can store private annotations?"
    Should the 'w' bit be used for "can store shared annotations?"

    - Greenfield and Daboo debate issue of more bits vs. overloading bits
    discussed
    - Crispin and Resnick agree that since private annotations
    are private to the one storing the annotations and should be stored in
    the space of the annotator, there is no reason for the mailbox owner to
    grant permission for those annotations to exist
    - Further discussion indicates that ACL is not where this belongs

A simply solution to this is (following ths second point above): anyone can 
store private annotations on a mailbox that they have read access to, 
anyone can store shared annotations on a mailbox that they have write 
access to. This eliminates any direct dependency on ACL as 
read-only/read-write mailbox access can be determined directly from the 
SELECT/EXAMINE response.

I think this has some significant issues for the server implementation in 
regards to where the private annotations actually reside - would this be 
too complex to implement?

-- 
Cyrus Daboo

From: Steve Hole <[email-masked]>
Date: Mon, 19 Nov 2001 09:36:21 -0700
To: Cyrus Daboo <[email-masked]>
Subject: Re: ANNOTATE issue #1: mirrored IMAP flags
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Mon, 19 Nov 2001 11:16:02 -0500 Cyrus Daboo <[email-masked]> wrote:

>     Clearly supporting: Resnick, Stebbens
> 
>     - Clients would prefer to use one mechanism for all annotation-like
>     data if it is available - Easier extensibility
>     - Features are available that don't exist in base flags (personal v.
>     shared)

You can add my name to the clearly supporting list Cyrus.

---
Steve Hole
Chief Technology Officer -  - Billing and Payment Systems
ACI Worldwide - MessagingDirect
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Mon, 19 Nov 2001 11:31:53 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE Issue #2: Unsolicited annotation responses
Sender: [email-masked]

>From the minutes:

    Q: Unsolicited annotation responses

    - Room agreeds that unsolicited responses are only cache invalidations,
    they aren't the data
    - Take to list the issue of whether they should
    they come only after an annotate command has been issued

I've updated the draft for the first point that was agreed upon.

I think the second issue is clear: an ANNOTATE aware server MUST NOT send 
unsolicited ANNOTATE fetch responses until it is clear that the client 
understands such responses. Sending an ANNOTATE fetch response to a client 
that is not ANNOTATE aware will result in an error since such fetch 
responses don't exist in the base protocol.

Thus there needs to be some way for the client to indicate to the server it 
is interested in annotations. There are two ways of doing this: an implicit 
behaviour where the first ANNOTATION command from the client triggers the 
unsolicited responses (as originally proposed), or an explicit behaviour 
via some kind of switch. Here are some choices:

1) Unsolicited ANNOTATION response only happen after the first ANNOTATION 
command is issued by the client.

2) The client turns on unsolicited ANNOTATION fetch responses via a 
parameter to the SELECT/EXAMINE commands.

3) The client turns on unsolicited ANNOTATION fetch responses via an 
'empty' ANNOTATION request in the first FETCH it issues. The only benefit 
to this over (1) is that it doesn't require the server to send any 
annotation data in order to simply turn on the responses.

Any opinions on which of these is better?

-- 
Cyrus Daboo

Date: Mon, 19 Nov 2001 11:16:02 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE issue #1: mirrored IMAP flags
Sender: [email-masked]

>From the minutes:

    Q: Should IMAP flags be mirrored in annotations?

    Clearly opposed: Crispin, Nerenberg, Gahrns

    - Having two ways to do things is bad with no real benefit
    - Additional flags can be done in current protocol which is superior
    - Will cause increased complexity (what kinds of responses, do they
    always store to old/new)

    Clearly supporting: Resnick, Stebbens

    - Clients would prefer to use one mechanism for all annotation-like
    data if it is available - Easier extensibility
    - Features are available that don't exist in base flags (personal v.
    shared)

Any more thoughts on this?

Here are some questions to answer:

- Do we mind having more than one way to do things? Note that for flags 
there are already two different ways to read them - using FETCH or SEARCH.

- Do we want to have flags split into personal vs shared without the need 
to rely on separate ACL bits to control each one? (We would rely on the one 
ACL bit indicating whether annotations can be shared or not).

-- 
Cyrus Daboo

Date: Mon, 19 Nov 2001 10:52:59 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Remaining ANNOTATE issues
Sender: [email-masked]

Hi folks,
Four issues remained after the last meeting. I'll post each as separate 
messages for discussion shortly.

-- 
Cyrus Daboo

From: "Shapira, Noam" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: SNAP - Security & IANA considerations
Date: Thu, 15 Nov 2001 19:34:04 +0200
Sender: [email-masked]

Hi all,

One of the action items I got in the last IETF meeting was to add Security
considerations and IANA considerations to the draft. 

Following is the added text, I would be happy to get comments.

Thanks

Noam
=============================================================
6. Security Considerations

   The SNAP describes a server-to-server protocol (Messaging Server
   and a Notification Server). The protocol defines the means by
   which the Notification Service will receive the event information
   and trigger a notification message / action to the user. Following
   is a set of threats implementers MUST take in consideration when
   defining the integration between the Messaging Server and the
   Notification Service:

6.1 Denial of Service (DoS)
 
   SNAP defines the way by which a Messaging System passes the 
   information to the Notification Service. DoS attack, might
   prevent a user from receiving a notification message by overloading
   the notification server. The possible countermeasures include: 
   validating the notification request before processing it, limiting
   the number of notification requests from a single store, etc.  
 
6.2 IP Spoofing

   As SNAP's payload holds private user's data, message data and
   mailbox data, IP spoofing may cause an attack on the user's
   privacy.

6.3 Impersonation

   A Messaging System impersonation might cause the Notification
   Service to send notification messages on events that did not occur.

6.4 Network Snooping

   Packet sniffing on the SNAP payload may impose a threat on the 
   user's privacy. The SNAP's payload SHOULD be secured in order to
   prevent network snooping.

7. IANA Considerations

   This specification calls for the registration of the new MIME
   content-type text/SNAP.

   The registration template:

     To: [email-masked]
     Subject: Registration of MIME media type text/SNAP

     MIME media type name: text

     MIME subtype name: SNAP

     Required parameters: See section 3 defined mandatory parameters

     Optional parameters: See section 3 defined non-mandatory parameters

     Encoding considerations: None

     Security considerations: None

     Interoperability considerations: None

     Published specification: This draft

     Applications which use this media type:
        Messaging System and Notification Services as defined in
        this draft.

     Additional information:
       Magic number(s): None
       File extension(s): None
       Macintosh File Type Code(s): None

     Person & email address to contact for further information:

       Noam Shapira: [email-masked]

     Intended usage:
       Common

     Author/Change controller:

       [email-masked]

Date: Wed, 14 Nov 2001 13:14:17 +0100 (CET)
From: Simon Josefsson <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-01.txt
Sender: [email-masked]

On Tue, 13 Nov 2001, Mark Crispin wrote:

> This suggests that ACL2 or ACLrev1 or ACLplus should have different commands
> and responses from the current SETACL/DELETEACL/GETACL/LISTRIGHTS/MYRIGHTS
> suite.  That way, it would be possible for a server to support both.

Adding a dummy command parameter might work.

* CAPABILITY ... ACL ACL2 ...
...
. GETACL "INBOX" "ACL2"
...
. MYRIGHTS "INBOX" "ACL2"
...

Date: Tue, 13 Nov 2001 16:11:51 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-01.txt
To: Cyrus Daboo <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

Cyrus' objections are valid.  I don't think that the conservative approach
will work.

This suggests that ACL2 or ACLrev1 or ACLplus should have different commands
and responses from the current SETACL/DELETEACL/GETACL/LISTRIGHTS/MYRIGHTS
suite.  That way, it would be possible for a server to support both.

We can still leverage on much of the existing work.  For example, we can
retain the existing lrswipcda style of single-letter rights, instead of going
to something like
 (\lookup \read \seen \write \insert \port \create \delete \administer)
which nominally would be more IMAPish.

Changing the commands and responses would give us other freedom as well, such
as being able to change the scheme of identifiers.  Instead of using a hack
like the $ prefix, we could make all identifiers have a type.  That would also
break the ambiguity between "anyone" and a user name of "anyone".

Date: Tue, 13 Nov 2001 19:09:20 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-01.txt
Sender: [email-masked]

--On Tuesday, November 13, 2001 5:46 PM -0500 Alexey Melnikov 
<[email-masked]> wrote:

> Oops, I forgot about this change. Unfortunately adding new rights is not
> backward compatible, so I will change capability to ACL2 or something like
> this.
>

If it were just a matter of adding a new right, that could be taken care of 
with 'additive' capabilities, ie * CAPABILITY ACL ACL2. But since the 
meaning of the d right is changing, a server can only advertise one of ACL 
or ACL2 and not both. Thus existing ACL clients will not work with ACL2 
servers. We must be sure that the meaning of the set of proposed rights for 
ACL2 will not change in the future - only addition of rights should be 
allowed.

-- 
Cyrus Daboo

Date: Tue, 13 Nov 2001 17:46:16 -0500
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-01.txt
Sender: [email-masked]

Simon Josefsson wrote:

> A client I use provides help texts on what each ACL capability means,
> so that I can make a good choice of what rights a mailbox should have.
> With this draft, how will I know that the "d" right is interpreted as
> in RFC 2086 or the draft?  How can I tell that the "x" right is
> supported at all?
>
> Replacing the standard is one thing, but servers out there won't
> magically upgrade at the moment RFC 2086 is updated by something else.
>
> I suspect the solutions to this problem are obvious, so I'll leave
> them as a exercise for the reader. :) Or is this discussed in the
> draft?  I couldn't find it, but perhaps I missed it.

Oops, I forgot about this change. Unfortunately adding new rights is not
backward compatible, so I will change capability to ACL2 or something like
this.

Alexey

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-01.txt
From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Nov 2001 22:12:17 +0100
Lines: 12
Sender: [email-masked]

A client I use provides help texts on what each ACL capability means,
so that I can make a good choice of what rights a mailbox should have.
With this draft, how will I know that the "d" right is interpreted as
in RFC 2086 or the draft?  How can I tell that the "x" right is
supported at all?

Replacing the standard is one thing, but servers out there won't
magically upgrade at the moment RFC 2086 is updated by something else.

I suspect the solutions to this problem are obvious, so I'll leave
them as a exercise for the reader. :) Or is this discussed in the
draft?  I couldn't find it, but perhaps I missed it.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-01.txt
Date: Tue, 13 Nov 2001 07:09:08 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-01.txt
	Pages		: 9
	Date		: 12-Nov-01
	
The ACL extension of the Internet Message Access Protocol [IMAP4]
permits access control lists to be manipulated through the IMAP
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-imapext-acl-01.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-acl-01.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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-acl-01.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sun, 11 Nov 2001 07:33:47 -0500
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Chris Newman <[email-masked]>, Mark Crispin <[email-masked]>, John Gardiner Myers <[email-masked]>
Subject: Updated ACL draft has been sent
Sender: [email-masked]

Hi,

Updated ACL draft should show up in IETF repository in a couple of days.

For now I've made only changes to make the extension as compatible with
ACL RFC as possible.
I've added two new rights: "x" for deleting mailbox and "e" for
expunging it. I've restored text that allows to implement either "union
of positive minus union of negatives" or "more specific rights win", not
just the former. I haven't touched negative rights identifiers.

Comments are welcome. There is a list of open issues in the beginning of
the document. Also I would rather hear from more people about breaking
backward compatibility with ACL RFC before I proceed any further.

Alexey

From: Steve Gardell <[email-masked]>
To: "'Shapira, Noam'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: SNAP question
Date: Thu, 8 Nov 2001 16:42:41 -0500 
Sender: [email-masked]

> -----Original Message-----
> From: Shapira, Noam [mailto:[email-masked]]
> Sent: Thursday, November 08, 2001 12:11 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: SNAP question
> 
> 
> 
> Hi all,
> 
> The SNAP next version is in it's final stages. As you can 
> recall the SNAP
> draft defines the protocol between a messaging system (e.g. 
> email server,
> voice mail) and a Notification Service. There are a few last 
> open issues
> that I would be happy if I got some suggestions.
> 
> In the last IETF (in London) I got some suggestions that it 
> is important to
> mention the issue of configuring the SNAP in the messaging 
> system - i.e. add
> the SNAP option for a user, configure the notification 
> service he will use,
> what type of request will be sent for this user (new message, 
> login, logout,
> etc.), the amount of retries and other options given in the SNAP.
> 
> The big question is how should it be done?
> 
> There are a few options like extensions of ACAP, LDAP, Sieve 
> based protocol
> and others. Another option is that this is not an interesting 
> questions and
> should be left open for different implementation.
> 

This would tend to be my inclination based on the observation that
messaging system provisioning is currently outside the scope
of standard protocols. This feels like just another piece
of user provisioning to me in the same general vein as quotas,
etc. If it were to be standardized I would suggest following
the general lead of the SIP subscribe/notify proposals.

> Noam
> 

From: "Shapira, Noam" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: SNAP question
Date: Thu, 8 Nov 2001 19:10:56 +0200 
Sender: [email-masked]

Hi all,

The SNAP next version is in it's final stages. As you can recall the SNAP
draft defines the protocol between a messaging system (e.g. email server,
voice mail) and a Notification Service. There are a few last open issues
that I would be happy if I got some suggestions.

In the last IETF (in London) I got some suggestions that it is important to
mention the issue of configuring the SNAP in the messaging system - i.e. add
the SNAP option for a user, configure the notification service he will use,
what type of request will be sent for this user (new message, login, logout,
etc.), the amount of retries and other options given in the SNAP.

The big question is how should it be done?

There are a few options like extensions of ACAP, LDAP, Sieve based protocol
and others. Another option is that this is not an interesting questions and
should be left open for different implementation.

Noam

To: [email-masked], [email-masked]
Subject: New Channel Draft Is Out
Organization: ACI Worldwide - Advanced Technology Group
Date: Thu, 29 Nov 2001 16:47:48 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

draft-nerenberg-imap-channel-01.txt is now in the I-D repositories.

I've changed the syntax of the body part specifiers and added
a grammar.

--lyndon

From: "Shapira, Noam" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: draft-shapira-snap-02.txt
Date: Thu, 29 Nov 2001 09:33:19 +0200
Sender: [email-masked]

Hi all,

As some of you might have seen, SNAP third version has been submitted.

You can find the new draft in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt.

The new draft holds in it some changes that take in consideration the
remarks and recommendations I got on the different mailing list (the changes
are documented in the draft).

I would be most thankful to get some more remarks/observations on the new
draft on the mailing list.

I will be attending IETF 52 (Salt Lake City) and present (in VPIM WG) the
changes I have done.

Thanks

Noam

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shapira-snap-02.txt
Date: Mon, 26 Nov 2001 06:16:51 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Simple Notification and Alarm Protocol (SNAP)
	Author(s)	: N. Shapira et al.
	Filename	: draft-shapira-snap-02.txt
	Pages		: 28
	Date		: 21-Nov-01
	
This memo suggests a protocol for messaging notification in
which a messaging system (e.g. email server, voice mail system, 
etc.) notifies a notification service, and through it the user,
that changes have occurred in a user's mailbox (new message
arrived, mailbox is full, etc.). The protocol aims to provide the
end-user with unified notification of events occurring on different
messaging systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-shapira-snap-02.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-shapira-snap-02.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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-shapira-snap-02.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 19 Nov 2001 14:07:49 -0800
To: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: ANNOTATE issue #1: mirrored IMAP flags
Sender: [email-masked]

At 11:16 AM -0500 11/19/01, Cyrus Daboo wrote:

>From the minutes:
>
>    Q: Should IMAP flags be mirrored in annotations?

>Here are some questions to answer:
>
>- Do we mind having more than one way to do things? Note that for 
>flags there are already two different ways to read them - using 
>FETCH or SEARCH.

In general I agree that having two ways to do the same thing is bad; 
it makes the protocol more complex, and leads to implementation (or 
even protocol) bugs.

But in this specific case, I think the benefits of easier 
extensibility and shared vs. personal make it worth doing.

>
>- Do we want to have flags split into personal vs shared without the 
>need to rely on separate ACL bits to control each one? (We would 
>rely on the one ACL bit indicating whether annotations can be shared 
>or not).

I think this makes it simpler, and so I'd support it.

-- 

Date: Mon, 19 Nov 2001 15:33:23 -0500
From: Lawrence Greenfield <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, Cyrus Daboo <[email-masked]>
Subject: Re: ANNOTATE Issue #2: Unsolicited annotation responses
Sender: [email-masked]

   Date: Mon, 19 Nov 2001 11:31:53 -0500
   From: Cyrus Daboo <[email-masked]>

   1) Unsolicited ANNOTATION response only happen after the first ANNOTATION 
   command is issued by the client.

   2) The client turns on unsolicited ANNOTATION fetch responses via a 
   parameter to the SELECT/EXAMINE commands.

I think that (2) is cleaner and more predictable than #1.

(1) is a switch, but a hidden one. (2) makes it explicit, where it
might as well be.  This can also mean that if there's any annotation
data to be sent on SELECT, they don't have to be hidden in 
* OK [ANNOTATEME xxx].  It also makes it clear that the annotation
responses are on only until the next SELECT/EXAMINE/CLOSE.

Larry

From: Steve Hole <[email-masked]>
Date: Mon, 19 Nov 2001 09:43:09 -0700
To: Cyrus Daboo <[email-masked]>
Subject: Re: ANNOTATE Issue #2: Unsolicited annotation responses
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Mon, 19 Nov 2001 11:31:53 -0500 Cyrus Daboo <[email-masked]> wrote:

> 
> From the minutes:
> 
>     Q: Unsolicited annotation responses
> 
>     - Room agreeds that unsolicited responses are only cache invalidations,
>     they aren't the data
>     - Take to list the issue of whether they should
>     they come only after an annotate command has been issued

The CONDSTORE extension suffers from pretty much the same issue ... not 
too much of a surprise.
 
> 1) Unsolicited ANNOTATION response only happen after the first ANNOTATION 
> command is issued by the client.

This is what Alexey and I settled on as a proposal for CONDSTORE.  If we 
ask for MODSEQ data via a FETCH, then it will issue the unsolicited MODSEQ
responses from that time on.

We have implemented this behaviour, and it seems to work well.   Either 
you are interested in this information or not.   If you are, you will ask 
for it right away (usually).   What is clear is that once you ask for it, 
you really want unsolicited changes to flags to include corresponding 
MODSEQ changes.   Doing it otherwise made for some very complicated 
processing logic in the client code and fetch roundtrip behaviours that 
were far from optimal (I tried it out just too see how nasty it would be).

So, based on the test implementation that we did for CONDSTORE, I would 
recommend option 1.

Cheers.

---
Steve Hole
Chief Technology Officer -  - Billing and Payment Systems
ACI Worldwide - MessagingDirect
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Mon, 19 Nov 2001 11:41:58 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE Issue #3:
Sender: [email-masked]

>From the minutes:

    Q: Should the 's' bit be used for "can store private annotations?"
    Should the 'w' bit be used for "can store shared annotations?"

    - Greenfield and Daboo debate issue of more bits vs. overloading bits
    discussed
    - Crispin and Resnick agree that since private annotations
    are private to the one storing the annotations and should be stored in
    the space of the annotator, there is no reason for the mailbox owner to
    grant permission for those annotations to exist
    - Further discussion indicates that ACL is not where this belongs

A simply solution to this is (following ths second point above): anyone can 
store private annotations on a mailbox that they have read access to, 
anyone can store shared annotations on a mailbox that they have write 
access to. This eliminates any direct dependency on ACL as 
read-only/read-write mailbox access can be determined directly from the 
SELECT/EXAMINE response.

I think this has some significant issues for the server implementation in 
regards to where the private annotations actually reside - would this be 
too complex to implement?

-- 
Cyrus Daboo

From: Steve Hole <[email-masked]>
Date: Mon, 19 Nov 2001 09:36:21 -0700
To: Cyrus Daboo <[email-masked]>
Subject: Re: ANNOTATE issue #1: mirrored IMAP flags
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Mon, 19 Nov 2001 11:16:02 -0500 Cyrus Daboo <[email-masked]> wrote:

>     Clearly supporting: Resnick, Stebbens
> 
>     - Clients would prefer to use one mechanism for all annotation-like
>     data if it is available - Easier extensibility
>     - Features are available that don't exist in base flags (personal v.
>     shared)

You can add my name to the clearly supporting list Cyrus.

---
Steve Hole
Chief Technology Officer -  - Billing and Payment Systems
ACI Worldwide - MessagingDirect
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Mon, 19 Nov 2001 11:31:53 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE Issue #2: Unsolicited annotation responses
Sender: [email-masked]

>From the minutes:

    Q: Unsolicited annotation responses

    - Room agreeds that unsolicited responses are only cache invalidations,
    they aren't the data
    - Take to list the issue of whether they should
    they come only after an annotate command has been issued

I've updated the draft for the first point that was agreed upon.

I think the second issue is clear: an ANNOTATE aware server MUST NOT send 
unsolicited ANNOTATE fetch responses until it is clear that the client 
understands such responses. Sending an ANNOTATE fetch response to a client 
that is not ANNOTATE aware will result in an error since such fetch 
responses don't exist in the base protocol.

Thus there needs to be some way for the client to indicate to the server it 
is interested in annotations. There are two ways of doing this: an implicit 
behaviour where the first ANNOTATION command from the client triggers the 
unsolicited responses (as originally proposed), or an explicit behaviour 
via some kind of switch. Here are some choices:

1) Unsolicited ANNOTATION response only happen after the first ANNOTATION 
command is issued by the client.

2) The client turns on unsolicited ANNOTATION fetch responses via a 
parameter to the SELECT/EXAMINE commands.

3) The client turns on unsolicited ANNOTATION fetch responses via an 
'empty' ANNOTATION request in the first FETCH it issues. The only benefit 
to this over (1) is that it doesn't require the server to send any 
annotation data in order to simply turn on the responses.

Any opinions on which of these is better?

-- 
Cyrus Daboo

Date: Mon, 19 Nov 2001 11:16:02 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE issue #1: mirrored IMAP flags
Sender: [email-masked]

>From the minutes:

    Q: Should IMAP flags be mirrored in annotations?

    Clearly opposed: Crispin, Nerenberg, Gahrns

    - Having two ways to do things is bad with no real benefit
    - Additional flags can be done in current protocol which is superior
    - Will cause increased complexity (what kinds of responses, do they
    always store to old/new)

    Clearly supporting: Resnick, Stebbens

    - Clients would prefer to use one mechanism for all annotation-like
    data if it is available - Easier extensibility
    - Features are available that don't exist in base flags (personal v.
    shared)

Any more thoughts on this?

Here are some questions to answer:

- Do we mind having more than one way to do things? Note that for flags 
there are already two different ways to read them - using FETCH or SEARCH.

- Do we want to have flags split into personal vs shared without the need 
to rely on separate ACL bits to control each one? (We would rely on the one 
ACL bit indicating whether annotations can be shared or not).

-- 
Cyrus Daboo

Date: Mon, 19 Nov 2001 10:52:59 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Remaining ANNOTATE issues
Sender: [email-masked]

Hi folks,
Four issues remained after the last meeting. I'll post each as separate 
messages for discussion shortly.

-- 
Cyrus Daboo

From: "Shapira, Noam" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: SNAP - Security & IANA considerations
Date: Thu, 15 Nov 2001 19:34:04 +0200
Sender: [email-masked]

Hi all,

One of the action items I got in the last IETF meeting was to add Security
considerations and IANA considerations to the draft. 

Following is the added text, I would be happy to get comments.

Thanks

Noam
=============================================================
6. Security Considerations

   The SNAP describes a server-to-server protocol (Messaging Server
   and a Notification Server). The protocol defines the means by
   which the Notification Service will receive the event information
   and trigger a notification message / action to the user. Following
   is a set of threats implementers MUST take in consideration when
   defining the integration between the Messaging Server and the
   Notification Service:

6.1 Denial of Service (DoS)
 
   SNAP defines the way by which a Messaging System passes the 
   information to the Notification Service. DoS attack, might
   prevent a user from receiving a notification message by overloading
   the notification server. The possible countermeasures include: 
   validating the notification request before processing it, limiting
   the number of notification requests from a single store, etc.  
 
6.2 IP Spoofing

   As SNAP's payload holds private user's data, message data and
   mailbox data, IP spoofing may cause an attack on the user's
   privacy.

6.3 Impersonation

   A Messaging System impersonation might cause the Notification
   Service to send notification messages on events that did not occur.

6.4 Network Snooping

   Packet sniffing on the SNAP payload may impose a threat on the 
   user's privacy. The SNAP's payload SHOULD be secured in order to
   prevent network snooping.

7. IANA Considerations

   This specification calls for the registration of the new MIME
   content-type text/SNAP.

   The registration template:

     To: [email-masked]
     Subject: Registration of MIME media type text/SNAP

     MIME media type name: text

     MIME subtype name: SNAP

     Required parameters: See section 3 defined mandatory parameters

     Optional parameters: See section 3 defined non-mandatory parameters

     Encoding considerations: None

     Security considerations: None

     Interoperability considerations: None

     Published specification: This draft

     Applications which use this media type:
        Messaging System and Notification Services as defined in
        this draft.

     Additional information:
       Magic number(s): None
       File extension(s): None
       Macintosh File Type Code(s): None

     Person & email address to contact for further information:

       Noam Shapira: [email-masked]

     Intended usage:
       Common

     Author/Change controller:

       [email-masked]

Date: Wed, 14 Nov 2001 13:14:17 +0100 (CET)
From: Simon Josefsson <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-01.txt
Sender: [email-masked]

On Tue, 13 Nov 2001, Mark Crispin wrote:

> This suggests that ACL2 or ACLrev1 or ACLplus should have different commands
> and responses from the current SETACL/DELETEACL/GETACL/LISTRIGHTS/MYRIGHTS
> suite.  That way, it would be possible for a server to support both.

Adding a dummy command parameter might work.

* CAPABILITY ... ACL ACL2 ...
...
. GETACL "INBOX" "ACL2"
...
. MYRIGHTS "INBOX" "ACL2"
...

Date: Tue, 13 Nov 2001 16:11:51 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-01.txt
To: Cyrus Daboo <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

Cyrus' objections are valid.  I don't think that the conservative approach
will work.

This suggests that ACL2 or ACLrev1 or ACLplus should have different commands
and responses from the current SETACL/DELETEACL/GETACL/LISTRIGHTS/MYRIGHTS
suite.  That way, it would be possible for a server to support both.

We can still leverage on much of the existing work.  For example, we can
retain the existing lrswipcda style of single-letter rights, instead of going
to something like
 (\lookup \read \seen \write \insert \port \create \delete \administer)
which nominally would be more IMAPish.

Changing the commands and responses would give us other freedom as well, such
as being able to change the scheme of identifiers.  Instead of using a hack
like the $ prefix, we could make all identifiers have a type.  That would also
break the ambiguity between "anyone" and a user name of "anyone".

Date: Tue, 13 Nov 2001 19:09:20 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-01.txt
Sender: [email-masked]

--On Tuesday, November 13, 2001 5:46 PM -0500 Alexey Melnikov 
<[email-masked]> wrote:

> Oops, I forgot about this change. Unfortunately adding new rights is not
> backward compatible, so I will change capability to ACL2 or something like
> this.
>

If it were just a matter of adding a new right, that could be taken care of 
with 'additive' capabilities, ie * CAPABILITY ACL ACL2. But since the 
meaning of the d right is changing, a server can only advertise one of ACL 
or ACL2 and not both. Thus existing ACL clients will not work with ACL2 
servers. We must be sure that the meaning of the set of proposed rights for 
ACL2 will not change in the future - only addition of rights should be 
allowed.

-- 
Cyrus Daboo

Date: Tue, 13 Nov 2001 17:46:16 -0500
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-01.txt
Sender: [email-masked]

Simon Josefsson wrote:

> A client I use provides help texts on what each ACL capability means,
> so that I can make a good choice of what rights a mailbox should have.
> With this draft, how will I know that the "d" right is interpreted as
> in RFC 2086 or the draft?  How can I tell that the "x" right is
> supported at all?
>
> Replacing the standard is one thing, but servers out there won't
> magically upgrade at the moment RFC 2086 is updated by something else.
>
> I suspect the solutions to this problem are obvious, so I'll leave
> them as a exercise for the reader. :) Or is this discussed in the
> draft?  I couldn't find it, but perhaps I missed it.

Oops, I forgot about this change. Unfortunately adding new rights is not
backward compatible, so I will change capability to ACL2 or something like
this.

Alexey

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-01.txt
From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Nov 2001 22:12:17 +0100
Lines: 12
Sender: [email-masked]

A client I use provides help texts on what each ACL capability means,
so that I can make a good choice of what rights a mailbox should have.
With this draft, how will I know that the "d" right is interpreted as
in RFC 2086 or the draft?  How can I tell that the "x" right is
supported at all?

Replacing the standard is one thing, but servers out there won't
magically upgrade at the moment RFC 2086 is updated by something else.

I suspect the solutions to this problem are obvious, so I'll leave
them as a exercise for the reader. :) Or is this discussed in the
draft?  I couldn't find it, but perhaps I missed it.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-01.txt
Date: Tue, 13 Nov 2001 07:09:08 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-01.txt
	Pages		: 9
	Date		: 12-Nov-01
	
The ACL extension of the Internet Message Access Protocol [IMAP4]
permits access control lists to be manipulated through the IMAP
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-imapext-acl-01.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-acl-01.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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-acl-01.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sun, 11 Nov 2001 07:33:47 -0500
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Chris Newman <[email-masked]>, Mark Crispin <[email-masked]>, John Gardiner Myers <[email-masked]>
Subject: Updated ACL draft has been sent
Sender: [email-masked]

Hi,

Updated ACL draft should show up in IETF repository in a couple of days.

For now I've made only changes to make the extension as compatible with
ACL RFC as possible.
I've added two new rights: "x" for deleting mailbox and "e" for
expunging it. I've restored text that allows to implement either "union
of positive minus union of negatives" or "more specific rights win", not
just the former. I haven't touched negative rights identifiers.

Comments are welcome. There is a list of open issues in the beginning of
the document. Also I would rather hear from more people about breaking
backward compatibility with ACL RFC before I proceed any further.

Alexey

From: Steve Gardell <[email-masked]>
To: "'Shapira, Noam'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: SNAP question
Date: Thu, 8 Nov 2001 16:42:41 -0500 
Sender: [email-masked]

> -----Original Message-----
> From: Shapira, Noam [mailto:[email-masked]]
> Sent: Thursday, November 08, 2001 12:11 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: SNAP question
> 
> 
> 
> Hi all,
> 
> The SNAP next version is in it's final stages. As you can 
> recall the SNAP
> draft defines the protocol between a messaging system (e.g. 
> email server,
> voice mail) and a Notification Service. There are a few last 
> open issues
> that I would be happy if I got some suggestions.
> 
> In the last IETF (in London) I got some suggestions that it 
> is important to
> mention the issue of configuring the SNAP in the messaging 
> system - i.e. add
> the SNAP option for a user, configure the notification 
> service he will use,
> what type of request will be sent for this user (new message, 
> login, logout,
> etc.), the amount of retries and other options given in the SNAP.
> 
> The big question is how should it be done?
> 
> There are a few options like extensions of ACAP, LDAP, Sieve 
> based protocol
> and others. Another option is that this is not an interesting 
> questions and
> should be left open for different implementation.
> 

This would tend to be my inclination based on the observation that
messaging system provisioning is currently outside the scope
of standard protocols. This feels like just another piece
of user provisioning to me in the same general vein as quotas,
etc. If it were to be standardized I would suggest following
the general lead of the SIP subscribe/notify proposals.

> Noam
> 

From: "Shapira, Noam" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: SNAP question
Date: Thu, 8 Nov 2001 19:10:56 +0200 
Sender: [email-masked]

Hi all,

The SNAP next version is in it's final stages. As you can recall the SNAP
draft defines the protocol between a messaging system (e.g. email server,
voice mail) and a Notification Service. There are a few last open issues
that I would be happy if I got some suggestions.

In the last IETF (in London) I got some suggestions that it is important to
mention the issue of configuring the SNAP in the messaging system - i.e. add
the SNAP option for a user, configure the notification service he will use,
what type of request will be sent for this user (new message, login, logout,
etc.), the amount of retries and other options given in the SNAP.

The big question is how should it be done?

There are a few options like extensions of ACAP, LDAP, Sieve based protocol
and others. Another option is that this is not an interesting questions and
should be left open for different implementation.

Noam