IMAP Channel Draft version 2 released

I've pushed version 02 of the Channel draft to the ID editor. Early
access can be had at:

        http://atg.aciworldwide.com/draft-nerenberg-imap-channel-02.txt

Diffs from version 01:

  Changed <channel-set> to use <section-spec> instead of <section-text>.
  This allows retrieval of headers and MIME structure.

  <channel-data> returns a <section-spec>, not <nz-number> (to match
  <channel> syntax).

  Add missing SP tokens to grammar.

  Grammar fix to allow foo: as a valid URI in a request.

  Add UID CHANNEL.

  Clarify response when client issues a command with an unsupported scheme.

  Add section on command sequencing.

  Note arbitrary ordering of untagged responses.

  Replace URI-reference with absoluteURI. The IMAP server can't maintain
  the state required to deal with relative URIs. This also solves an
  ambiguity between parsing "NIL" as <nil> or as a relative URI.

Re: CHANNEL and proxy credentials

There is an underlying assumption that an IMAP server offering
CHANNEL services is doing this by implementing the additional
schemes internally, or with the cooperation of a trusted external
service. Presumably these servers share an authentication namespace.

The only way to override this is by specifying authentication
information in the URI (where the scheme permits this).

--lyndon

CHANNEL and proxy credentials

Advanced authentication frameworks support proxy credentials.
The most obvious example of this is Kerberos V.  An extremely naive
example is just sending your password to the server that you want to
act on your behalf.  There have also been discussions of this in the
PKI world, though I'm not familiar with them.

This is something that might be useful for channel.  While there's no
specification corresponding to SASL on how to ask for or transmit
credentials, attempting to add such a thing to channel would be
worthwhile so we can gain experience with it and see what's going on.

It would probably be sufficient to have another paren'd list send as
part of the channel command, so:

a CHANNEL ("KERBEROS_V5" <base64> "PKIX509BLAH" <base64>) ...

for the client to transmit some sort of proxy credentials to the
server which it thinks might be useful for the IMAP server to make the
established channel.

In the kerberos world the blob would be proxiable ticket (see 2.5 of
draft-ietf-krb-wg-kerberos-clarifications-00 for instance).  The
server would decode the blob and stuff it into its kerberos (client)
ticket cache.

Larry

[Fwd: IMAPEXT bar BOF in Minneapolis]

As we just discussed with Pere, we should also discuss CHANNEL and
BINARY.

-------- Original Message --------
Subject: IMAPEXT bar BOF in Minneapolis
Date: Sun, 17 Mar 2002 18:36:38 -0700
From: Alexey Melnikov <mel <at> messagingdirect.com>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <ietf-imapext <at> imc.org>

Monday around 16.30 near the message board. (This should start after
SASL bar BOF, I believe a lot of people interested in IMAPEXT will
attend SASL as well).

Tentative agenda:

IMAP ACL2 issues (in no particular order):
 1). REPLACEACL
 2). Setting an ACL on a mailbox hierarchy.
 3). How to encode user names starting with "-" and "$".
 4). 'r' to read QUOTA and ACL?
 5). 'a' to read ACL as well.
 6). Which set of rights correspond to READ-WRITE?
      Cyrus and our MessagingDirect server: if either "w" or "t" are
allowed for the current user
      Communigate: when only "s" allowed.
 7). Subscription and listing:
      LIST - 'l' right
      LSUB - 'l'? (if subscription is not an attribute of a mailbox?)

Mail Extensions for Unified Messaging / TUI Access to Email BOF

I would like to have the first meeting of the TUI/UM extensions Bar BOF
meeting TODAY in the 1-3 PM timeslot.  Let's meet at the message board.  If
you arrive and there are no people there, check the board for a forward
location pointer.

Greg V.

-----Original Message-----
From: Vaudreuil, Greg M (Greg) 
Sent: Wednesday, March 06, 2002 2:04 PM
To: Zmolek, Andrew (Andrew); dcrocker <at> brandenburg.com;
gparsons <at> nortelnetworks.com; eburger <at> snowshore.com;
vpim <at> lists.neystadt.org
Subject: [VPIM] RE: Rolling BoF?

Lets set a first session from 1-3 Monday, and pick up additional timeslots
from there if we find a productive track.   The goal is to determine if we
have a topic of sufficient interest and contributors priority to pursue
chartering as a formal IETF work-group.

I am particularly interested in soliciting attendance by folks tuned into
the latest 3GPP MMS work and standards needs.  

I can't guess accurately a location.  I will pick a spot and post it on the
IETF message board by Monday morning.   I am sure many of us may gather in
the hallway after the Apps area meeting for lunch. 

Greg V.

VPIM WG Agenda

CHANNEL usage

[Here's the *complete* response -- sorry about the last one that got
away early.]

> - Am I allowed to get the entire message instead of just a part?

No, you can only grab things that can be indentified by MIME section
numbers. This is an artifact of the syntax, and not necessarily a
deliberate retriction. Channel was intended to provide alternative
processing of specific body sections. The idea of sending the entire
message somewhere never even came up during the initial design
discussions.

> - The document says (in a comment)
>          You cannot ask for .HEADERS or .MIME data with CHANNEL.

It didn't seem to be a useful thing to do. At least, not useful
enough to justify adding complexity to the parsers to handle it.
(Which admittedly isn't a lot of complexity. However I don't like
adding features to protocols unless there is a compelling need
for them. If there's a consensus that fetching .HEADERS and .MIME
is a useful addition, in they go.)

The scope of this extension seems to be taking on a life of it's
own -- certainly one that's much broader than what Steve and Barry
and I originally envisioned. It would be useful to hear what other
ways people see themselves using CHANNEL. It may be that we have
to revisit some of the original design assumptions we made.

--lyndon

Re: Interesting (gross?) use of CHANNEL

> - Am I allowed to get the entire message instead of just a part?

No, you can only grab things that can be indentified by MIME section
numbers. This is an artifact of the syntax, and not necessarily a
deliverate retriction. Channel was intended to provide alternative
processing of specific body sections. The idea of sending the entire
message somewhere never even came up.

> - The document says (in a comment)
>          You cannot ask for .HEADERS or .MIME data with CHANNEL.

It didn't seem to be a useful thing to do. At least, not useful
enough to justify adding complexity to the parsers to handle it.
(Which admittedly isn't a lot of complexity. However I don't like
adding "features" to protocols unless there is a compelling need
for them. If there's a consensus that fetching .HEADERS and .MIME

Re: Interesting (gross?) use of CHANNEL

Okay, I thought you were talking about the IMAP server itself
modifying the body content. Yes, it's perfectly reasonable for an
external process to modify the body content in order to satisfy the
channel request.

--lyndon

Re: Interesting (gross?) use of CHANNEL

> What do people think of using "mailto" in CHANNEL? That is, if I have 
> a message in a mailbox, I can CHANNEL it using a mailto URL in order 
> to effect the sending of the message. My thought is that the target 
> of the mailto should only be the envelope recipient and should not 
> change the contents of the message header in anyway.

Urgh. If you mailto:, I would expect the server to simply BARF
the request back to you. Unless, in some bizarre circumstance,
it made sense to honour the request. The bottom line is that
the server has to interpret the presented URI in whatever
form makes sense to it. If the URI that's presented is absurd,
the server gets to deal with it as such.

> In my ideal 
> picture, the server would take the message and prepend Resent-* 
> fields using the destination and whatever other fields are specified 
> in the URL. 

No! The draft does not mention it, but the (my) intent is that
the server (or anything else in the data path) canNOT mess
with the data content in any way.

> You would, of course, only be able to CHANNEL to mailto 
> for an entire message or for a subpart which was itself of type 
> message/rfc822. This seems to me an ideal way to implement the Resend 
> command in many clients, and could even be used to send draft 
> messages out for the first time.

Yuk. No. Again, CHANNEL is NOT alowwed to modify the data content
in ANY way. I will spell this out loudly in the next draft.

--lyndon

Re: UID for IMAP Channel?

> > When Notification scenarios are considered, it may be that the client gets
> > some indication about a specific message for which it then issues a CHANNEL
> > command (i.e, the client did not necessarily received all sequence numbers
> > in the mailbox before issuing the CHANNEL command, so it can't map between
> > UID and sequence number). 

IMAP has no "notification scenarios" as this describes.  It's a common
misconception that UIDs have an equivalence map to IMAP sequence
numbers. There are no asynchronous events that map between the two. A
client that issues an IMAP CHANNEL request simply asks the server to
perform a task on its behalf. The server itself decides if the request
is valid, let alone if it is a reasonable idea.

--lyndon