Subject: ANNOTATEMORE Wildcards
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 12 Jul 2002 13:53:59 -0400 (EDT)
List-Id: <ietf-imapext.imc.org>

I've been doing some work on our implementation of ANNOTATEMORE, and I've
been having trouble deciding what to do with some globs.

My concerns focus mostly around the integration of the mailbox names into
entry names.  If '.' is being used as the mailbox hierarchy delimiter,
does % fail to match on '/' and '.'?  Does it include or exclude '}'?

Does '/mailbox/%/foo' resolve to the same thing as '/mailbox/{*}/foo' or
'/mailbox/{%}/foo'

What if only one of the braces is missing?

Does '/mailbox/{user.%/foo' work equivilantly to '/mailbox/{user.*}/foo'
or '/mailbox/{user.%}/foo'?

Also, is it really necessary to allow '/mail%/{user.foo}/foo' as a
pattern?  Personally, I don't see any use for wildcards at all in the
first level of mailbox and server annotations, especially since mailbox
annotations have the second level of mailbox names before you get to the
actual entry names.

I propose the following change:

Allow wildcards only in the following locations (denoted by the * below):

/mailbox/{*}/*
/server/*

For mailbox annotations, inside of the braces % will refuse to match the
mailbox hierarchy separator (as it does in LIST).  Otherwise, '%' will not
match / in entry names (note that this does not affect attribute names).

I think this preserves all of the truly useful functionality, while
removing a lot of ambiguity (and possibly simplifying some
implementations).  Yes, it's true, you can no longer do a getannotation
for * without two round trips, but I don't think we really want to
encourage getannotation * anyway.

So, suggested text at the end of section 7.1:

    "*" and "%" wildcard characters can be used in either specifier to
    match match one or more characters at that position, with the
    exception that "%" does not match the hierarchy delimiter for the
    specifier it appears in (i.e. "/" for an entry specifier or "." for
    an attribute specifer).  Thus an entry specifier of "/server/%"
    would match entries such as "/server/comment" and "/server/version",
    but not "/server/comment/note".

    Wildcard characters MUST NOT appear in the top level
    hierarchies, '/server' and '/mailbox'.  Additionally, mailbox
    annotations MUST always delimit the mailbox name with both braces,
    though wildcard characters are permitted within the braces.
    Within the braces, '%' and '*' are interpreted as they would be
    for a LIST command [IMAP4].  Thus, '/mailbox/{user.%}/comment' is
    valid, but '/mailbox/{user*/comment' is not.

We should also change the ABNF for entry-match:

entry-match = DQUOTE entry-match-toplevel *("/" 1*entry-match-atom) DQUOTE

entry-match-toplevel = "/server" / "/mailbox/{" list-mailbox "}"

(Where list-mailbox is as defined in [IMAP4])

Note that this allows the requests of the entries /server and
/mailbox/{foo}, which both are defined to not have any attributes (but so
did the original ABNF, so I didn't think to change it).

Also, I haven't seen any comments on Ken's previous post, about ABNF of
responses not matching the examples.  The examples have parenthesis around
each entry-att as well as the complete list, where the grammar only shows
parenthesis around the list.

Personally, I believe the grammer specifies something much cleaner than is
in the examples:

entry-att = entry SP "(" att-value *(SP att-value) ")"

and

entry-list = entry-att / "(" entry-att *(SP entry-att) ")"

Ken and I believe this also affects the ANNOTATE draft.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W+ N- o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b++ DI+++ G e h r y?
------END GEEK CODE BLOCK-----

Date: Fri, 05 Jul 2002 15:59:37 -0600
From: Alexey Melnikov <[email-masked]>
Reply-To: [email-masked]
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-05.txt
Sender: [email-masked]

[email-masked] wrote:

> 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-05.txt
>         Pages           : 9
>         Date            : 02-Jul-02
>
> 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-05.txt
>

List of changes (can be found in Appendix):

  21. Added mail client security considerations when dealing with special
      identifier "anyone".

  22. Clarified that negative rights are not the same as DELETEACL (ACL DELETE).

  23. Removed the requirement to check the "r" right for CHECK, SEARCH and
      FETCH, as this is required for SELECT/EXAMINE to be successful.

  24. Added note that a server can modify an ACL for any identifier(s) as a
      side effect of performing SETACL/DELETEACL/REPLACEACL
      (ACL STORE/DELETE/SET). Also specified that the server MUST send
      untagged ACL response if it does that. Updated command definition
      to include optional ACL untagged response.

  25. Fixed typo in 10.1. (Was "ACL=...", not "ACL2=...")

  26. Cleaned up section 10.2 a bit.

  27. LISTRIGHTS (ACL LIST) requires same rights as MYRIGHTS.

  28. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY
      response codes.

Please, read this carefully. I hope it makes sense, but it required introducing many special definitions
just for this section.

  29. Changed ABNF for rigths/mod_rights to be quoted instead of astring.

I did this change as I've heard no objections after my last message on the topic.

  30. Changed syntax of ACL2 commands according to the following table:
        SETACL          => ACL STORE
        DELETEACL       => ACL DELETE
        REPLACEACL      => ACL SET
        GETACL          => ACL GET
        LISTRIGHTS      => ACL LIST

        MYRIGHTS was left as is

      Changed syntax of ACL2 responses:
        ACL             => ACLINFO
        LISTRIGHTS      => RIGHTS-INFO

        MYRIGHTS was left as is (no semantic change)

      Any better suggestions for names are welcome.

Also, one big change missing from this list is changing identifiers as per recent discussion.

To Do List:

  3). Update syntax to allow for multiple mailboxes and masks.
      Describe partial failures.

Sorry, I didn't have time to finish this. After this change the ACL2 document should be "feature
complete", i.e. only issues found in the document that are enclosed in <<>> should be resolved.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-05.txt
Date: Wed, 03 Jul 2002 06:30:36 -0400
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-05.txt
	Pages		: 9
	Date		: 02-Jul-02
	
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-05.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-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-acl-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="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shapira-snap-04.txt
Date: Tue, 02 Jul 2002 06:33:42 -0400
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 
	Filename	: draft-shapira-snap-04.txt
	Pages		: 30
	Date		: 01-Jul-02
	
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 mailing list has been established to discuss this draft and
promote the issue of Notification to RFC. To subscribe, send
email with 'subscribe snap' to [email-masked]
or using web at http://www.neystadt.org/cgi-bin/majordomo.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shapira-snap-04.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-04.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-04.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-04.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-neystadt-imap-status-counters-01.txt
Date: Tue, 02 Jul 2002 06:32:25 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 rev1 û STATUS-COUNTERS Extension
	Author(s)	: J. Neystadt, A. Melnikov
	Filename	: draft-neystadt-imap-status-counters-01.txt
	Pages		: 10
	Date		: 01-Jul-02
	
The STATUS-COUNTERS extends IMAP4rev1Æs STATUS command. This 
extension adds the following functionality: 
Enable MUA to get mailbox counters per groups of messages, grouped 
according to the value of Message-Context header field. For 
example, the MUA can find out that the Inbox contains 5 unseen fax 
messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-neystadt-imap-status-counters-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-neystadt-imap-status-counters-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-neystadt-imap-status-counters-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-neystadt-imap-status-counters-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 12 Jul 2002 13:53:59 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: ANNOTATEMORE Wildcards
Sender: [email-masked]

I've been doing some work on our implementation of ANNOTATEMORE, and I've
been having trouble deciding what to do with some globs.

My concerns focus mostly around the integration of the mailbox names into
entry names.  If '.' is being used as the mailbox hierarchy delimiter,
does % fail to match on '/' and '.'?  Does it include or exclude '}'?

Does '/mailbox/%/foo' resolve to the same thing as '/mailbox/{*}/foo' or
'/mailbox/{%}/foo'

What if only one of the braces is missing?

Does '/mailbox/{user.%/foo' work equivilantly to '/mailbox/{user.*}/foo'
or '/mailbox/{user.%}/foo'?

Also, is it really necessary to allow '/mail%/{user.foo}/foo' as a
pattern?  Personally, I don't see any use for wildcards at all in the
first level of mailbox and server annotations, especially since mailbox
annotations have the second level of mailbox names before you get to the
actual entry names.

I propose the following change:

Allow wildcards only in the following locations (denoted by the * below):

/mailbox/{*}/*
/server/*

For mailbox annotations, inside of the braces % will refuse to match the
mailbox hierarchy separator (as it does in LIST).  Otherwise, '%' will not
match / in entry names (note that this does not affect attribute names).

I think this preserves all of the truly useful functionality, while
removing a lot of ambiguity (and possibly simplifying some
implementations).  Yes, it's true, you can no longer do a getannotation
for * without two round trips, but I don't think we really want to
encourage getannotation * anyway.

So, suggested text at the end of section 7.1:

    "*" and "%" wildcard characters can be used in either specifier to
    match match one or more characters at that position, with the
    exception that "%" does not match the hierarchy delimiter for the
    specifier it appears in (i.e. "/" for an entry specifier or "." for
    an attribute specifer).  Thus an entry specifier of "/server/%"
    would match entries such as "/server/comment" and "/server/version",
    but not "/server/comment/note".

    Wildcard characters MUST NOT appear in the top level
    hierarchies, '/server' and '/mailbox'.  Additionally, mailbox
    annotations MUST always delimit the mailbox name with both braces,
    though wildcard characters are permitted within the braces.
    Within the braces, '%' and '*' are interpreted as they would be
    for a LIST command [IMAP4].  Thus, '/mailbox/{user.%}/comment' is
    valid, but '/mailbox/{user*/comment' is not.

We should also change the ABNF for entry-match:

entry-match = DQUOTE entry-match-toplevel *("/" 1*entry-match-atom) DQUOTE

entry-match-toplevel = "/server" / "/mailbox/{" list-mailbox "}"

(Where list-mailbox is as defined in [IMAP4])

Note that this allows the requests of the entries /server and
/mailbox/{foo}, which both are defined to not have any attributes (but so
did the original ABNF, so I didn't think to change it).

Also, I haven't seen any comments on Ken's previous post, about ABNF of
responses not matching the examples.  The examples have parenthesis around
each entry-att as well as the complete list, where the grammar only shows
parenthesis around the list.

Personally, I believe the grammer specifies something much cleaner than is
in the examples:

entry-att = entry SP "(" att-value *(SP att-value) ")"

and

entry-list = entry-att / "(" entry-att *(SP entry-att) ")"

Ken and I believe this also affects the ANNOTATE draft.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W+ N- o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b++ DI+++ G e h r y?
------END GEEK CODE BLOCK-----

Date: Fri, 05 Jul 2002 15:59:37 -0600
From: Alexey Melnikov <[email-masked]>
Reply-To: [email-masked]
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-05.txt
Sender: [email-masked]

[email-masked] wrote:

> 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-05.txt
>         Pages           : 9
>         Date            : 02-Jul-02
>
> 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-05.txt
>

List of changes (can be found in Appendix):

  21. Added mail client security considerations when dealing with special
      identifier "anyone".

  22. Clarified that negative rights are not the same as DELETEACL (ACL DELETE).

  23. Removed the requirement to check the "r" right for CHECK, SEARCH and
      FETCH, as this is required for SELECT/EXAMINE to be successful.

  24. Added note that a server can modify an ACL for any identifier(s) as a
      side effect of performing SETACL/DELETEACL/REPLACEACL
      (ACL STORE/DELETE/SET). Also specified that the server MUST send
      untagged ACL response if it does that. Updated command definition
      to include optional ACL untagged response.

  25. Fixed typo in 10.1. (Was "ACL=...", not "ACL2=...")

  26. Cleaned up section 10.2 a bit.

  27. LISTRIGHTS (ACL LIST) requires same rights as MYRIGHTS.

  28. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY
      response codes.

Please, read this carefully. I hope it makes sense, but it required introducing many special definitions
just for this section.

  29. Changed ABNF for rigths/mod_rights to be quoted instead of astring.

I did this change as I've heard no objections after my last message on the topic.

  30. Changed syntax of ACL2 commands according to the following table:
        SETACL          => ACL STORE
        DELETEACL       => ACL DELETE
        REPLACEACL      => ACL SET
        GETACL          => ACL GET
        LISTRIGHTS      => ACL LIST

        MYRIGHTS was left as is

      Changed syntax of ACL2 responses:
        ACL             => ACLINFO
        LISTRIGHTS      => RIGHTS-INFO

        MYRIGHTS was left as is (no semantic change)

      Any better suggestions for names are welcome.

Also, one big change missing from this list is changing identifiers as per recent discussion.

To Do List:

  3). Update syntax to allow for multiple mailboxes and masks.
      Describe partial failures.

Sorry, I didn't have time to finish this. After this change the ACL2 document should be "feature
complete", i.e. only issues found in the document that are enclosed in <<>> should be resolved.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-05.txt
Date: Wed, 03 Jul 2002 06:30:36 -0400
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-05.txt
	Pages		: 9
	Date		: 02-Jul-02
	
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-05.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-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-acl-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="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shapira-snap-04.txt
Date: Tue, 02 Jul 2002 06:33:42 -0400
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 
	Filename	: draft-shapira-snap-04.txt
	Pages		: 30
	Date		: 01-Jul-02
	
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 mailing list has been established to discuss this draft and
promote the issue of Notification to RFC. To subscribe, send
email with 'subscribe snap' to [email-masked]
or using web at http://www.neystadt.org/cgi-bin/majordomo.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shapira-snap-04.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-04.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-04.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-04.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-neystadt-imap-status-counters-01.txt
Date: Tue, 02 Jul 2002 06:32:25 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 rev1 û STATUS-COUNTERS Extension
	Author(s)	: J. Neystadt, A. Melnikov
	Filename	: draft-neystadt-imap-status-counters-01.txt
	Pages		: 10
	Date		: 01-Jul-02
	
The STATUS-COUNTERS extends IMAP4rev1Æs STATUS command. This 
extension adds the following functionality: 
Enable MUA to get mailbox counters per groups of messages, grouped 
according to the value of Message-Context header field. For 
example, the MUA can find out that the Inbox contains 5 unseen fax 
messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-neystadt-imap-status-counters-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-neystadt-imap-status-counters-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-neystadt-imap-status-counters-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-neystadt-imap-status-counters-01.txt

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

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

--OtherAccess--

--NextPart--