Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
From: Randall Gellens <[email-masked]>
To: Alexey Melnikov <[email-masked]>, [email-masked]
Date: Mon, 26 Mar 2001 18:06:47 -0800
List-Id: <ietf-imapext.imc.org>

At 11:39 PM -0700 3/18/01, Alexey Melnikov wrote:

>   >    /message/smtp-envelope
>>         Defines the top-level of entries which together describe the
>>         SMTP envelope used in delivery of the message.  There are no
>>         attributes at this level.  The client SHOULD NOT modify the
>>         /message/smtp-envelope entry or any sub-entries or any of their
>>         attributes, except in messages which have the DRAFT flag set.
>
>  Randy, can you add /message/smtp-envelope/auth_sender for 
> authenticated sender
>  (SMTP AUTH extension)?
>  This will replace Netscape XSENDER extension.

Seems like a good idea.

Date: Mon, 26 Mar 2001 15:58:01 -0800
From: Chris Newman <[email-masked]>
Subject: RE: X-NETSCAPE
To: "Neystadt, John" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

X-Mailer: Mulberry/2.1.0a2 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--On Monday, March 19, 2001 20:44 +0200 "Neystadt, John" 
<[email-masked]> wrote:
> My original suggestion was about proxyauth. Did you picked up Alexey's
> glove to write a draft on that? I beleive that it is a very important
> feature that anyhow supported by many servers and we will benefit from
> moving it towards a standard. If you don't up to it, may be somebody else
> (myself?) will do it?

The PLAIN mechanism in RFC 2595 supports proxy auth, as does the DIGEST-MD5 
mechanism in RFC 2831.  If you want the feature, encourage people to 
implement these specs.

		- Chris

Date: Fri, 23 Mar 2001 13:59:36 -0600
From: Chris Newman <[email-masked]>
Subject: Re: informal IMAPEXT discussion
To: "Alan K. Stebbens" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Monday, March 19, 2001 21:30 -0600 "Alan K. Stebbens" 
<[email-masked]> wrote:
> Chris, can you or someone post a summary of this informal discussion?

I was busy participating so I didn't take a lot of notes.  If someone else 
has better notes, please post them.  But here's what I have:

----
Discussed binary extension.  Decided there is a need for sizes of binary 
objects, will try BINARYSIZE approach.

Discussed ACL draft and worked through open issues.  Current ACL RFC is 
widely implemented and interoperates, but has some deficiencies: missing 
"x" right for deleting mailboxes, too vague about semantics, no way to map 
genernal names to authorization identifiers.  Need to include advisory URL 
to describe how to look up users and groups without getting IMAP into 
directory service area (I volunteered to write first draft of text 
describing what the URL means).  John will talk to Mark about some other 
issues, but it may be necessary to have two different ACL extensions in 
order to make a good UI practical.

Discussed SORT/THREAD/VIEW.  Some believe that "lightweight" clients won't 
use threading due to complexity, so windowing thread may not be worth the 
trouble.  There are three common thread algorithms with about 33% mindshare 
in user community for each.  SORT+ORDEREDSUBJECT is one, THREAD extension 
has another, and third isn't documented yet.  Some believe that windowing 
removes most need for dynamic updates (at least with sort) since re-issuing 
the sort doesn't consume as much bandwidth.  Some discussion of WINDOWing 
for SORT/THREAD.  One question why we can't have a select-based mechanism 
which replaces seqno with view position.  Cyrus and I will work through a 
different approach to WINDOWing that should be simpler than the previous 
VIEW proposal and is layered on SORT/THREAD base spec.

Deferred discussion of CHANNEL since voice mail folks weren't present.

		- Chris

Date: Thu, 22 Mar 2001 19:42:15 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: outline of what to do with ACL
Organization: Networks & Distributed Computing
Sender: [email-masked]

Here's a basic outline of what I'd like to do with ACLPLUS.  It's not in
a formal I-D, but I'd like to hear comments.  Due to all the stuff in this
proposal, I imagine that a lot of clarifications/fine-tuning will be
needed.

Goals:	functional upwards compatibility with RFC 2086.  Add missing
	functionality and desirable extensions (e.g. wildcards).  Interact
	with extended LIST work.  Be able to represent (but not require)
	filesystem style access controls as well as existing ACL access
	controls.  Don't require semantics that are unimplementable on
	some platforms (= allow server to say NO and/or don't have side
	effects that make something unusable).
Non-goal: strict compatibility with RFC 2086

The general idea is that it should be possible to have a server that
supports both ACL and ACLPLUS, although such a server won't be able to use
all of ACLPLUS.

ACLPLUS identifiers:

syntax:
	["$"] astring

RFC 2086 style "negative rights" are eliminated, along with inherience.

An identifier that does not begin with "$" is a login user name, as in
RFC 2086.

Definable identifiers.  Server implementations are *NOT* required to
use any of these, but if they do, these are their semantics.  Note
that definable identifiers may expand to other definable identifiers.

$G$xxx	global identifier xxx.  Valid everywhere
$U$xxx	per-user identifier xxx.  Valid only for the logged-in user
$M$xxx	per-mailbox identifer xxx.  Valid only for this mailbox
$xxxxx	reserved for future definition

Non-definable identifiers.  Server implementations SHOULD support $WORLD,
and MUST support anyone and user names.  However, a server can respond with
a NO.

$WORLD		all authorized users but not anonymous
$ANONYMOUS	anonymous users
$DISABLE	disabled rights (see below)

There is no inheritance of rights, not even from $WORLD.  This means
that RFC 2086 negative rights aren't needed.

If the user name is listed, those rights are used; otherwise, the
first applicable identifier in the ACL defines the (only) rights that
the user gets.  For example, given
	Joe= $G$hackers=rwipslda $ALL=rw
Joe has no access to the mailbox, even though he's a member of the
global "hackers" group (and $ALL).

The $DISABLE identifier is special.  This identifier disables the
listed rights for all other identifiers.  For example:
	Joe=rwipslda $ALL=rw $DISABLE=rwipslda
denies all access to all users, including Joe.  A sample use of
$DISABLE is to deny access temporarily (e.g. while some system
administration task is going on); this is basically what RFC 2086
negative rights were intended to do.

ACL rights:

These try to be as compatible with RFC 2086 as possible.

l	list
r	read
s	permanent seen status
w	write (permanent flags other than \Seen and \Deleted)
i	insert [APPEND, COPY to mailbox]
p	post to mailbox
c	create inferior mailboxes
d	permanent delete status
a	administer (ACL operations permitted)
x	delete mailbox (new, not in RFC 2086)
e	expunge mailbox (new, not in RFC 2086)

ACLPLUS Operations:

These commands are completely different from RFC 2086.  Compatibility
operations are below.

Wildcards permitted for mailbox in all commands.

ACL SET mailbox 1*(identifier rights)
	set the ACL, replacing existing ACL

ACL MODIFY mailbox 1*(identifier rights)
	modify the identifier/rights, leaving others unchanged

ACL REMOVE mailbox *identifier
	remove all rights for the specified identifiers

ACL TEST mailbox identifier rights
	test mailbox to see if the identifier has the given rights

ACL DEFINE mailbox 1*(identifier definition)
	define an identifier.  Mailbox may be empty for global identifiers

ACL EXPAND mailbox 1*identifier
	return definitions for the specified identifers

ACL EXPAND returns the following new untagged value:

* DEFINEID mailbox 1*(identifier definition)

Extended LIST command.  Note that the exact syntax depends upon how the
extended LIST word goes; this is just for illustration purposes.

LIST reference name "(" 1*("ACL" / "RIGHTS" / "MYRIGHTS") ")"

Extended LIST returns extended forms of the LIST response, using
attributes.  We can use of colon, underscore, and equals as delimiters
in the obvious places.  Here's how the RFC 2086 examples would look in
the new style:
	* ACL INBOX Fred rwipslda Joe rw
=>	* LIST (\NoInferiors \ACL:Fred=rwipslda:Joe=rw) NIL INBOX
	* LISTRIGHTS ~/Mail/saved smith la r swicd
=>	* LIST (\NoInferiors \RIGHTS:smith=la_r_swicd) NIL INBOX
	* MYRIGHTS INBOX
=>	* LIST (\NoInferiors \MYRIGHTS:rwipslda) NIL INBOX

Note that all IMAP4rev1 compliant implementations support this now as part
of the flag-extension rule.

We can also add "CHILD" and "REFERRALS" to the extended LIST command
if the associated capability is there.

RFC 2086 compatibility operations:

This is only if you advertise both the ACLPLUS and ACL rights.

No "x" or "e" rights.  OK to ignore this problem with RFC 2086, but
not with Myers' new draft.

Here are the equivalents to RFC 2086 commands, but these equivalents return
the new extended LIST form.  If you want the RFC 2086 responses, you must use
RFC 2086 commands.

SETACL mailbox identifer rights
	=> ACL MODIFY mailbox identifier rights

DELETEACL mailbox identifier
	=> ACL REMOVE mailbox identifier

GETACL mailbox
	=> LIST "" mailbox (\ACL)

LISTRIGHTS mailbox identifier
	=> LIST "" mailbox (\RIGHTS)

MYRIGHTS mailbox
	=> LIST "" mailbox (\MYRIGHTS)

Unix filesystem implementation specifics

Three or four possible identifiers on a mailbox.  Owner is $M$owner,
group is $M$group, other user is $WORLD.  It may also implement
$ANONYMOUS.  It will answer NO to an attempt to create any other
identifier.

$M$owner is defined as one or more users (no "$" in name).

$M$group is defined as $G$xxx where xxx is a UNIX group name.

Don't use $U$xxx or $DISABLE at all.

ACL rights for flat-file formats (all except mh and mx)

l	(mailbox only) 4 bit in containing directory
r	(mailbox only) 1 bit in containing directory, 4 bit in file
wisde	(mailbox only) 1 bit in containing directory, 2 bit in file
p	?? what to do about this ??
c	(directory only) 2 bit in containing directory
x	2 bit in containing directory, if sticky bit set then owner
a	user is owner or Administrator

ACL rights for one-message/one-file formats (mh and mx)

l	4 bit in containing directory
r	1 bit in containing directory, 4 bit
wisde	1 bit in containing directory, 2 bit
c	2 bit in containing directory
x	2 bit in containing directory, if sticky bit set then owner
p	?? what to do about this ??
a	user is owner or Administrator

ACL rights for news

l	4 bit in containing directory
r	1 bit in containing directory, 4 bit
d	always set
wiseacx	never set
p	?? what to do about this ??

Example:
	* LIST (\NoInferiors \ACL:$OWNER=lrswipcdxa:$WORLD=p) NIL INBOX
	* LIST (\ACL:$OWNER=lrswipcdxa:$GROUP=lrswipd:$WORLD=lrp) "/" sharedmbx
	* DEFINEID INBOX $OWNER (mary)
	* DEFINEID pine-bugs $GROUP $G$pineteam
	* DEFINEID "" $G$pineteam mikes hubert mrc jpf

Classes of users.  * identifies things that require external privileged program

Ordinary users:
 . permitted to change mode of their own mailbox
 . permitted to change group of their own mailbox
 * permitted to create and manage a personal group

Power users (members of group imappower):
 ordinary user, plus:
 * permitted to change owner of their own mailbox
 * permitted to create public groups
 * may manage any group in which he's the first member

Administrators (members of group mailadm):
 power user, plus:
 * permitted to change mode of any mailbox
 * permitted to change owner of any mailbox
 * permitted to change group of any mailbox
 * permitted to create and manage any group

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Thu, 22 Mar 2001 09:21:00 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Eric Burger <[email-masked]>
cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Last, last, last visit to Critical-Content / Content-Disposition
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 22 Mar 2001, Eric Burger wrote:
> Given the realities of BODYSTRUCTURE, and the fact that we are NOT bending
> Content-Disposition too far, the consensus is to use a CRITICALITY parameter
> to Content-Disposition, rather than a new MIME entity, for criticality
> marking.

Sounds good to me.  I'll sign off on that.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Reply-To: <[email-masked]>
From: "Eric Burger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Last, last, last visit to Critical-Content / Content-Disposition
Date: Thu, 22 Mar 2001 11:45:34 -0500
Importance: Normal
Sender: [email-masked]

At the VPIM lunch BOF, I reviewed why we said "no" to putting
Critical-Content as a parameter to Content-Disposition.

Going back to the deep, dark past, the original proposal was to do the
following:

     Content-Disposition: attachment; content-notification=true

This was shot down because per-part notification control and part type
labeling did not belong as a "disposition".  This scenario came about in the
evolution of partial-non-delivery notification (PNDN) to the critical
content concept.

Looking over the archives and some private correspondence, it is clear that
content-notification, as a part of PNDN, is an inappropriate use of
Content-Disposition.  However, it is also clear that criticality IS an
appropriate use of Content-Disposition.

Given the realities of BODYSTRUCTURE, and the fact that we are NOT bending
Content-Disposition too far, the consensus is to use a CRITICALITY parameter
to Content-Disposition, rather than a new MIME entity, for criticality
marking.

The -03 way of marking:

   Critical part:
       --Next part
       Content-Type: ...
       Content-Disposition: attachment; file=foo.bar
       Content-Criticality: CRITICAL
       ...

   Not important part:
       --Next part
       Content-Type: ...
       Content-Disposition: attachment; file=foo.bar
       Content-Criticality: IGNORE
       ...

The -04 (future) way of marking:
   Critical part:
       --Next part
       Content-Type: ...
       Content-Disposition: attachment; file=foo.bar; criticality=CRITICAL
       ...

   Not important part:
       --Next part
       Content-Type: ...
       Content-Disposition: attachment; file=foo.bar; criticality=IGNORE
       ...

Speak now...

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: IMAP CHANNEL discussion list
Organization: ACI Worldwide
Date: Wed, 21 Mar 2001 13:18:44 -0700
Sender: [email-masked]

At the VPIM lunch BOF today we decided that, since both the IMAP
and the VPIM communities have interest in this extension, we will
use the [email-masked] mailing list for further discussions.
This eliminates the need for VPIM folks to subscribe to the IMAP
lists, and vice versa. To subscribe:

	echo subscribe | mail [email-masked]

--lyndon

From: Lyndon Nerenberg <[email-masked]>
Organization: ACI / Messagingdirect
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: BINARY grammar 
Date: Tue, 20 Mar 2001 13:28:34 -0700
Sender: [email-masked]

> I'm not clear on how your proposed change would prevent NUL from being
> sent to unsuspecting clients.

Thanks, I knew I had missing something *blatently* obvious :-(

--lyndon

Date: Tue, 20 Mar 2001 12:21:35 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: <[email-masked]>
Subject: Re: BINARY grammar
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 20 Mar 2001, Lyndon Nerenberg wrote:
> Having re-read the grammar in 2060 I'm wondering if it would be
> better to change the definition of <string> to include <literal8>
> instead of special casing FETCH and APPEND.

literal8 is a misnomer since existing literals are 8bit.  It should be
something like literalb or binary_literal to reflect the inclusion of NUL.

I'm not clear on how your proposed change would prevent NUL from being
sent to unsuspecting clients.

It almost seems easier to remove the NUL restriction from CHAR and CHAR8,
and add a NUL restriction to TEXT_CHAR, all in the base spec.  But that
might break software that depends upon the NUL restirction.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: BINARY grammar
Organization: ACI / MessagingDirect
Date: Tue, 20 Mar 2001 13:06:40 -0700
Sender: [email-masked]

Currently I define a new protocol element <literal8> for 8bit data
with NULs. FETCH BINARY is explicitly defined to return <literal8>,
and APPEND is extended to accept <literal8> in addition to <literal>.

Having re-read the grammar in 2060 I'm wondering if it would be
better to change the definition of <string> to include <literal8>
instead of special casing FETCH and APPEND. This change would
simplify the BINARY specification, and simplifies the resulting
parser changes. I'm just worried that making this change to <string>
might break something. (Although nothing bad is immediately obvious
as I look at 2060.)

--lyndon

Date: Tue, 20 Mar 2001 11:49:46 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, <[email-masked]>
Subject: Re: BINARY command syntax
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 20 Mar 2001, Alexey Melnikov wrote:
> I like BINARY.SIZE, but it is one character longer :-).

Me too.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Tue, 20 Mar 2001 12:08:00 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lyndon Nerenberg <[email-masked]>
CC: [email-masked]
Subject: Re: BINARY command syntax
Sender: [email-masked]

Lyndon Nerenberg wrote:

> Do people have a
> preference for "FETCH BINARYSIZE" vs. "FETCH BINARY.SIZE" ?

I like BINARY.SIZE, but it is one character longer :-).

Alexey

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: BINARY command syntax
Organization: ACI / MessagingDirect
Date: Tue, 20 Mar 2001 11:44:16 -0700
Sender: [email-masked]

At the IMAP BOF yesterday we agreed to kill BINARYSTRUCTURE and
add a FETCH item to obtain the decoded size. Do people have a
preference for "FETCH BINARYSIZE" vs. "FETCH BINARY.SIZE" ?
(FETCH BINARY and FETCH BINARY.PEEK remain as is.)

--lyndon

Date: Mon, 19 Mar 2001 22:58:08 -0800
From: John Gardiner Myers <[email-masked]>
Subject: Re: X-NETSCAPE
To: "Jim O'Connor" <[email-masked]>
Cc: Mike Macgirvin <[email-masked]>, Neystadt John <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms68B20B98EF8A88F53EA90A63
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim O'Connor wrote:
> 
> I have some questions about your reply.  We currently have several customers using > Netscape Messaging servers. We find proxyauth very useful and use it for a number of > specialized applications:

The proxyauth command is made obsolete by the proxy authentication
(separate authorization id) feature of SASL (RFC 2222).
--------------ms68B20B98EF8A88F53EA90A63
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

--------------ms68B20B98EF8A88F53EA90A63--

Date: Mon, 19 Mar 2001 21:30:02 -0600
From: "Alan K. Stebbens" <[email-masked]>
Reply-To: "Alan K. Stebbens" <[email-masked]>
Organization: Openwave Systems, Inc.
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Re: informal IMAPEXT discussion
Sender: [email-masked]

Hello Chris,

Monday, March 19, 2001, 10:56:31 AM, you wrote:

CN> We're going to have an informal IMAPEXT discussion during the afternoon 
CN> session at the IETF today.  We'll be discussing the VPIM-related extensions 
CN> since the VPIM people are around, as well as other issues the participants 
CN> desire.

CN> Meet by the IETF message board at 1 PM today.

Chris, can you or someone post a summary of this informal discussion?

Thanks.

-- 
Best regards,
 Alan K. Stebbens <[email-masked]>
 Sr. Technical Product Manager
 End-to-End Architecture & Application Standards
 Openwave Systems, Inc.
 Voice: +1.805.886.8886  Fax: +1.818.464.6943

If all you have is a hammer, then everything looks like a nail!

Date: Mon, 19 Mar 2001 20:48:18 -0600
From: "Alan K. Stebbens" <[email-masked]>
Reply-To: "Alan K. Stebbens" <[email-masked]>
Organization: Openwave Systems, Inc.
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Re: informal IMAPEXT discussion
Sender: [email-masked]

Hello Chris,

Monday, March 19, 2001, 10:56:31 AM, you wrote:

CN> We're going to have an informal IMAPEXT discussion during the afternoon 
CN> session at the IETF today.  We'll be discussing the VPIM-related extensions 
CN> since the VPIM people are around, as well as other issues the participants 
CN> desire.

CN> Meet by the IETF message board at 1 PM today.

Chris, can you or someone post a summary of this informal discussion?

Thanks.

-- 
Best regards,
 Alan K. Stebbens <[email-masked]>
 Sr. Technical Product Manager
 End-to-End Architecture & Application Standards
 Openwave Systems, Inc.
 Voice: +1.805.886.8886  Fax: +1.818.464.6943

If all you have is a hammer, then everything looks like a nail!

Date: Mon, 19 Mar 2001 14:27:34 -0800
From: John Gardiner Myers <[email-masked]>
Subject: Re: X-NETSCAPE
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms0ED5AD9B8625A941DBAED15F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(resending)

"Neystadt, John" wrote:
> As to X-NETSCAPE (ProxyAuth) you can read at
> http://help.netscape.com/kb/corporate/19980217-17.html.

X-NETSCAPE is more than proxyauth, there's a way to retrieve a URL for
user self-administration from the server.  I don't have a spec on hand;
the extension is obsolete.

The following is the specification for XSERVERINFO:

------------------------------------------------

The CAPABILITY tag returned by this extension is "XSERVERINFO".
Servers which advertise the XSERVERINFO capability must support both
the XSERVERINFO and XMAILBOXINFO commands.

XSERVERINFO

Syntax:

serverinfo_cmd = "XSERVERINFO" 1*(SPACE atom)

serverinfo_data = "XSERVERINFO" 1*(SPACE atom SPACE nstring)

Description:

The XSERVERINFO command returns information about the IMAP server.
The client specifies in the arguments to the XSERVERINFO the names of
the information items it is requesting.  The server issues an untagged
XSERVERINFO response including the names and values of each of the
requested items before issuing a tagged OK response to XSERVERINFO
command.

If the client requests an information item that the server has no
knowledge of, the server MUST return a NIL value.

Currently-defined information items are:

        MANAGEACCOUNTURL        The URL for managing the user's account
        MANAGELISTSURL          The URL for managing mailing lists
        MANAGEFILTERSURL        The URL for managing filters for
                                incoming mail

Example:

C: A001 XSERVERINFO MANAGEACCOUNTURL FOOBAR
S: * XSERVERINFO MANAGEACCOUNTURL "https://[email-masked]:3333/"
FOOBAR NIL
S: A001 OK Completed

XMAILBOXINFO

Syntax:

mailboxinfo_cmd = "XMAILBOXINFO" SPACE mailbox 1*(SPACE atom)

mailboxinfo_data = "XMAILBOXINFO" SPACE mailbox 1*(SPACE atom SPACE
nstring)

Description:

The XMAILBOXINFO command returns information about the specified IMAP
mailbox.  The client specifies in the arguments to the XMAILBOXINFO
the mailbox for which information is being requested and the names of
the information items it is requesting.  The mailbox issues an
untagged XMAILBOXINFO response including mailbox name and the names
and values of each of the requested items before issuing a tagged OK
response to XMAILBOXINFO command.

If the client requests an information item that either the server has
no knowledge of or which is not applicable to the mailbox, the server
MUST return a NIL value.

Currently-defined information items are:

        MANAGEURL               The URL for managing the mailbox
        POSTURL                 The URL for posting to the mailbox
                                "news:" and "mailto:" URLS are most
                                appropriate, though a client must
                                safely ignore unrecognized URL types.

Example:

C: A001 XMAILBOXINFO "INBOX" MANAGEURL POSTURL
S: * XMAILBOXINFO "INBOX" MANAGEURL
   "https://srvr.mcom.com:3333/user/userid/INBOX"
    POSTURL "mailto:[email-masked]"
S: A001 OK Completed
--------------ms0ED5AD9B8625A941DBAED15F
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

--------------ms0ED5AD9B8625A941DBAED15F--

From: "Neystadt, John" <[email-masked]>
To: "'John Gardiner Myers '" <[email-masked]>
Cc: "[email-masked] ' '" <[email-masked]>, "[email-masked]' '" <[email-masked]>
Subject: RE: X-NETSCAPE
Date: Mon, 19 Mar 2001 20:44:15 +0200
Sender: [email-masked]

Thanx!

My original suggestion was about proxyauth. Did you picked up Alexey's glove
to write a draft on that? I beleive that it is a very important feature that
anyhow supported by many servers and we will benefit from moving it towards
a standard. If you don't up to it, may be somebody else (myself?) will do
it?

John

-----Original Message-----
From: John Gardiner Myers
To: Neystadt, John
Cc: 'Tony Hansen '; 'Alexey Melnikov '; [email-masked] ';
[email-masked]'
Sent: 3/19/01 7:27 PM
Subject: Re: X-NETSCAPE

"Neystadt, John" wrote:
> As to X-NETSCAPE (ProxyAuth) you can read at
> http://help.netscape.com/kb/corporate/19980217-17.html.

X-NETSCAPE is more than proxyauth, there's a way to retrieve a URL for
user self-administration from the server.  I don't have a spec on hand;
the extension is obsolete.

The following is the specification for XSERVERINFO:

------------------------------------------------

The CAPABILITY tag returned by this extension is "XSERVERINFO".
Servers which advertise the XSERVERINFO capability must support both
the XSERVERINFO and XMAILBOXINFO commands.

XSERVERINFO

Syntax:

serverinfo_cmd = "XSERVERINFO" 1*(SPACE atom)

serverinfo_data = "XSERVERINFO" 1*(SPACE atom SPACE nstring)

Description:

The XSERVERINFO command returns information about the IMAP server.
The client specifies in the arguments to the XSERVERINFO the names of
the information items it is requesting.  The server issues an untagged
XSERVERINFO response including the names and values of each of the
requested items before issuing a tagged OK response to XSERVERINFO
command.

If the client requests an information item that the server has no
knowledge of, the server MUST return a NIL value.

Currently-defined information items are:

	MANAGEACCOUNTURL	The URL for managing the user's account
	MANAGELISTSURL		The URL for managing mailing lists
	MANAGEFILTERSURL	The URL for managing filters for
				incoming mail

Example:

C: A001 XSERVERINFO MANAGEACCOUNTURL FOOBAR
S: * XSERVERINFO MANAGEACCOUNTURL "https://[email-masked]:3333/"
FOOBAR NIL
S: A001 OK Completed

XMAILBOXINFO

Syntax:

mailboxinfo_cmd = "XMAILBOXINFO" SPACE mailbox 1*(SPACE atom)

mailboxinfo_data = "XMAILBOXINFO" SPACE mailbox 1*(SPACE atom SPACE
nstring)

Description:

The XMAILBOXINFO command returns information about the specified IMAP
mailbox.  The client specifies in the arguments to the XMAILBOXINFO
the mailbox for which information is being requested and the names of
the information items it is requesting.  The mailbox issues an
untagged XMAILBOXINFO response including mailbox name and the names
and values of each of the requested items before issuing a tagged OK
response to XMAILBOXINFO command.

If the client requests an information item that either the server has
no knowledge of or which is not applicable to the mailbox, the server
MUST return a NIL value.

Currently-defined information items are:

	MANAGEURL		The URL for managing the mailbox
	POSTURL			The URL for posting to the mailbox
				"news:" and "mailto:" URLS are most
				appropriate, though a client must
				safely ignore unrecognized URL types.

Example:

C: A001 XMAILBOXINFO "INBOX" MANAGEURL POSTURL
S: * XMAILBOXINFO "INBOX" MANAGEURL
   "https://srvr.mcom.com:3333/user/userid/INBOX"
    POSTURL "mailto:[email-masked]"
S: A001 OK Completed

Date: Mon, 19 Mar 2001 10:56:31 -0600
From: Chris Newman <[email-masked]>
Subject: informal IMAPEXT discussion
To: [email-masked]
Sender: [email-masked]

We're going to have an informal IMAPEXT discussion during the afternoon 
session at the IETF today.  We'll be discussing the VPIM-related extensions 
since the VPIM people are around, as well as other issues the participants 
desire.

Meet by the IETF message board at 1 PM today.

		- Chris

From: "Neystadt, John" <[email-masked]>
To: "'Tony Hansen '" <[email-masked]>, "'Alexey Melnikov '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: X-NETSCAPE
Date: Mon, 19 Mar 2001 18:37:53 +0200
Sender: [email-masked]

I did not heard about xservinfo.

As to X-NETSCAPE (ProxyAuth) you can read at
http://help.netscape.com/kb/corporate/19980217-17.html.

I can't not found a detailed specification, alhough I've seen it once,
probbably within Netscape's manuals.

-----Original Message-----
From: Tony Hansen
To: Alexey Melnikov
Cc: Neystadt, John; [email-masked]; [email-masked]
Sent: 3/19/01 7:37 AM
Subject: Re: BOUNCE [email-masked]: Approval required:

Are X-NETSCAPE and XSERVINFO defined anywhere that's accessible?

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:
> 
> "Neystadt, John" wrote:
> 
> > Here is one observation:
> >
> > It seems to me, that almost every existing server supports
X-NETSCAPE.
> > Presumable for 'master-password' support. Actually this feature
makes indeed
> > a lot of sense for imap front-ends.
> >
> > May be we should standartise it (or similar approach), instead of
> > implementing un-official extention?
> 
> Netscape has implemented another extension XSERVINFO, that obsoletes
X-NETSCAPE.
> 
> XSERVINFO is kind of server level annotations.
> I said to John Myers that it is a good idea to make this extension
standard
> track document.
> 
> Alexey

Date: Mon, 19 Mar 2001 00:40:42 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: Conditional store (MODTIME) open issues
Sender: [email-masked]

Here is the list of Open Issues I have after San Diego IMAPEXT meeting
(in no particular order). Some comments are below items.

1). modtime: timestamp or sequence counter?

Why we should use timestamps: there is no correlation between sequence
counters for different flags,
modtime timestamps for two different Store operations are guarantied to
have different timestamps (sequence counters are not). A client will be
able to construct search criterion that covers multiple flags
(e.g. "all messages with either \Answered or $MDNSent modified after
XXX").

2). How specify different UNCHANGESINCE for different flags in the same
STORE?  Do we want such granularity anyway?

3). Untagged Modtime response that is used with FETCH/STORE to specify
that client has all data till modtime?
MODTIME Message Data Item in STATUS?

I would say yes.

4). Do we need per flag modtimes? Should they be persistent between IMAP
server restarts?

There are two ways how the proposed extension can be used by a client.
The first use for the client is to synchronize mailbox. This doesn't
require per flag modtimes, but requires that modtime is stored on server
and is preserved between server restarts (i.e. it must be stored in some
persistent storage, for example database).
The second use for the client is to perform atomic update operations on
a set of flags. This requires that server remembers modtime only while
it is running (modtimes should be regenerated on restart) and also per
flag modtimes.

5). Add support for SORT extension?

Alexey

Date: Sun, 18 Mar 2001 23:39:42 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Randall Gellens <[email-masked]>, [email-masked]
Subject: More ANNOTATE comments (was Re: Progress? Meeting?)
Sender: [email-masked]

>    /message/smtp-envelope
>        Defines the top-level of entries which together describe the
>        SMTP envelope used in delivery of the message.  There are no
>        attributes at this level.  The client SHOULD NOT modify the
>        /message/smtp-envelope entry or any sub-entries or any of their
>        attributes, except in messages which have the DRAFT flag set.

Randy, can you add /message/smtp-envelope/auth_sender for authenticated sender
(SMTP AUTH extension)?
This will replace Netscape XSENDER extension.

Alexey

Date: Mon, 19 Mar 2001 00:37:21 -0500
From: Tony Hansen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BOUNCE [email-masked]: Approval required:
Sender: [email-masked]

Are X-NETSCAPE and XSERVINFO defined anywhere that's accessible?

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:
> 
> "Neystadt, John" wrote:
> 
> > Here is one observation:
> >
> > It seems to me, that almost every existing server supports X-NETSCAPE.
> > Presumable for 'master-password' support. Actually this feature makes indeed
> > a lot of sense for imap front-ends.
> >
> > May be we should standartise it (or similar approach), instead of
> > implementing un-official extention?
> 
> Netscape has implemented another extension XSERVINFO, that obsoletes X-NETSCAPE.
> 
> XSERVINFO is kind of server level annotations.
> I said to John Myers that it is a good idea to make this extension standard
> track document.
> 
> Alexey

Date: Sun, 18 Mar 2001 21:09:58 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Neystadt, John" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: BOUNCE [email-masked]: Approval required:
Sender: [email-masked]

"Neystadt, John" wrote:

> Here is one observation:
>
> It seems to me, that almost every existing server supports X-NETSCAPE.
> Presumable for 'master-password' support. Actually this feature makes indeed
> a lot of sense for imap front-ends.
>
> May be we should standartise it (or similar approach), instead of
> implementing un-official extention?

Netscape has implemented another extension XSERVINFO, that obsoletes X-NETSCAPE.

XSERVINFO is kind of server level annotations.
I said to John Myers that it is a good idea to make this extension standard
track document.

Alexey

From: "Neystadt, John" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: BOUNCE [email-masked]: Approval required:
Date: Mon, 19 Mar 2001 04:17:06 +0200
Sender: [email-masked]

Here is one observation:

It seems to me, that almost every existing server supports X-NETSCAPE.
Presumable for 'master-password' support. Actually this feature makes indeed
a lot of sense for imap front-ends.

May be we should standartise it (or similar approach), instead of
implementing un-official extention?

John Neystadt
[email-masked]
http://www.neystadt.org/john/

> -----Original Message-----
> From: Ken Murchison [mailto:[email-masked]]
> Sent: Fri, March 16, 2001 10:24 PM
> To: Chris Newman
> Cc: [email-masked]
> Subject: Re: BOUNCE [email-masked]: Approval required:
> 
> 
> Chris,
> 
> Speaking on behalf of CMU (per Larry's request)
> 
> > >Please send in corrections/additions (preferably in same 
> format) and I'll
> > >post a revised version in a few days.
> > >
> > >               - Chris
> > >
> > >-----
> > >
> > >Standard IMAP Extensions
> > >          IMAP4 4rev1 ACL QUOTA lit+ nspace uid+ tls ID 
> mboxref logindisable
> > >CMU Cyrus  X     X    X    X     X     X     X   X   X    X
> 
> 
> Should be:
> 
>           IMAP4 4rev1 ACL QUOTA lit+ nspace uid+ tls ID 
> mboxref logindisable IDLE
> CMU Cyrus  X     X    X    X     X     X     X   X   X    X 
> (1)     X         X (2)
> 
> 
> (1) only available with Cyrus Murder (IMAP proxy)
> (2) compile-time option (disabled for the test)
> 
> 
> > >POP Capabilities (Lotus - no server)
> > >           TOP PIPELINING UIDL SASL USER EXPIRE RESP-CODES 
> implem STLS
> > >CMU Cyrus  X      X       X    X    X     X                  X    X
> 
> Should be:
> 
>            TOP PIPELINING UIDL SASL USER EXPIRE RESP-CODES implem STLS
> CMU Cyrus   X      X       X    X    X     X        X (3)     X    X
> 
> (3) supported, but wasn't being advertised (fixed in CVS)
> 
> 
> > >IMAP/POP SASL
> > >            P/CRAM I/CRAM digest P/PLAIN I/PLAIN APOP kerb4 GSSAPI
> > >CMU Cyrus    X        X     X                         X     X
> 
> Should be:
> 
>             P/CRAM I/CRAM digest P/PLAIN I/PLAIN APOP kerb4 GSSAPI
> CMU Cyrus    X        X     X       X (4)  X (4)        X     X
> 
> (4) config option (disabled for the test)
> 
> 
> > >Non-Standard IMAP Extensions
> > >          XSENDER X-NETSCAPE
> > >iPlanet     X         X
> > >Novell      X         X
> 
> Add:
> 
>           XSENDER X-NETSCAPE
> CMU Cyrus             X (5)
> 
> (5) compile-time option (disabled for the test)
> 
> 
> Thanks,
> Ken
> -- 
> Kenneth Murchison     Oceana Matrix Ltd.
> Software Engineer     21 Princeton Place
> 716-662-8973 x26      Orchard Park, NY 14127
> --PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
> 

From: "Neystadt, John" <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: IETF-50
Date: Mon, 19 Mar 2001 00:54:41 +0200
Sender: [email-masked]

Since there is no IMAP meeting at this IETF, I though that it may be nice
for those who attend IETF to have a chance met first time face to face (for
those who still have not, like me :))

May be we can do it tomorrow, towards end of the breakfast, say at 8:50am,
near in Ballroom near Saloon E entrance?

John Neystadt

Date: Thu, 15 Mar 2001 01:26:40 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Chris Newman <[email-masked]>
cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Critical Content -- Header or Parameter
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 14 Mar 2001, Chris Newman wrote:
> If I could go back in history and redo things, I'd replace BODYSTRUCTURE
> with a headers/headers-not facility that fetches the skeleton of the MIME
> message minus the body parts themselves.  Any client which does offline or
> local file work has to have an 822/MIME header parser anyway, so why force
> clients to implement two syntaxes for the same data?

Not all clients do offline or local file work.  There are IMAP-only
clients in existance which do not have a clue about how to parse 822 or
MIME.

Unlike 822 or MIME, ENVELOPE and BODYSTRUCTURE actually have a dependable
and structured syntax, that is not subject to the whims of what some email
composer considers esthetically pleasing.  BODYSTRUCTURE also contains
information which is not to be found in the MIME headers.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Wed, 14 Mar 2001 17:02:01 -0800
From: Chris Newman <[email-masked]>
Subject: Re: Critical Content -- Header or Parameter
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

--On Wednesday, March 14, 2001 11:31 -0500 Eric Burger 
<[email-masked]> wrote:
> OK, here's another choice (thanks to Mark Crispin):  How about making the
> critical content notation a parameter to Content-Type?

Poor choice.  The scope of Content-Type parameters is intended to be 
specific to the content type.  Thus a "foo" parameter on application/bar 
can have a different meaning from a "foo" parameter on application/baz.

If you want to add a parameter to an existing header, add it to 
Content-Disposition which has parameters which are _not_ specific to the 
disposition value and is already in the IMAP BODYSTRUCTURE.  The "filename" 
parameter on Content-Disposition is a perfect example of this sort of thing.

Futher, the concept of "criticality" fits much better as an aspect of the 
"disposition" of the body part rather than a modifier to the "type" of a 
body part.

If I could go back in history and redo things, I'd replace BODYSTRUCTURE 
with a headers/headers-not facility that fetches the skeleton of the MIME 
message minus the body parts themselves.  Any client which does offline or 
local file work has to have an 822/MIME header parser anyway, so why force 
clients to implement two syntaxes for the same data?

		- Chris

Date: Wed, 14 Mar 2001 18:35:57 -0500
From: Dave Aronson <[email-masked]>
Organization: Air 'n Sun free Fidonet BBS, (703) 319-0714
To: [email-masked]
Subject: Re: [VPIM] Critical Content -- Header or Parameter
Sender: [email-masked]

"Eric Burger" <[email-masked]> wrote:

>  We rejected making critical content a parameter to Content-Disposition,
>  since people felt that would bend the semantics of Content-Disposition
>  a bit too much.

And it bends those of Content-TYPE *less*?  Methinks I missed this
discussion; there seems to be nothing  relevant in the past several months
of VPIM WG mailing list archive.  (Found the archives, thanks, Glenn!)  If
you mean in the draft itself, I don't see much logic there beyond that it
"overloads the meaning of the entity".  I'll admit I'm not intimately
familiar with the original intent of that entity, but it seems to me that
criticality is indeed an instruction on disposition.  One obvious case is
that if something with criticality of CRITICAL can't be rendered, DISPOSE of
the message.  B-)  Sorry if I'm beating a dead horse, but it was dead when I
got here, honest, officer!

>  The argument for making critical content a parameter to Content-Type
>  is that all IMAP servers return Content-Type parameters in the
>  BODY/BODYSTRUCTURE methods.  They would not have to implement a
>  BODYSTRUCTURE extension to return Critical-Content.

"Because it was there" may have worked for Hillary (Sir Edmund or Clinton,
take yer pick), but I don't think that's quite the sort of deep technical
analysis usually expected of the IETF.  B-)

>  The argument against making critical content a parameter to Content-Type
>  is that it goes directly against two paragraphs in RFC 2045:
>
>     There are NO globally-meaningful parameters that apply to all media
>     types.  Truly global mechanisms are best addressed, in the MIME
>     model, by the definition of additional Content-* header fields.
>
>  a CRITICALITY parameter is a globally-meaningful parameter.

I'm not sure I quite grok what you mean here.  It's not
"globally-meaningful" in the sense of applying to the entire message; it is
only for one piece.  (Sounds like it's probably got some locally-specific
meaning explained in the RFC; I'll go check it later, as I'm writing this
offline.)  However, the other argument against it:

>  A Content-Type parameter is supposed to be for
>  modifiers to the Content-Type only:

is what knocks it out for me.  The criticality has no relation to what type
of thing is actually inside -- especially since there could be parts of the
exact same type and different criticality, such as Voice-Message versus
Spoken-Receipient.  (Sure, you care if the message itself gets through, but
do you really want to communicate with anyone who has to be reminded who he
is?  B->)  Therefore, at least IMHO, it should not be in Content-Type.

>  Do we really care?

Enough to argue about it -- but that doesn't say much!  B-)

>  I'd like to hear from IMAP server vendors.

Well, seeing as I'm currently Between Positions (see sig) and might possibly
get hired by an IMAP server vendor....

(NOTE: This is a resend to the imapext mailing list, to which I do not
subscribe; I am sending it because what I was replying to was also sent
here.  Please include either me or the VPIM mailing list
([email-masked]) in any replies.  Thank you.)

-- 
Dave Aronson, Sysop of AirNSun free public Fidonet BBS @ +1-703-319-0714
The above opinions are MINE, ALL MINE, but for rent at reasonable rates.
I'VE BEEN LAID OFF AGAIN; see http://djajobhunt2001.tripod.com for info.

Date: Wed, 14 Mar 2001 10:26:44 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Critical Content -- Header or Parameter
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, 14 Mar 2001 11:31:47 -0500, Eric Burger wrote:
> I'd like to hear from IMAP server vendors.

As an "IMAP server vendor", here's my public statement on what I already told
Eric in private:

It doesn't matter much to me whether there is a Content-Criticality header, or
a CRITIALITY parameter to Content-Type.  I always believed that there should
only have been one MIME header, and use parameters for everything else.  But
that horse is long out of the barn.

I am concerned, given the stalling against having Content-Location appear in
the IMAP BODYSTRUCTURE, that there is probably little chance of ever having
Content-Criticality in there.  So, as a purely practical matter, I recommend
the CRITICALITY parameter as something that you won't have to fight to see
happen.

Reply-To: <[email-masked]>
From: "Eric Burger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Critical Content -- Header or Parameter
Date: Wed, 14 Mar 2001 11:31:47 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01C0AC7A.5AAC4200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

OK, here's another choice (thanks to Mark Crispin):  How about making the
critical content notation a parameter to Content-Type?

We rejected making critical content a parameter to Content-Disposition,
since people felt that would bend the semantics of Content-Disposition a bit
too much.

The argument for making critical content a parameter to Content-Type is that
all IMAP servers return Content-Type parameters in the BODY/BODYSTRUCTURE
methods.  They would not have to implement a BODYSTRUCTURE extension to
return Critical-Content.

That is, instead of
	Content-Type: TEXT/PLAIN;CHARSET=US-ASCII
	Content-Criticality: IGNORE
we would use something like
	Content-Type: TEXT/PLAIN;CHARSET=US-ASCII;CRITICALITY=IGNORE

The argument against making critical content a parameter to Content-Type is
that it goes directly against two paragraphs in RFC 2045:

   There are NO globally-meaningful parameters that apply to all media
   types.  Truly global mechanisms are best addressed, in the MIME
   model, by the definition of additional Content-* header fields.

a CRITICALITY parameter is a globally-meaningful parameter.  A Content-Type
parameter is supposed to be for modifiers to the Content-Type only:

   Parameters are modifiers of the media subtype, and as such do not
   fundamentally affect the nature of the content.  The set of
   meaningful parameters depends on the media type and subtype.  Most
   parameters are associated with a single specific subtype.  However, a
   given top-level media type may define parameters which are applicable
   to any subtype of that type.

Do we really care?  I'd like to hear from IMAP server vendors.

Thoughts?

[If you're wondering what this is about, see
http://www.ietf.org/internet-drafts/draft-ietf-vpim-cc-03.txt ]

------=_NextPart_000_0035_01C0AC7A.5AAC4200
Content-Type: text/x-vcard;
	name="Eric Burger.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Eric Burger.vcf"

BEGIN:VCARD
VERSION:2.1
N:Burger;Eric
FN:Eric Burger
ORG:SnowShore Networks, Inc.
TITLE:Chief Technology Officer
TEL;WORK;VOICE:+1 (978) 367-8403
TEL;CELL;VOICE:+1 (703) 304-3883
TEL;WORK;FAX:+1 (978) 367-8499
ADR;WORK:;;285 Billerica Rd.;Chelmsford;MA;01824-4120;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:285 Billerica =
Rd.=3D0D=3D0AChelmsford, MA 01824-4120=3D0D=3D0AUnited States of =
Ameri=3D
ca
URL;WORK:http://www.snowshore.com
EMAIL;PREF;INTERNET:[email-masked]
REV:20010312T171942Z
END:VCARD

------=_NextPart_000_0035_01C0AC7A.5AAC4200--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-01.txt
Date: Mon, 05 Mar 2001 06:45:01 -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		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-01.txt
	Pages		: 19
	Date		: 02-Mar-01
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

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

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-annotate-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-annotate-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-annotate-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-annotate-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, 02 Mar 2001 12:03:42 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Randall Gellens <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Progress? Meeting?
Sender: [email-masked]

Randall Gellens wrote:

> At 12:15 PM -0800 2/20/01, Randall Gellens wrote:
>
> >  I'm trying to get an updated Annotations draft done shortly.
>
> I just sent it in.  Until it appears in the Internet Drafts
> directories, you can get it from
> <ftp://ftp.pensive.org/Public/Randy/annotate-02.txt>
>

Few comments:

>7 Private versus Shared
[skipped]

>        <<<OPEN-ISSUE>>>
>
>    This is dangerous since it allows a client to store an entry without
>    knowing if other users are able to view it.
>
>    How a client learns or changes the default is an open issue.  One
>    suggestion is to use an additional ACL bit to indicate the current
>    default state.
>
>    It may be better to remove the default, and force clients to always
>    explicitly store into one or the other.

I don't like default state. I would prefer that as well.

>8.2 ANNOTATION Message Data Item in FETCH Response
>
>    The ANNOTATION message data item in the FETCH response displays
>    information about annotations in a message.
>
>    ANNOTATION parenthesised list

------------------------^ parenthesized

>        The response consists of a list of entries, each of which has a
>        list of attribute-value pairs.
>
>    Examples:
>        C: a FETCH 1 (ANNOTATION ("/message/comment" "value"))
>        S: * 1 FETCH (ANNOTATION ("/message/comment"
>                                   ("value.priv" "My comment"
>                                    "value.shared" NIL)))
>        S: a OK Fetch complete

I would prefer if a server can omit values that it doesn't store currently
(i.e. server is allowed to send the following response:

        S: * 1 FETCH (ANNOTATION ("/message/comment"
                                    ("value.priv" "My comment")))

>8.7 ACL Rights
>
>    The "r" right, as specified in [ACL-EXT], is required to use
>    annotations in any command other than STORE.
>
>    The "w" right is needed to use shared annotations in the STORE
>    command.

These two seems Ok.

>    The "s" right is needed to use private annotations in the STORE
>    command.

I disagree. "s" right is used for \Seen flag, private annotations have
nothing to do with \Seen flag. There is no guaranty that \Seen flag is
private for the user. I would rather add a new right for that particular
purpose.

Alexey

Date: Mon, 26 Mar 2001 18:06:47 -0800
To: Alexey Melnikov <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
Sender: [email-masked]

At 11:39 PM -0700 3/18/01, Alexey Melnikov wrote:

>   >    /message/smtp-envelope
>>         Defines the top-level of entries which together describe the
>>         SMTP envelope used in delivery of the message.  There are no
>>         attributes at this level.  The client SHOULD NOT modify the
>>         /message/smtp-envelope entry or any sub-entries or any of their
>>         attributes, except in messages which have the DRAFT flag set.
>
>  Randy, can you add /message/smtp-envelope/auth_sender for 
> authenticated sender
>  (SMTP AUTH extension)?
>  This will replace Netscape XSENDER extension.

Seems like a good idea.

Date: Mon, 26 Mar 2001 15:58:01 -0800
From: Chris Newman <[email-masked]>
Subject: RE: X-NETSCAPE
To: "Neystadt, John" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

X-Mailer: Mulberry/2.1.0a2 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--On Monday, March 19, 2001 20:44 +0200 "Neystadt, John" 
<[email-masked]> wrote:
> My original suggestion was about proxyauth. Did you picked up Alexey's
> glove to write a draft on that? I beleive that it is a very important
> feature that anyhow supported by many servers and we will benefit from
> moving it towards a standard. If you don't up to it, may be somebody else
> (myself?) will do it?

The PLAIN mechanism in RFC 2595 supports proxy auth, as does the DIGEST-MD5 
mechanism in RFC 2831.  If you want the feature, encourage people to 
implement these specs.

		- Chris

Date: Fri, 23 Mar 2001 13:59:36 -0600
From: Chris Newman <[email-masked]>
Subject: Re: informal IMAPEXT discussion
To: "Alan K. Stebbens" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Monday, March 19, 2001 21:30 -0600 "Alan K. Stebbens" 
<[email-masked]> wrote:
> Chris, can you or someone post a summary of this informal discussion?

I was busy participating so I didn't take a lot of notes.  If someone else 
has better notes, please post them.  But here's what I have:

----
Discussed binary extension.  Decided there is a need for sizes of binary 
objects, will try BINARYSIZE approach.

Discussed ACL draft and worked through open issues.  Current ACL RFC is 
widely implemented and interoperates, but has some deficiencies: missing 
"x" right for deleting mailboxes, too vague about semantics, no way to map 
genernal names to authorization identifiers.  Need to include advisory URL 
to describe how to look up users and groups without getting IMAP into 
directory service area (I volunteered to write first draft of text 
describing what the URL means).  John will talk to Mark about some other 
issues, but it may be necessary to have two different ACL extensions in 
order to make a good UI practical.

Discussed SORT/THREAD/VIEW.  Some believe that "lightweight" clients won't 
use threading due to complexity, so windowing thread may not be worth the 
trouble.  There are three common thread algorithms with about 33% mindshare 
in user community for each.  SORT+ORDEREDSUBJECT is one, THREAD extension 
has another, and third isn't documented yet.  Some believe that windowing 
removes most need for dynamic updates (at least with sort) since re-issuing 
the sort doesn't consume as much bandwidth.  Some discussion of WINDOWing 
for SORT/THREAD.  One question why we can't have a select-based mechanism 
which replaces seqno with view position.  Cyrus and I will work through a 
different approach to WINDOWing that should be simpler than the previous 
VIEW proposal and is layered on SORT/THREAD base spec.

Deferred discussion of CHANNEL since voice mail folks weren't present.

		- Chris

Date: Thu, 22 Mar 2001 19:42:15 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: outline of what to do with ACL
Organization: Networks & Distributed Computing
Sender: [email-masked]

Here's a basic outline of what I'd like to do with ACLPLUS.  It's not in
a formal I-D, but I'd like to hear comments.  Due to all the stuff in this
proposal, I imagine that a lot of clarifications/fine-tuning will be
needed.

Goals:	functional upwards compatibility with RFC 2086.  Add missing
	functionality and desirable extensions (e.g. wildcards).  Interact
	with extended LIST work.  Be able to represent (but not require)
	filesystem style access controls as well as existing ACL access
	controls.  Don't require semantics that are unimplementable on
	some platforms (= allow server to say NO and/or don't have side
	effects that make something unusable).
Non-goal: strict compatibility with RFC 2086

The general idea is that it should be possible to have a server that
supports both ACL and ACLPLUS, although such a server won't be able to use
all of ACLPLUS.

ACLPLUS identifiers:

syntax:
	["$"] astring

RFC 2086 style "negative rights" are eliminated, along with inherience.

An identifier that does not begin with "$" is a login user name, as in
RFC 2086.

Definable identifiers.  Server implementations are *NOT* required to
use any of these, but if they do, these are their semantics.  Note
that definable identifiers may expand to other definable identifiers.

$G$xxx	global identifier xxx.  Valid everywhere
$U$xxx	per-user identifier xxx.  Valid only for the logged-in user
$M$xxx	per-mailbox identifer xxx.  Valid only for this mailbox
$xxxxx	reserved for future definition

Non-definable identifiers.  Server implementations SHOULD support $WORLD,
and MUST support anyone and user names.  However, a server can respond with
a NO.

$WORLD		all authorized users but not anonymous
$ANONYMOUS	anonymous users
$DISABLE	disabled rights (see below)

There is no inheritance of rights, not even from $WORLD.  This means
that RFC 2086 negative rights aren't needed.

If the user name is listed, those rights are used; otherwise, the
first applicable identifier in the ACL defines the (only) rights that
the user gets.  For example, given
	Joe= $G$hackers=rwipslda $ALL=rw
Joe has no access to the mailbox, even though he's a member of the
global "hackers" group (and $ALL).

The $DISABLE identifier is special.  This identifier disables the
listed rights for all other identifiers.  For example:
	Joe=rwipslda $ALL=rw $DISABLE=rwipslda
denies all access to all users, including Joe.  A sample use of
$DISABLE is to deny access temporarily (e.g. while some system
administration task is going on); this is basically what RFC 2086
negative rights were intended to do.

ACL rights:

These try to be as compatible with RFC 2086 as possible.

l	list
r	read
s	permanent seen status
w	write (permanent flags other than \Seen and \Deleted)
i	insert [APPEND, COPY to mailbox]
p	post to mailbox
c	create inferior mailboxes
d	permanent delete status
a	administer (ACL operations permitted)
x	delete mailbox (new, not in RFC 2086)
e	expunge mailbox (new, not in RFC 2086)

ACLPLUS Operations:

These commands are completely different from RFC 2086.  Compatibility
operations are below.

Wildcards permitted for mailbox in all commands.

ACL SET mailbox 1*(identifier rights)
	set the ACL, replacing existing ACL

ACL MODIFY mailbox 1*(identifier rights)
	modify the identifier/rights, leaving others unchanged

ACL REMOVE mailbox *identifier
	remove all rights for the specified identifiers

ACL TEST mailbox identifier rights
	test mailbox to see if the identifier has the given rights

ACL DEFINE mailbox 1*(identifier definition)
	define an identifier.  Mailbox may be empty for global identifiers

ACL EXPAND mailbox 1*identifier
	return definitions for the specified identifers

ACL EXPAND returns the following new untagged value:

* DEFINEID mailbox 1*(identifier definition)

Extended LIST command.  Note that the exact syntax depends upon how the
extended LIST word goes; this is just for illustration purposes.

LIST reference name "(" 1*("ACL" / "RIGHTS" / "MYRIGHTS") ")"

Extended LIST returns extended forms of the LIST response, using
attributes.  We can use of colon, underscore, and equals as delimiters
in the obvious places.  Here's how the RFC 2086 examples would look in
the new style:
	* ACL INBOX Fred rwipslda Joe rw
=>	* LIST (\NoInferiors \ACL:Fred=rwipslda:Joe=rw) NIL INBOX
	* LISTRIGHTS ~/Mail/saved smith la r swicd
=>	* LIST (\NoInferiors \RIGHTS:smith=la_r_swicd) NIL INBOX
	* MYRIGHTS INBOX
=>	* LIST (\NoInferiors \MYRIGHTS:rwipslda) NIL INBOX

Note that all IMAP4rev1 compliant implementations support this now as part
of the flag-extension rule.

We can also add "CHILD" and "REFERRALS" to the extended LIST command
if the associated capability is there.

RFC 2086 compatibility operations:

This is only if you advertise both the ACLPLUS and ACL rights.

No "x" or "e" rights.  OK to ignore this problem with RFC 2086, but
not with Myers' new draft.

Here are the equivalents to RFC 2086 commands, but these equivalents return
the new extended LIST form.  If you want the RFC 2086 responses, you must use
RFC 2086 commands.

SETACL mailbox identifer rights
	=> ACL MODIFY mailbox identifier rights

DELETEACL mailbox identifier
	=> ACL REMOVE mailbox identifier

GETACL mailbox
	=> LIST "" mailbox (\ACL)

LISTRIGHTS mailbox identifier
	=> LIST "" mailbox (\RIGHTS)

MYRIGHTS mailbox
	=> LIST "" mailbox (\MYRIGHTS)

Unix filesystem implementation specifics

Three or four possible identifiers on a mailbox.  Owner is $M$owner,
group is $M$group, other user is $WORLD.  It may also implement
$ANONYMOUS.  It will answer NO to an attempt to create any other
identifier.

$M$owner is defined as one or more users (no "$" in name).

$M$group is defined as $G$xxx where xxx is a UNIX group name.

Don't use $U$xxx or $DISABLE at all.

ACL rights for flat-file formats (all except mh and mx)

l	(mailbox only) 4 bit in containing directory
r	(mailbox only) 1 bit in containing directory, 4 bit in file
wisde	(mailbox only) 1 bit in containing directory, 2 bit in file
p	?? what to do about this ??
c	(directory only) 2 bit in containing directory
x	2 bit in containing directory, if sticky bit set then owner
a	user is owner or Administrator

ACL rights for one-message/one-file formats (mh and mx)

l	4 bit in containing directory
r	1 bit in containing directory, 4 bit
wisde	1 bit in containing directory, 2 bit
c	2 bit in containing directory
x	2 bit in containing directory, if sticky bit set then owner
p	?? what to do about this ??
a	user is owner or Administrator

ACL rights for news

l	4 bit in containing directory
r	1 bit in containing directory, 4 bit
d	always set
wiseacx	never set
p	?? what to do about this ??

Example:
	* LIST (\NoInferiors \ACL:$OWNER=lrswipcdxa:$WORLD=p) NIL INBOX
	* LIST (\ACL:$OWNER=lrswipcdxa:$GROUP=lrswipd:$WORLD=lrp) "/" sharedmbx
	* DEFINEID INBOX $OWNER (mary)
	* DEFINEID pine-bugs $GROUP $G$pineteam
	* DEFINEID "" $G$pineteam mikes hubert mrc jpf

Classes of users.  * identifies things that require external privileged program

Ordinary users:
 . permitted to change mode of their own mailbox
 . permitted to change group of their own mailbox
 * permitted to create and manage a personal group

Power users (members of group imappower):
 ordinary user, plus:
 * permitted to change owner of their own mailbox
 * permitted to create public groups
 * may manage any group in which he's the first member

Administrators (members of group mailadm):
 power user, plus:
 * permitted to change mode of any mailbox
 * permitted to change owner of any mailbox
 * permitted to change group of any mailbox
 * permitted to create and manage any group

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Thu, 22 Mar 2001 09:21:00 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Eric Burger <[email-masked]>
cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Last, last, last visit to Critical-Content / Content-Disposition
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 22 Mar 2001, Eric Burger wrote:
> Given the realities of BODYSTRUCTURE, and the fact that we are NOT bending
> Content-Disposition too far, the consensus is to use a CRITICALITY parameter
> to Content-Disposition, rather than a new MIME entity, for criticality
> marking.

Sounds good to me.  I'll sign off on that.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Reply-To: <[email-masked]>
From: "Eric Burger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Last, last, last visit to Critical-Content / Content-Disposition
Date: Thu, 22 Mar 2001 11:45:34 -0500
Importance: Normal
Sender: [email-masked]

At the VPIM lunch BOF, I reviewed why we said "no" to putting
Critical-Content as a parameter to Content-Disposition.

Going back to the deep, dark past, the original proposal was to do the
following:

     Content-Disposition: attachment; content-notification=true

This was shot down because per-part notification control and part type
labeling did not belong as a "disposition".  This scenario came about in the
evolution of partial-non-delivery notification (PNDN) to the critical
content concept.

Looking over the archives and some private correspondence, it is clear that
content-notification, as a part of PNDN, is an inappropriate use of
Content-Disposition.  However, it is also clear that criticality IS an
appropriate use of Content-Disposition.

Given the realities of BODYSTRUCTURE, and the fact that we are NOT bending
Content-Disposition too far, the consensus is to use a CRITICALITY parameter
to Content-Disposition, rather than a new MIME entity, for criticality
marking.

The -03 way of marking:

   Critical part:
       --Next part
       Content-Type: ...
       Content-Disposition: attachment; file=foo.bar
       Content-Criticality: CRITICAL
       ...

   Not important part:
       --Next part
       Content-Type: ...
       Content-Disposition: attachment; file=foo.bar
       Content-Criticality: IGNORE
       ...

The -04 (future) way of marking:
   Critical part:
       --Next part
       Content-Type: ...
       Content-Disposition: attachment; file=foo.bar; criticality=CRITICAL
       ...

   Not important part:
       --Next part
       Content-Type: ...
       Content-Disposition: attachment; file=foo.bar; criticality=IGNORE
       ...

Speak now...

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: IMAP CHANNEL discussion list
Organization: ACI Worldwide
Date: Wed, 21 Mar 2001 13:18:44 -0700
Sender: [email-masked]

At the VPIM lunch BOF today we decided that, since both the IMAP
and the VPIM communities have interest in this extension, we will
use the [email-masked] mailing list for further discussions.
This eliminates the need for VPIM folks to subscribe to the IMAP
lists, and vice versa. To subscribe:

	echo subscribe | mail [email-masked]

--lyndon

From: Lyndon Nerenberg <[email-masked]>
Organization: ACI / Messagingdirect
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: BINARY grammar 
Date: Tue, 20 Mar 2001 13:28:34 -0700
Sender: [email-masked]

> I'm not clear on how your proposed change would prevent NUL from being
> sent to unsuspecting clients.

Thanks, I knew I had missing something *blatently* obvious :-(

--lyndon

Date: Tue, 20 Mar 2001 12:21:35 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: <[email-masked]>
Subject: Re: BINARY grammar
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 20 Mar 2001, Lyndon Nerenberg wrote:
> Having re-read the grammar in 2060 I'm wondering if it would be
> better to change the definition of <string> to include <literal8>
> instead of special casing FETCH and APPEND.

literal8 is a misnomer since existing literals are 8bit.  It should be
something like literalb or binary_literal to reflect the inclusion of NUL.

I'm not clear on how your proposed change would prevent NUL from being
sent to unsuspecting clients.

It almost seems easier to remove the NUL restriction from CHAR and CHAR8,
and add a NUL restriction to TEXT_CHAR, all in the base spec.  But that
might break software that depends upon the NUL restirction.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: BINARY grammar
Organization: ACI / MessagingDirect
Date: Tue, 20 Mar 2001 13:06:40 -0700
Sender: [email-masked]

Currently I define a new protocol element <literal8> for 8bit data
with NULs. FETCH BINARY is explicitly defined to return <literal8>,
and APPEND is extended to accept <literal8> in addition to <literal>.

Having re-read the grammar in 2060 I'm wondering if it would be
better to change the definition of <string> to include <literal8>
instead of special casing FETCH and APPEND. This change would
simplify the BINARY specification, and simplifies the resulting
parser changes. I'm just worried that making this change to <string>
might break something. (Although nothing bad is immediately obvious
as I look at 2060.)

--lyndon

Date: Tue, 20 Mar 2001 11:49:46 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Lyndon Nerenberg <[email-masked]>, <[email-masked]>
Subject: Re: BINARY command syntax
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 20 Mar 2001, Alexey Melnikov wrote:
> I like BINARY.SIZE, but it is one character longer :-).

Me too.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Tue, 20 Mar 2001 12:08:00 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lyndon Nerenberg <[email-masked]>
CC: [email-masked]
Subject: Re: BINARY command syntax
Sender: [email-masked]

Lyndon Nerenberg wrote:

> Do people have a
> preference for "FETCH BINARYSIZE" vs. "FETCH BINARY.SIZE" ?

I like BINARY.SIZE, but it is one character longer :-).

Alexey

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: BINARY command syntax
Organization: ACI / MessagingDirect
Date: Tue, 20 Mar 2001 11:44:16 -0700
Sender: [email-masked]

At the IMAP BOF yesterday we agreed to kill BINARYSTRUCTURE and
add a FETCH item to obtain the decoded size. Do people have a
preference for "FETCH BINARYSIZE" vs. "FETCH BINARY.SIZE" ?
(FETCH BINARY and FETCH BINARY.PEEK remain as is.)

--lyndon

Date: Mon, 19 Mar 2001 22:58:08 -0800
From: John Gardiner Myers <[email-masked]>
Subject: Re: X-NETSCAPE
To: "Jim O'Connor" <[email-masked]>
Cc: Mike Macgirvin <[email-masked]>, Neystadt John <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms68B20B98EF8A88F53EA90A63
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim O'Connor wrote:
> 
> I have some questions about your reply.  We currently have several customers using > Netscape Messaging servers. We find proxyauth very useful and use it for a number of > specialized applications:

The proxyauth command is made obsolete by the proxy authentication
(separate authorization id) feature of SASL (RFC 2222).
--------------ms68B20B98EF8A88F53EA90A63
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

--------------ms68B20B98EF8A88F53EA90A63--

Date: Mon, 19 Mar 2001 21:30:02 -0600
From: "Alan K. Stebbens" <[email-masked]>
Reply-To: "Alan K. Stebbens" <[email-masked]>
Organization: Openwave Systems, Inc.
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Re: informal IMAPEXT discussion
Sender: [email-masked]

Hello Chris,

Monday, March 19, 2001, 10:56:31 AM, you wrote:

CN> We're going to have an informal IMAPEXT discussion during the afternoon 
CN> session at the IETF today.  We'll be discussing the VPIM-related extensions 
CN> since the VPIM people are around, as well as other issues the participants 
CN> desire.

CN> Meet by the IETF message board at 1 PM today.

Chris, can you or someone post a summary of this informal discussion?

Thanks.

-- 
Best regards,
 Alan K. Stebbens <[email-masked]>
 Sr. Technical Product Manager
 End-to-End Architecture & Application Standards
 Openwave Systems, Inc.
 Voice: +1.805.886.8886  Fax: +1.818.464.6943

If all you have is a hammer, then everything looks like a nail!

Date: Mon, 19 Mar 2001 20:48:18 -0600
From: "Alan K. Stebbens" <[email-masked]>
Reply-To: "Alan K. Stebbens" <[email-masked]>
Organization: Openwave Systems, Inc.
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Re: informal IMAPEXT discussion
Sender: [email-masked]

Hello Chris,

Monday, March 19, 2001, 10:56:31 AM, you wrote:

CN> We're going to have an informal IMAPEXT discussion during the afternoon 
CN> session at the IETF today.  We'll be discussing the VPIM-related extensions 
CN> since the VPIM people are around, as well as other issues the participants 
CN> desire.

CN> Meet by the IETF message board at 1 PM today.

Chris, can you or someone post a summary of this informal discussion?

Thanks.

-- 
Best regards,
 Alan K. Stebbens <[email-masked]>
 Sr. Technical Product Manager
 End-to-End Architecture & Application Standards
 Openwave Systems, Inc.
 Voice: +1.805.886.8886  Fax: +1.818.464.6943

If all you have is a hammer, then everything looks like a nail!

Date: Mon, 19 Mar 2001 14:27:34 -0800
From: John Gardiner Myers <[email-masked]>
Subject: Re: X-NETSCAPE
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms0ED5AD9B8625A941DBAED15F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(resending)

"Neystadt, John" wrote:
> As to X-NETSCAPE (ProxyAuth) you can read at
> http://help.netscape.com/kb/corporate/19980217-17.html.

X-NETSCAPE is more than proxyauth, there's a way to retrieve a URL for
user self-administration from the server.  I don't have a spec on hand;
the extension is obsolete.

The following is the specification for XSERVERINFO:

------------------------------------------------

The CAPABILITY tag returned by this extension is "XSERVERINFO".
Servers which advertise the XSERVERINFO capability must support both
the XSERVERINFO and XMAILBOXINFO commands.

XSERVERINFO

Syntax:

serverinfo_cmd = "XSERVERINFO" 1*(SPACE atom)

serverinfo_data = "XSERVERINFO" 1*(SPACE atom SPACE nstring)

Description:

The XSERVERINFO command returns information about the IMAP server.
The client specifies in the arguments to the XSERVERINFO the names of
the information items it is requesting.  The server issues an untagged
XSERVERINFO response including the names and values of each of the
requested items before issuing a tagged OK response to XSERVERINFO
command.

If the client requests an information item that the server has no
knowledge of, the server MUST return a NIL value.

Currently-defined information items are:

        MANAGEACCOUNTURL        The URL for managing the user's account
        MANAGELISTSURL          The URL for managing mailing lists
        MANAGEFILTERSURL        The URL for managing filters for
                                incoming mail

Example:

C: A001 XSERVERINFO MANAGEACCOUNTURL FOOBAR
S: * XSERVERINFO MANAGEACCOUNTURL "https://[email-masked]:3333/"
FOOBAR NIL
S: A001 OK Completed

XMAILBOXINFO

Syntax:

mailboxinfo_cmd = "XMAILBOXINFO" SPACE mailbox 1*(SPACE atom)

mailboxinfo_data = "XMAILBOXINFO" SPACE mailbox 1*(SPACE atom SPACE
nstring)

Description:

The XMAILBOXINFO command returns information about the specified IMAP
mailbox.  The client specifies in the arguments to the XMAILBOXINFO
the mailbox for which information is being requested and the names of
the information items it is requesting.  The mailbox issues an
untagged XMAILBOXINFO response including mailbox name and the names
and values of each of the requested items before issuing a tagged OK
response to XMAILBOXINFO command.

If the client requests an information item that either the server has
no knowledge of or which is not applicable to the mailbox, the server
MUST return a NIL value.

Currently-defined information items are:

        MANAGEURL               The URL for managing the mailbox
        POSTURL                 The URL for posting to the mailbox
                                "news:" and "mailto:" URLS are most
                                appropriate, though a client must
                                safely ignore unrecognized URL types.

Example:

C: A001 XMAILBOXINFO "INBOX" MANAGEURL POSTURL
S: * XMAILBOXINFO "INBOX" MANAGEURL
   "https://srvr.mcom.com:3333/user/userid/INBOX"
    POSTURL "mailto:[email-masked]"
S: A001 OK Completed
--------------ms0ED5AD9B8625A941DBAED15F
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

--------------ms0ED5AD9B8625A941DBAED15F--

From: "Neystadt, John" <[email-masked]>
To: "'John Gardiner Myers '" <[email-masked]>
Cc: "[email-masked] ' '" <[email-masked]>, "[email-masked]' '" <[email-masked]>
Subject: RE: X-NETSCAPE
Date: Mon, 19 Mar 2001 20:44:15 +0200
Sender: [email-masked]

Thanx!

My original suggestion was about proxyauth. Did you picked up Alexey's glove
to write a draft on that? I beleive that it is a very important feature that
anyhow supported by many servers and we will benefit from moving it towards
a standard. If you don't up to it, may be somebody else (myself?) will do
it?

John

-----Original Message-----
From: John Gardiner Myers
To: Neystadt, John
Cc: 'Tony Hansen '; 'Alexey Melnikov '; [email-masked] ';
[email-masked]'
Sent: 3/19/01 7:27 PM
Subject: Re: X-NETSCAPE

"Neystadt, John" wrote:
> As to X-NETSCAPE (ProxyAuth) you can read at
> http://help.netscape.com/kb/corporate/19980217-17.html.

X-NETSCAPE is more than proxyauth, there's a way to retrieve a URL for
user self-administration from the server.  I don't have a spec on hand;
the extension is obsolete.

The following is the specification for XSERVERINFO:

------------------------------------------------

The CAPABILITY tag returned by this extension is "XSERVERINFO".
Servers which advertise the XSERVERINFO capability must support both
the XSERVERINFO and XMAILBOXINFO commands.

XSERVERINFO

Syntax:

serverinfo_cmd = "XSERVERINFO" 1*(SPACE atom)

serverinfo_data = "XSERVERINFO" 1*(SPACE atom SPACE nstring)

Description:

The XSERVERINFO command returns information about the IMAP server.
The client specifies in the arguments to the XSERVERINFO the names of
the information items it is requesting.  The server issues an untagged
XSERVERINFO response including the names and values of each of the
requested items before issuing a tagged OK response to XSERVERINFO
command.

If the client requests an information item that the server has no
knowledge of, the server MUST return a NIL value.

Currently-defined information items are:

	MANAGEACCOUNTURL	The URL for managing the user's account
	MANAGELISTSURL		The URL for managing mailing lists
	MANAGEFILTERSURL	The URL for managing filters for
				incoming mail

Example:

C: A001 XSERVERINFO MANAGEACCOUNTURL FOOBAR
S: * XSERVERINFO MANAGEACCOUNTURL "https://[email-masked]:3333/"
FOOBAR NIL
S: A001 OK Completed

XMAILBOXINFO

Syntax:

mailboxinfo_cmd = "XMAILBOXINFO" SPACE mailbox 1*(SPACE atom)

mailboxinfo_data = "XMAILBOXINFO" SPACE mailbox 1*(SPACE atom SPACE
nstring)

Description:

The XMAILBOXINFO command returns information about the specified IMAP
mailbox.  The client specifies in the arguments to the XMAILBOXINFO
the mailbox for which information is being requested and the names of
the information items it is requesting.  The mailbox issues an
untagged XMAILBOXINFO response including mailbox name and the names
and values of each of the requested items before issuing a tagged OK
response to XMAILBOXINFO command.

If the client requests an information item that either the server has
no knowledge of or which is not applicable to the mailbox, the server
MUST return a NIL value.

Currently-defined information items are:

	MANAGEURL		The URL for managing the mailbox
	POSTURL			The URL for posting to the mailbox
				"news:" and "mailto:" URLS are most
				appropriate, though a client must
				safely ignore unrecognized URL types.

Example:

C: A001 XMAILBOXINFO "INBOX" MANAGEURL POSTURL
S: * XMAILBOXINFO "INBOX" MANAGEURL
   "https://srvr.mcom.com:3333/user/userid/INBOX"
    POSTURL "mailto:[email-masked]"
S: A001 OK Completed

Date: Mon, 19 Mar 2001 10:56:31 -0600
From: Chris Newman <[email-masked]>
Subject: informal IMAPEXT discussion
To: [email-masked]
Sender: [email-masked]

We're going to have an informal IMAPEXT discussion during the afternoon 
session at the IETF today.  We'll be discussing the VPIM-related extensions 
since the VPIM people are around, as well as other issues the participants 
desire.

Meet by the IETF message board at 1 PM today.

		- Chris

From: "Neystadt, John" <[email-masked]>
To: "'Tony Hansen '" <[email-masked]>, "'Alexey Melnikov '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: X-NETSCAPE
Date: Mon, 19 Mar 2001 18:37:53 +0200
Sender: [email-masked]

I did not heard about xservinfo.

As to X-NETSCAPE (ProxyAuth) you can read at
http://help.netscape.com/kb/corporate/19980217-17.html.

I can't not found a detailed specification, alhough I've seen it once,
probbably within Netscape's manuals.

-----Original Message-----
From: Tony Hansen
To: Alexey Melnikov
Cc: Neystadt, John; [email-masked]; [email-masked]
Sent: 3/19/01 7:37 AM
Subject: Re: BOUNCE [email-masked]: Approval required:

Are X-NETSCAPE and XSERVINFO defined anywhere that's accessible?

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:
> 
> "Neystadt, John" wrote:
> 
> > Here is one observation:
> >
> > It seems to me, that almost every existing server supports
X-NETSCAPE.
> > Presumable for 'master-password' support. Actually this feature
makes indeed
> > a lot of sense for imap front-ends.
> >
> > May be we should standartise it (or similar approach), instead of
> > implementing un-official extention?
> 
> Netscape has implemented another extension XSERVINFO, that obsoletes
X-NETSCAPE.
> 
> XSERVINFO is kind of server level annotations.
> I said to John Myers that it is a good idea to make this extension
standard
> track document.
> 
> Alexey

Date: Mon, 19 Mar 2001 00:40:42 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: Conditional store (MODTIME) open issues
Sender: [email-masked]

Here is the list of Open Issues I have after San Diego IMAPEXT meeting
(in no particular order). Some comments are below items.

1). modtime: timestamp or sequence counter?

Why we should use timestamps: there is no correlation between sequence
counters for different flags,
modtime timestamps for two different Store operations are guarantied to
have different timestamps (sequence counters are not). A client will be
able to construct search criterion that covers multiple flags
(e.g. "all messages with either \Answered or $MDNSent modified after
XXX").

2). How specify different UNCHANGESINCE for different flags in the same
STORE?  Do we want such granularity anyway?

3). Untagged Modtime response that is used with FETCH/STORE to specify
that client has all data till modtime?
MODTIME Message Data Item in STATUS?

I would say yes.

4). Do we need per flag modtimes? Should they be persistent between IMAP
server restarts?

There are two ways how the proposed extension can be used by a client.
The first use for the client is to synchronize mailbox. This doesn't
require per flag modtimes, but requires that modtime is stored on server
and is preserved between server restarts (i.e. it must be stored in some
persistent storage, for example database).
The second use for the client is to perform atomic update operations on
a set of flags. This requires that server remembers modtime only while
it is running (modtimes should be regenerated on restart) and also per
flag modtimes.

5). Add support for SORT extension?

Alexey

Date: Sun, 18 Mar 2001 23:39:42 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Randall Gellens <[email-masked]>, [email-masked]
Subject: More ANNOTATE comments (was Re: Progress? Meeting?)
Sender: [email-masked]

>    /message/smtp-envelope
>        Defines the top-level of entries which together describe the
>        SMTP envelope used in delivery of the message.  There are no
>        attributes at this level.  The client SHOULD NOT modify the
>        /message/smtp-envelope entry or any sub-entries or any of their
>        attributes, except in messages which have the DRAFT flag set.

Randy, can you add /message/smtp-envelope/auth_sender for authenticated sender
(SMTP AUTH extension)?
This will replace Netscape XSENDER extension.

Alexey

Date: Mon, 19 Mar 2001 00:37:21 -0500
From: Tony Hansen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BOUNCE [email-masked]: Approval required:
Sender: [email-masked]

Are X-NETSCAPE and XSERVINFO defined anywhere that's accessible?

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:
> 
> "Neystadt, John" wrote:
> 
> > Here is one observation:
> >
> > It seems to me, that almost every existing server supports X-NETSCAPE.
> > Presumable for 'master-password' support. Actually this feature makes indeed
> > a lot of sense for imap front-ends.
> >
> > May be we should standartise it (or similar approach), instead of
> > implementing un-official extention?
> 
> Netscape has implemented another extension XSERVINFO, that obsoletes X-NETSCAPE.
> 
> XSERVINFO is kind of server level annotations.
> I said to John Myers that it is a good idea to make this extension standard
> track document.
> 
> Alexey

Date: Sun, 18 Mar 2001 21:09:58 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Neystadt, John" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: BOUNCE [email-masked]: Approval required:
Sender: [email-masked]

"Neystadt, John" wrote:

> Here is one observation:
>
> It seems to me, that almost every existing server supports X-NETSCAPE.
> Presumable for 'master-password' support. Actually this feature makes indeed
> a lot of sense for imap front-ends.
>
> May be we should standartise it (or similar approach), instead of
> implementing un-official extention?

Netscape has implemented another extension XSERVINFO, that obsoletes X-NETSCAPE.

XSERVINFO is kind of server level annotations.
I said to John Myers that it is a good idea to make this extension standard
track document.

Alexey

From: "Neystadt, John" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: BOUNCE [email-masked]: Approval required:
Date: Mon, 19 Mar 2001 04:17:06 +0200
Sender: [email-masked]

Here is one observation:

It seems to me, that almost every existing server supports X-NETSCAPE.
Presumable for 'master-password' support. Actually this feature makes indeed
a lot of sense for imap front-ends.

May be we should standartise it (or similar approach), instead of
implementing un-official extention?

John Neystadt
[email-masked]
http://www.neystadt.org/john/

> -----Original Message-----
> From: Ken Murchison [mailto:[email-masked]]
> Sent: Fri, March 16, 2001 10:24 PM
> To: Chris Newman
> Cc: [email-masked]
> Subject: Re: BOUNCE [email-masked]: Approval required:
> 
> 
> Chris,
> 
> Speaking on behalf of CMU (per Larry's request)
> 
> > >Please send in corrections/additions (preferably in same 
> format) and I'll
> > >post a revised version in a few days.
> > >
> > >               - Chris
> > >
> > >-----
> > >
> > >Standard IMAP Extensions
> > >          IMAP4 4rev1 ACL QUOTA lit+ nspace uid+ tls ID 
> mboxref logindisable
> > >CMU Cyrus  X     X    X    X     X     X     X   X   X    X
> 
> 
> Should be:
> 
>           IMAP4 4rev1 ACL QUOTA lit+ nspace uid+ tls ID 
> mboxref logindisable IDLE
> CMU Cyrus  X     X    X    X     X     X     X   X   X    X 
> (1)     X         X (2)
> 
> 
> (1) only available with Cyrus Murder (IMAP proxy)
> (2) compile-time option (disabled for the test)
> 
> 
> > >POP Capabilities (Lotus - no server)
> > >           TOP PIPELINING UIDL SASL USER EXPIRE RESP-CODES 
> implem STLS
> > >CMU Cyrus  X      X       X    X    X     X                  X    X
> 
> Should be:
> 
>            TOP PIPELINING UIDL SASL USER EXPIRE RESP-CODES implem STLS
> CMU Cyrus   X      X       X    X    X     X        X (3)     X    X
> 
> (3) supported, but wasn't being advertised (fixed in CVS)
> 
> 
> > >IMAP/POP SASL
> > >            P/CRAM I/CRAM digest P/PLAIN I/PLAIN APOP kerb4 GSSAPI
> > >CMU Cyrus    X        X     X                         X     X
> 
> Should be:
> 
>             P/CRAM I/CRAM digest P/PLAIN I/PLAIN APOP kerb4 GSSAPI
> CMU Cyrus    X        X     X       X (4)  X (4)        X     X
> 
> (4) config option (disabled for the test)
> 
> 
> > >Non-Standard IMAP Extensions
> > >          XSENDER X-NETSCAPE
> > >iPlanet     X         X
> > >Novell      X         X
> 
> Add:
> 
>           XSENDER X-NETSCAPE
> CMU Cyrus             X (5)
> 
> (5) compile-time option (disabled for the test)
> 
> 
> Thanks,
> Ken
> -- 
> Kenneth Murchison     Oceana Matrix Ltd.
> Software Engineer     21 Princeton Place
> 716-662-8973 x26      Orchard Park, NY 14127
> --PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
> 

From: "Neystadt, John" <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: IETF-50
Date: Mon, 19 Mar 2001 00:54:41 +0200
Sender: [email-masked]

Since there is no IMAP meeting at this IETF, I though that it may be nice
for those who attend IETF to have a chance met first time face to face (for
those who still have not, like me :))

May be we can do it tomorrow, towards end of the breakfast, say at 8:50am,
near in Ballroom near Saloon E entrance?

John Neystadt

Date: Thu, 15 Mar 2001 01:26:40 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Chris Newman <[email-masked]>
cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Critical Content -- Header or Parameter
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 14 Mar 2001, Chris Newman wrote:
> If I could go back in history and redo things, I'd replace BODYSTRUCTURE
> with a headers/headers-not facility that fetches the skeleton of the MIME
> message minus the body parts themselves.  Any client which does offline or
> local file work has to have an 822/MIME header parser anyway, so why force
> clients to implement two syntaxes for the same data?

Not all clients do offline or local file work.  There are IMAP-only
clients in existance which do not have a clue about how to parse 822 or
MIME.

Unlike 822 or MIME, ENVELOPE and BODYSTRUCTURE actually have a dependable
and structured syntax, that is not subject to the whims of what some email
composer considers esthetically pleasing.  BODYSTRUCTURE also contains
information which is not to be found in the MIME headers.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Wed, 14 Mar 2001 17:02:01 -0800
From: Chris Newman <[email-masked]>
Subject: Re: Critical Content -- Header or Parameter
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

--On Wednesday, March 14, 2001 11:31 -0500 Eric Burger 
<[email-masked]> wrote:
> OK, here's another choice (thanks to Mark Crispin):  How about making the
> critical content notation a parameter to Content-Type?

Poor choice.  The scope of Content-Type parameters is intended to be 
specific to the content type.  Thus a "foo" parameter on application/bar 
can have a different meaning from a "foo" parameter on application/baz.

If you want to add a parameter to an existing header, add it to 
Content-Disposition which has parameters which are _not_ specific to the 
disposition value and is already in the IMAP BODYSTRUCTURE.  The "filename" 
parameter on Content-Disposition is a perfect example of this sort of thing.

Futher, the concept of "criticality" fits much better as an aspect of the 
"disposition" of the body part rather than a modifier to the "type" of a 
body part.

If I could go back in history and redo things, I'd replace BODYSTRUCTURE 
with a headers/headers-not facility that fetches the skeleton of the MIME 
message minus the body parts themselves.  Any client which does offline or 
local file work has to have an 822/MIME header parser anyway, so why force 
clients to implement two syntaxes for the same data?

		- Chris

Date: Wed, 14 Mar 2001 18:35:57 -0500
From: Dave Aronson <[email-masked]>
Organization: Air 'n Sun free Fidonet BBS, (703) 319-0714
To: [email-masked]
Subject: Re: [VPIM] Critical Content -- Header or Parameter
Sender: [email-masked]

"Eric Burger" <[email-masked]> wrote:

>  We rejected making critical content a parameter to Content-Disposition,
>  since people felt that would bend the semantics of Content-Disposition
>  a bit too much.

And it bends those of Content-TYPE *less*?  Methinks I missed this
discussion; there seems to be nothing  relevant in the past several months
of VPIM WG mailing list archive.  (Found the archives, thanks, Glenn!)  If
you mean in the draft itself, I don't see much logic there beyond that it
"overloads the meaning of the entity".  I'll admit I'm not intimately
familiar with the original intent of that entity, but it seems to me that
criticality is indeed an instruction on disposition.  One obvious case is
that if something with criticality of CRITICAL can't be rendered, DISPOSE of
the message.  B-)  Sorry if I'm beating a dead horse, but it was dead when I
got here, honest, officer!

>  The argument for making critical content a parameter to Content-Type
>  is that all IMAP servers return Content-Type parameters in the
>  BODY/BODYSTRUCTURE methods.  They would not have to implement a
>  BODYSTRUCTURE extension to return Critical-Content.

"Because it was there" may have worked for Hillary (Sir Edmund or Clinton,
take yer pick), but I don't think that's quite the sort of deep technical
analysis usually expected of the IETF.  B-)

>  The argument against making critical content a parameter to Content-Type
>  is that it goes directly against two paragraphs in RFC 2045:
>
>     There are NO globally-meaningful parameters that apply to all media
>     types.  Truly global mechanisms are best addressed, in the MIME
>     model, by the definition of additional Content-* header fields.
>
>  a CRITICALITY parameter is a globally-meaningful parameter.

I'm not sure I quite grok what you mean here.  It's not
"globally-meaningful" in the sense of applying to the entire message; it is
only for one piece.  (Sounds like it's probably got some locally-specific
meaning explained in the RFC; I'll go check it later, as I'm writing this
offline.)  However, the other argument against it:

>  A Content-Type parameter is supposed to be for
>  modifiers to the Content-Type only:

is what knocks it out for me.  The criticality has no relation to what type
of thing is actually inside -- especially since there could be parts of the
exact same type and different criticality, such as Voice-Message versus
Spoken-Receipient.  (Sure, you care if the message itself gets through, but
do you really want to communicate with anyone who has to be reminded who he
is?  B->)  Therefore, at least IMHO, it should not be in Content-Type.

>  Do we really care?

Enough to argue about it -- but that doesn't say much!  B-)

>  I'd like to hear from IMAP server vendors.

Well, seeing as I'm currently Between Positions (see sig) and might possibly
get hired by an IMAP server vendor....

(NOTE: This is a resend to the imapext mailing list, to which I do not
subscribe; I am sending it because what I was replying to was also sent
here.  Please include either me or the VPIM mailing list
([email-masked]) in any replies.  Thank you.)

-- 
Dave Aronson, Sysop of AirNSun free public Fidonet BBS @ +1-703-319-0714
The above opinions are MINE, ALL MINE, but for rent at reasonable rates.
I'VE BEEN LAID OFF AGAIN; see http://djajobhunt2001.tripod.com for info.

Date: Wed, 14 Mar 2001 10:26:44 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Critical Content -- Header or Parameter
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, 14 Mar 2001 11:31:47 -0500, Eric Burger wrote:
> I'd like to hear from IMAP server vendors.

As an "IMAP server vendor", here's my public statement on what I already told
Eric in private:

It doesn't matter much to me whether there is a Content-Criticality header, or
a CRITIALITY parameter to Content-Type.  I always believed that there should
only have been one MIME header, and use parameters for everything else.  But
that horse is long out of the barn.

I am concerned, given the stalling against having Content-Location appear in
the IMAP BODYSTRUCTURE, that there is probably little chance of ever having
Content-Criticality in there.  So, as a purely practical matter, I recommend
the CRITICALITY parameter as something that you won't have to fight to see
happen.

Reply-To: <[email-masked]>
From: "Eric Burger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Critical Content -- Header or Parameter
Date: Wed, 14 Mar 2001 11:31:47 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01C0AC7A.5AAC4200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

OK, here's another choice (thanks to Mark Crispin):  How about making the
critical content notation a parameter to Content-Type?

We rejected making critical content a parameter to Content-Disposition,
since people felt that would bend the semantics of Content-Disposition a bit
too much.

The argument for making critical content a parameter to Content-Type is that
all IMAP servers return Content-Type parameters in the BODY/BODYSTRUCTURE
methods.  They would not have to implement a BODYSTRUCTURE extension to
return Critical-Content.

That is, instead of
	Content-Type: TEXT/PLAIN;CHARSET=US-ASCII
	Content-Criticality: IGNORE
we would use something like
	Content-Type: TEXT/PLAIN;CHARSET=US-ASCII;CRITICALITY=IGNORE

The argument against making critical content a parameter to Content-Type is
that it goes directly against two paragraphs in RFC 2045:

   There are NO globally-meaningful parameters that apply to all media
   types.  Truly global mechanisms are best addressed, in the MIME
   model, by the definition of additional Content-* header fields.

a CRITICALITY parameter is a globally-meaningful parameter.  A Content-Type
parameter is supposed to be for modifiers to the Content-Type only:

   Parameters are modifiers of the media subtype, and as such do not
   fundamentally affect the nature of the content.  The set of
   meaningful parameters depends on the media type and subtype.  Most
   parameters are associated with a single specific subtype.  However, a
   given top-level media type may define parameters which are applicable
   to any subtype of that type.

Do we really care?  I'd like to hear from IMAP server vendors.

Thoughts?

[If you're wondering what this is about, see
http://www.ietf.org/internet-drafts/draft-ietf-vpim-cc-03.txt ]

------=_NextPart_000_0035_01C0AC7A.5AAC4200
Content-Type: text/x-vcard;
	name="Eric Burger.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Eric Burger.vcf"

BEGIN:VCARD
VERSION:2.1
N:Burger;Eric
FN:Eric Burger
ORG:SnowShore Networks, Inc.
TITLE:Chief Technology Officer
TEL;WORK;VOICE:+1 (978) 367-8403
TEL;CELL;VOICE:+1 (703) 304-3883
TEL;WORK;FAX:+1 (978) 367-8499
ADR;WORK:;;285 Billerica Rd.;Chelmsford;MA;01824-4120;United States of =
America
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:285 Billerica =
Rd.=3D0D=3D0AChelmsford, MA 01824-4120=3D0D=3D0AUnited States of =
Ameri=3D
ca
URL;WORK:http://www.snowshore.com
EMAIL;PREF;INTERNET:[email-masked]
REV:20010312T171942Z
END:VCARD

------=_NextPart_000_0035_01C0AC7A.5AAC4200--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-01.txt
Date: Mon, 05 Mar 2001 06:45:01 -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		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-01.txt
	Pages		: 19
	Date		: 02-Mar-01
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

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

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-annotate-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-annotate-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-annotate-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-annotate-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, 02 Mar 2001 12:03:42 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Randall Gellens <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Progress? Meeting?
Sender: [email-masked]

Randall Gellens wrote:

> At 12:15 PM -0800 2/20/01, Randall Gellens wrote:
>
> >  I'm trying to get an updated Annotations draft done shortly.
>
> I just sent it in.  Until it appears in the Internet Drafts
> directories, you can get it from
> <ftp://ftp.pensive.org/Public/Randy/annotate-02.txt>
>

Few comments:

>7 Private versus Shared
[skipped]

>        <<<OPEN-ISSUE>>>
>
>    This is dangerous since it allows a client to store an entry without
>    knowing if other users are able to view it.
>
>    How a client learns or changes the default is an open issue.  One
>    suggestion is to use an additional ACL bit to indicate the current
>    default state.
>
>    It may be better to remove the default, and force clients to always
>    explicitly store into one or the other.

I don't like default state. I would prefer that as well.

>8.2 ANNOTATION Message Data Item in FETCH Response
>
>    The ANNOTATION message data item in the FETCH response displays
>    information about annotations in a message.
>
>    ANNOTATION parenthesised list

------------------------^ parenthesized

>        The response consists of a list of entries, each of which has a
>        list of attribute-value pairs.
>
>    Examples:
>        C: a FETCH 1 (ANNOTATION ("/message/comment" "value"))
>        S: * 1 FETCH (ANNOTATION ("/message/comment"
>                                   ("value.priv" "My comment"
>                                    "value.shared" NIL)))
>        S: a OK Fetch complete

I would prefer if a server can omit values that it doesn't store currently
(i.e. server is allowed to send the following response:

        S: * 1 FETCH (ANNOTATION ("/message/comment"
                                    ("value.priv" "My comment")))

>8.7 ACL Rights
>
>    The "r" right, as specified in [ACL-EXT], is required to use
>    annotations in any command other than STORE.
>
>    The "w" right is needed to use shared annotations in the STORE
>    command.

These two seems Ok.

>    The "s" right is needed to use private annotations in the STORE
>    command.

I disagree. "s" right is used for \Seen flag, private annotations have
nothing to do with \Seen flag. There is no guaranty that \Seen flag is
private for the user. I would rather add a new right for that particular
purpose.

Alexey