Subject: Re: Progress? Meeting?
From: Randall Gellens <[email-masked]>
To: Randall Gellens <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked]
Date: Wed, 28 Feb 2001 16:48:40 -0800
List-Id: <ietf-imapext.imc.org>

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>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
One of the greatest labor saving inventions of today is tomorrow.  -
                                               --Vincent T. Foss

Date: Wed, 28 Feb 2001 13:52:58 -0800
From: Chris Newman <[email-masked]>
Subject: Re: binary draft and APPEND
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
Cc: [email-masked]
Sender: [email-masked]

--On Tuesday, February 27, 2001 13:20 -0700 Lyndon Nerenberg 
<[email-masked]> wrote:

>> I disagree with section 4.4 of this draft on the grounds that it breaks
>> backwards compatibility with IMAP clients that are not binary aware.
>>
>> RFC 2060 section 4.3.1 states "Implementations MUST encode binary data
>> into  a textual form such as BASE64 before transmitting the data."  I
>> interpret  this to mean that any RFC 2060 server implementation which
>> receives a  "binary" body part must behave as if it were downconverted
>> to "base64" CTE  with respect to BODYSTRUCTURE and FETCH commands.
>
> I don't see how this breaks non-binary clients. If the client doesn't
> do BINARY, it would never issue an APPEND with a <literal8> to
> begin with.

Scenario:
* Client A supports BINARY, Client B doesn't
* Client A does an APPEND using <literal8> of a message with a true binary
  transfer-encoding to a shared IMAP mailbox
* Client B does a BODY FETCH of that message from the IMAP mailbox

Section 4.4 says:
     The server SHOULD NOT perform any content-transfer-encoding conversion
     of the data.

but in this scenario, the server MUST perform a content-transfer-encoding 
in order to maintain compatibility with the IMAP base spec.

>> I'm not fond of BINARYSTRUCTURE.  It results in two syntatically
>> identical  complex FETCH items with subtle semantic differences, neither
>> of which  necessarily reflect the real bodystructure of the message in
>> the store.
>
> I'm not a fan of BINARYSTRUCTURE either, and I like your BINARYSIZES
> proposal a lot better. In fact, I would prefer to remove this altogether,
> however a few people had requested the ability to obtain the BINARY
> fetch size prior to issuing the FETCH. Tony, you were one of the
> proponents of this: could you provide a rationale for this feature?
> Maybe I'm misunderstanding what people actually asking for here.

Then I suggest we remove it altogether now unless someone has a compelling 
reason.  There are two reasons to desire sizes in advance: (1) to know how 
many resources to allocate.  (2) as a trigger for alternate behavior (e.g., 
don't download attachments over 2MB over a modem link).  The existing sizes 
in BODYSTRUCTURE provides an upper-bound for 1 and can be turned into an 
adequate estimate for 2.

	- Chris

Date: Tue, 27 Feb 2001 18:27:29 -0500
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: Lyndon Nerenberg <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: binary draft and APPEND
Sender: [email-masked]

Lyndon Nerenberg wrote:
> 
> > I'm not fond of BINARYSTRUCTURE.  It results in two syntatically identical
> > complex FETCH items with subtle semantic differences, neither of which
> > necessarily reflect the real bodystructure of the message in the store.
> 
> I'm not a fan of BINARYSTRUCTURE either, and I like your BINARYSIZES
> proposal a lot better. In fact, I would prefer to remove this altogether,
> however a few people had requested the ability to obtain the BINARY
> fetch size prior to issuing the FETCH. Tony, you were one of the
> proponents of this: could you provide a rationale for this feature?
> Maybe I'm misunderstanding what people actually asking for here.

No, wasn't me, at least not that I remember. Sorry.

	Tony Hansen
	[email-masked]

From: Lyndon Nerenberg <[email-masked]>
Organization: ACI / Messagingdirect
To: Chris Newman <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: binary draft and APPEND 
Date: Tue, 27 Feb 2001 13:20:22 -0700
Sender: [email-masked]

> I disagree with section 4.4 of this draft on the grounds that it breaks 
> backwards compatibility with IMAP clients that are not binary aware.
> 
> RFC 2060 section 4.3.1 states "Implementations MUST encode binary data into 
> a textual form such as BASE64 before transmitting the data."  I interpret 
> this to mean that any RFC 2060 server implementation which receives a 
> "binary" body part must behave as if it were downconverted to "base64" CTE 
> with respect to BODYSTRUCTURE and FETCH commands.

I don't see how this breaks non-binary clients. If the client doesn't
do BINARY, it would never issue an APPEND with a <literal8> to
begin with.

> No statement should be made about the message store capabilities.  Both 
> implementations (a binary message store which does base64 conversion for 
> BODY fetches, or a non-binary message store which removes base64/QP for 
> BINARY fetches) are valid, IMHO.

You're right. I'll remove that text.

> I'm not fond of BINARYSTRUCTURE.  It results in two syntatically identical 
> complex FETCH items with subtle semantic differences, neither of which 
> necessarily reflect the real bodystructure of the message in the store.

I'm not a fan of BINARYSTRUCTURE either, and I like your BINARYSIZES
proposal a lot better. In fact, I would prefer to remove this altogether,
however a few people had requested the ability to obtain the BINARY
fetch size prior to issuing the FETCH. Tony, you were one of the
proponents of this: could you provide a rationale for this feature?
Maybe I'm misunderstanding what people actually asking for here.

--lyndon

From: Lyndon Nerenberg <[email-masked]>
Organization: ACI / Messagingdirect
To: "Neystadt, John" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: newmail notification protocol 
Date: Mon, 26 Feb 2001 15:36:26 -0700
Sender: [email-masked]

> I am thinking about notification gateway application - for example to
> monitor multiple subscribers accounts and send them sms'es.

SIN (or its successor) isn't the correct solution for this problem.
What you want for this application is to have your local delivery
agent push the SMS messages out.

> Another issue is with availability. How can we enable client to request from
> server to queue events persistently if it currently is not connected to SIN
> server?

You don't. This is a deliberate design decistion. SIN reports event
*triggers* without communicating any context. If you want the
context you get that through the primary application protocol.

--lyndon

Date: Mon, 26 Feb 2001 13:54:52 -0800
From: Chris Newman <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Mark Crispin <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Saturday, February 24, 2001 0:49 -0800 Mark Crispin 
<[email-masked]> wrote:
> Assuming that pejorative terms such as "weakness" are not a requirement,

I'd prefer if all opinions about the severity of the problem were omitted. 
But the problem (that the network bandwidth needed for the SORT/THREAD 
response grows unbounded with the number of messages in the mailbox, unlike 
the FETCH command) should be clearly described.

> Assuming that such a prohibition exists, what about a reference to a
> "separate document dealing with IMAP message set windowing", similar to
> the existing reference to a "separate document dealing with IMAP
> internationalization."?

That's fine.

> If that is out of the way, we can push SORT/THREAD and start windowing.
> You can be assured that the push of SORT/THREAD essentially requires a
> windowing document, just as it requires an i18n document.
>
> Does this work for you?

Close, but not quite.  The problem is that as long as the windowing problem 
remains unsolved, it may be necessary to tweak the existing SORT/THREAD to 
make windowing simpler.  This is particularly risky if we wish to window 
threads, where the windowing and thread hierarchy model will be tightly 
intertwined.  The basic principle of concern: "if you know you're going to 
extend a facility, make sure the facility is designed to accommodate the 
expected extension."  I'm honestly not sure SORT/THREAD meet that test.  So 
here are some options I see:

(A) We put out SORT/THREAD as experimental so that if we have to tweak them 
it's no big deal.

(B) We put out SORT/THREAD as proposed standard, but have a firm agreement 
that if the windowing extension can be made simpler by a tweak to 
SORT/THREAD we'll recycle them at proposed with that tweak.

(C) Let SORT/THREAD sit where they are until we have rough concensus on a 
windowing strawman with a firm level of confidence that we won't need to 
tweak SORT/THREAD.

		- Chris

Date: Mon, 26 Feb 2001 10:49:53 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Chris Newman <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

Chris -

You have made your claims about "non-scalability" of SORT and THREAD many
times.  Considerable first-hand implementation experience, as well as
production operational experience over a period of years, contradicts these
claims.

SORT and THREAD have multiple client and server implementations.  They are
proven to work, and work well enough that servers which don't have the
facility are at a considerable disadvantage compared to those which do.

I have also spent some time talking with developers of MUAs for Palms and
other PDA type devices who indicate that the form of windowing that you
outline is not the direction in what PDA email applications are going.

To the best of my knowledge, you have no first-hand experience with IMAP
clients that use SORT and THREAD.  In fact, I believe that you have not
written an IMAP client at all.  I'm not such if you've talked with PDA
implementors eeither.  If you have such experience, please share it.

There is no evidence that windowing is anything other than a solution in
search of a problem.  I am willing to work on it, for the political reasons if
nothing else.  However, given that windowing is orthogonal to searching,
sorting, and threading, the latter functionalities should not be burdened with
a mandatory-to-implement windowing mechanism.  Windowing should stand or die
on its own (lack of) merit.

The fact that people seriously suggest "punt on windowing THREAD, just window
SORT" indicates to me that the people making such statements aren't directly
involved in what users want.  Threading is what most users want; sorting is
much less interesting if threading is available.

If windowing isn't worth doing right, it's not worth doing.

Date: Fri, 23 Feb 2001 17:44:29 -0800
From: Chris Newman <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Mark Crispin <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Friday, February 23, 2001 15:13 -0800 Mark Crispin 
<[email-masked]> wrote:
> What this indicates is that SORT and THREAD should be published now

As I have for the past several years, I remain opposed to moving SORT and 
THREAD forward on the standards track unless a facility to provide 
scalability on the basis of mailbox size is also complete.

The fact that building such a facility as a separate extension layered on 
top of SORT and THREAD has proved difficult and complex indicates to me 
that SORT and THREAD may not be adequately designed to accommodate 
necessary functionality and thus are not ready to move forward on the 
standards track.

The IESG has decided that IMAP is too complex and doesn't work well enough 
and have indicated there will be significant pushback on IMAP extensions. 
I may disagree with the IESG on the former conclusion (IMAP seems far 
simpler and more interoperable than HTTP to me, especially given it's 
solving a much more complex problem), but we would be ill-advised to move 
forward with extensions when we suspect there's a need for one or more 
"tune up" extensions later.

> I object to kludges being hammered through in a rush for a partial 
solution,

I agree 100% with this statement, and it explains exactly why I don't want 
SORT and THREAD to be moved on the standards track.  SORT and THREAD as 
currently specified are a partial solution since they are not scalable on 
the basis of mailbox size.  I also have some concern about the extra round 
trip they currently require.

		- Chris

From: "Neystadt, John" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: newmail notification protocol 
Date: Mon, 26 Feb 2001 17:11:54 +0200
Sender: [email-masked]

I am thinking about notification gateway application - for example to
monitor multiple subscribers accounts and send them sms'es.

Such a client will need to monitor more than one account.
Current porposed protocol requires to open a SIN connection per account,
which is not scalable.

I propose to extend namespaces within the protocol to include account name.

There is an issue with authentication is such a case. Two options:

1. Allow to authenticate consequently for more than one account. 
2. Allow trusted applications with master password (similiar to Netscape's
PROXYAUTH proprietry extension).

Another issue is with availability. How can we enable client to request from
server to queue events persistently if it currently is not connected to SIN
server?

What do you think?

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

-----Original Message-----
From: Lyndon Nerenberg [mailto:[email-masked]]
Sent: Tue, February 13, 2001 11:42 PM
To: Eric Burger
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: newmail notification protocol 

> I'm wondering if defining a profile for the SIP message waiting protocol
> (draft-mahy-sip-message-waiting-01.txt) wouldn't be a better approach.
> 
> On the one hand, the IMAP server and biff client would only need to
> implement a VERY small subset of SIP.

An interesting idea. A quick scan of the draft makes me think this might
work, although it would be restricted to the email case only.

> In addition, more and more firewalls are SIP-friendly, so you could use
UDP
> (although TCP's an option).

You need authentication in there, otherwise people would be able to
use the SIP service to probe your IMAP server namespace. Since IMAP
uses SASL you'll have to provide at least the same level of security
in SIP as the corresponding IMAP server. This will require some
investigation.

> Work to be done in this case would be on the event profile for subscribing
> to a particular IMAP folder.  That said, that work probably needs to be
done
> anyway for the SIP MWI draft.

Do you want to put up a strawman? While I like SINs generality, the
immediate need is clearly for email, and if an existing protocol can
provide the functionality in a light-weight manner, I'm all for it.

--lyndon

Date: Sun, 25 Feb 2001 22:11:26 -0600
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: So, do we meet?
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2/23/01 at 1:01 PM -0800, Mark Crispin wrote:

>Is it worth meeting if it's only a one-hour session?  Specifically, what
>business do we need to do face-to-face (obviously it isn't much if only an
>hour is needed), and does it need to be attended to at this IETF or can it be
>deferred to the next one?

At this point, I'm inclined to agree. I haven't heard screaming for a 
meeting in Minneapolis, or a list of issues that are currently 
front-burner that can't be addressed on the list. I'd be glad to hear 
that the "usual suspects" who do go to Minneapolis get together for a 
"bar-BOF" to kickstart some work, but unless I hear strong arguments 
otherwise before noon US Eastern Time Monday, we'll leave an official 
meeting until London.

pr

-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Sat, 24 Feb 2001 00:49:27 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Chris Newman <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 23 Feb 2001 16:08:20 -0800, Chris Newman wrote:
> But
> as protocol designers it's our responsibility to make the protocol
> sufficent if a client chooses to support large mailboxes.

I probably have more experience with developing IMAP clients that support
large mailboxes than anyone else.  Even my earliest efforts supported
mailboxes with a number of messages in the 5-digit range (and a lot of popular
clients today collapse before 4-digits).

Scalability is a good thing, but it is possible to take such arguments to
needless extremes.

> An acceptable compromise to me would be:
> SORT/THREAD move onto the standards track at the same time as the windowing
> facility.  SORT/THREAD drafts should note the weakness they have with
> respect to scalability on the basis of mailbox size and include at least a
> non-normative reference to the windowing facility as a way to address the
> problem.

Assuming that pejorative terms such as "weakness" are not a requirement, this
may be a foundation to work on.

The problem with moving them out simultaneously is that it puts us in the
position of simultaneously stalling SORT/THREAD and rushing windowing.  We're
clearly spinning our wheels having three pots on the stove at a time.

Can a reference to a "work in progress" can be in a standards-track document?
Clearly it can't be in a Draft or Full Standard, but I believe that a similar
prohibition exists with a Proposed Standard, right?

Assuming that such a prohibition exists, what about a reference to a "separate
document dealing with IMAP message set windowing", similar to the existing
reference to a "separate document dealing with IMAP internationalization."?

If that is out of the way, we can push SORT/THREAD and start windowing.  You
can be assured that the push of SORT/THREAD essentially requires a windowing
document, just as it requires an i18n document.

Does this work for you?

Date: Sat, 24 Feb 2001 02:53:21 -0500
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: draft-leiba-imap-search-multiple-00.txt
Sender: [email-masked]

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

Sigh... and here's the draft that I didn't attach to the other note.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

--==========290856023==========
Content-Type: text/plain; charset=us-ascii;
 name="draft-leiba-imap-search-multiple-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="draft-leiba-imap-search-multiple-00.txt"; size=6784

Network Working Group                                           B. Leiba
Internet Draft                           IBM T.J. Watson Research Center
Document: draft-leiba-imap-search-multiple-00.txt          February 2001
                                                     Expires August 2001

              IMAP4 SEARCHM Command for Multiple Mailboxes

Status of this Document

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

   A revised version of this draft document will be submitted to the RFC
   editor as an Proposed Standard for the Internet Community. 
   Discussion and suggestions for improvement are requested, and should
   be sent to [email-masked].  This document will expire before 31
   August 2001.  Distribution of this memo is unlimited.

1. Abstract

   The IMAP4 specification allows the searching only of the selected
   mailbox.  A user often wants to search multiple mailboxes, and a
   client that wishes to support this must issue a series of SELECT and
   SEARCH commands, waiting for each to complete before moving on to the
   next.  This extension allows a client to search multiple mailboxes
   with one command, limiting the round-trips and waiting for various
   searches to complete.  This also introduces named searches, allowing
   a client to pipeline the searches if it chooses.

B. Leiba                  Expires August 2001                  [Page 1]

Internet DRAFT    IMAP4 SEARCHM for Multiple Mailboxes     February 2001

2. Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Keywords].

3. The SEARCHM command

   The basic syntax if the SEARCHM command (see the formal grammar for
   the exact syntax) is

          tag SEARCHM "search-name" (options) (list of mailbox URLs)
            (search criteria)

   The mailbox URLs MUST be relative URLs that point to IMAP mailboxes
   on this server; this command does not do referrals.  The URLs MAY
   contain the IMAP mailbox wildcard characters.  The search criteria
   are the same as those specified in [IMAP].

   The search name is used to related the SEARCHM responses to the
   search performed, allowing the client to send multiple SEARCHM
   commands without having to wait for all responses.  The server MAY
   perform those searches in parallel; it MAY instead serialize them.

   The options control the operation of the SEARCHM command.  There is
   one option defined by this document: "depth".  The option "depth(n)"
   causes the SEARCHM command to traverse the hierarchy "n" levels down
   (including the current level).  Thus, "xyz*" with depth(2) and
   "xyz/*" with depth(1) will both match child mailboxes of "xyz", but
   will not match child mailboxes of those children (of course, the
   former will also match "xyzabc", while the latter will not).

   Other options may be defined by extensions.

   The server returns one untagged SEARCHM response for each mailbox
   that matches one or more of the URLs and that has messages that match
   the search criteria.  The server MUST NOT return a SEARCHM response
   that lists no message numbers.  There are also no errors that come
   from unmatched mailbox URLs.

   The command "UID SEARCHM" behaves in an analogous way to "UID SEARCH"
   (see [IMAP]), returning UIDs instead of message numbers.

B. Leiba                  Expires August 2001                  [Page
2]

Internet DRAFT    IMAP4 SEARCHM for Multiple Mailboxes     February 2001

4. Example

   C: tag1 SEARCHM "unseen" (depth(1)) ("folder1" "folder2/*") (unseen)
   C: tag2 SEARCHM "chad" () ("folder1" "folder2/*") (subject "chad")
   S: * SEARCHM "unseen" "folder1" (1 3 5 7 9)
   S: * SEARCHM "chad" "folder1" (1 2 3 4 8)
   S: * SEARCHM "unseen" "folder2/banana" (2 4)
   S: * SEARCHM "unseen" "folder2/peach" (691)
   S: tag1 OK done
   S: * SEARCHM "chad" "folder2/dubya" (3 6 9 12)
   S: tag2 OK done

5. Formal Grammar

   Items not defined here are defined in the formal grammar of [IMAP].

   mailbox_list    ::= 1#mailbox_URL
   mailbox_URL     ::= ???
                       ;; relative URL -- see [IMAPURL]
                       ;; may contain list_wildcards
   searchm         ::= "SEARCHM" SPACE search_name
                                 SPACE "(" search_options ")"
                                 SPACE "(" mailbox_list ")"
                                 SPACE "(" search_criteria ")"
   search_criteria ::= ["CHARSET" SPACE astring SPACE] 1#search_key
   search_name     ::= string
   search_option   ::= "DEPTH(" number ")"
   search_options  ::= 0#search_option
                       ;; a given option may only appear once

6. Security Considerations

   This document describes an IMAP4 command similar to the SEARCH
   command, and has the same security considerations as that command. 
   Those considerations are described in [IMAP].

7. References

   [IMAP]; Crispin, M.; "Internet Message Access Protocol - Version
   4rev1"; RFC 2060; University of Washington; December 1996.

   [IMAPURL]; Newman, C.; "IMAP URL Scheme"; RFC 2192; Innosoft;
   September 1997.

   [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate

B. Leiba                  Expires August 2001                  [Page 3]

Internet DRAFT    IMAP4 SEARCHM for Multiple Mailboxes     February 2001

   Requirement Levels"; RFC 2119; Harvard University; March 1997.

8. Author's Address

   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532

   Phone: 1-914-784-7941
   Email: [email-masked]

B. Leiba                  Expires
August 2001                  [Page 4]

--==========290856023==========--

Date: Sat, 24 Feb 2001 02:51:55 -0500
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: draft-leiba-imap-search-multiple-00.txt
Sender: [email-masked]

I've just submitted the attached draft to the I-D editor.  May we discuss
it here?  I think it's out of the working group's charter, unless Pete
thinks it should be in, and so I submitted it as an individual draft.  But
since the IMAP mailing list is almost useless now, having turned into the
UW-IMAP implementation discussion mailing list, I hope the WG Chair won't
mind our discussing it here.

It proposes a SEARCHM command that allows a few things:
1. named searches, so a client may have multiple SEARCHM commands pending
at once, and can relate the responses to the search that caused them,
2. the ability to search multiple mailboxes in one command, and
3. the ability to use mailbox URLs to name the mailboxes.

In order to get it out in time, I didn't specify a few things that I do
want to specify in an update, so I'll outline them here.

First, I'm looking for whether we want to put the "mailbox name/list in URL
format" syntax into the "list extensions" draft, as we're currently
planning (I plan to have an update to that, incorporating the discussion
leading up to and in San Diego, next week), or whether we want to pull it
out as a separate draft and refer to it in both list extensions and SEARCHM.

Second, I want to be clear that the ability to search multiple mailboxes,
and, in particular, the use of wildcards, can be hazardous.  I intend to
add words indicating that a server MAY (SHOULD?) limit the number of
mailboxes that may be searched with one command, and, in fact, that the
server SHOULD reject the specification of "*".  The intent here is more to
allow a search like "inbox/*" to search a mailbox and its sub-mailboxes.
Of course, that can still get weird -- for instance, searching
"#news.alt.*" -- and therefore the server MAY/SHOULD limit it.  So I'm
looking for opinions here on what to say and how to say it.

Finally, I'm particularly looking for feedback from the client developers
about whether this is something you'd use.  For server developers, remember
that a client *can* currently do this with a series of SELECT and SEARCH
commands, and this is an attempt to be more efficient about it, and,
especially, to be easier on lightweight clients.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Fri, 23 Feb 2001 17:51:24 -0800
To: Cyrus Daboo <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: So, do we meet?
Sender: [email-masked]

At 11:17 AM -0500 2/23/01, Cyrus Daboo wrote:

>
>  draft-ietf-imapext-regex-00.txt
>   Status?

I'd like to get an update out, but I may not be able to do so 
before the deadline.

Also, I'm still waiting to hear if I can attend.  (If not, this 
will be the first I've missed a long time.)  Right now it doesn't 
look good.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Nice guys finish last, but we get to sleep in.  --Evan Davis

Date: Fri, 23 Feb 2001 16:08:20 -0800
From: Chris Newman <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Mark Crispin <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Friday, February 23, 2001 15:01 -0800 Mark Crispin 
<[email-masked]> wrote:
> Whether or not "a windowing facility is absolutely necessary" is a matter
> of opinion.  The need is speculative; it assumes the advent of a class of
> clients which will behave that way.

Obviously we can't force clients to write scalable implementations.  Plenty 
of clients still do a "FETCH 1:* <whatever>" regularly without need.  But 
as protocol designers it's our responsibility to make the protocol 
sufficent if a client chooses to support large mailboxes.

> I'm willing to work on the design of a windowing facility (and have), but
> not at the cost of forcing it upon unwilling implementations.

An acceptable compromise to me would be:

SORT/THREAD move onto the standards track at the same time as the windowing 
facility.  SORT/THREAD drafts should note the weakness they have with 
respect to scalability on the basis of mailbox size and include at least a 
non-normative reference to the windowing facility as a way to address the 
problem.

I believe that meets your requirement.

		- Chris

Date: Fri, 23 Feb 2001 16:09:51 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: So, do we meet?
To: Chris Newman <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 23 Feb 2001 15:11:57 -0800, Chris Newman wrote:
> >> draft-ietf-imapext-acl-01.txt
> >>   Status?
> I suggest the chair nag the document editor directly to get a revision out.

It was decided at San Diego that the document editor work with me to address
the concerns I've raised about the current ACL framework.  To date, this has
not happened.  I'll take some of the blame for this; but it's nevertheless
premature to talk about a revised document without determining the nature of
the revisions.

Date: Fri, 23 Feb 2001 15:13:26 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 23 Feb 2001 18:10:11 -0500, Lawrence Greenfield wrote:
> Windowing SORT seems to be simple, so can we do the simple thing and
> publish it?

The windowing facility must not forced into SORT:
 1) A client must not do a new SORT simply to move through the window.
 2) The dynamic update problem precludes windowing as part of an existing
    SEARCH-class command (SEARCH, SORT, and THREAD) because the input is
    dynamic.

Windowing must be through a static set.  Otherwise, you'll get inexplicable
user interface behavior because of an update happening underneath.  The result
will be a protocol feature that clients can't use but servers are forced to
implement anyway.

> The engineering problem left is coming up with windowing for THREAD.
> Unless this problem is intractable, we might as well solve it before
> publishing the THREAD document.

The three problems with putting windowing in THREAD are:
 1) the tree-address problem, unique to threading
 2) the new-THREAD simply to move through the window problem, shared by
     SEARCH and SORT
 3) the dynamic update problem, shared by SEARCH and SORT

What this indicates is that SORT and THREAD should be published now, and
windowing addressed separately in a way that addresses all known problems.  If
windowing is to happen, there should be a single form of windowing.  Not SORT
windowing that works differently from THREAD windowing because some people
wanted a quick-and-dirty solution for SORT and didn't want to think about
THREAD.

For example, a separate VIEW mechanism:
 1) can solve the tree-address problem if there is sober reflection upon what
     the windowing parameters are
 2) addresses the new SEARCH/SORT/THREAD just to move through the window
     problem, by having a preliminary "set view" operation
 3) addresses the dynamic update problem by having a static data set.

There is no need to rush through a windowing solution in order to get SORT and
THREAD published.  The only "need" is a fear that maybe windowing won't ever
happen unless it's piggy-backed on SORT and THREAD.  If windowing is as vital
as its supporters claim, then windowing will happen even if SORT and THREAD
are published first.

I object to kludges being hammered through in a rush for a partial solution,
particularly if the kludge is shoehorned into an orthogonal mechanism.

Date: Fri, 23 Feb 2001 15:11:57 -0800
From: Chris Newman <[email-masked]>
Subject: Re: So, do we meet?
To: Mark Crispin <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Friday, February 23, 2001 13:01 -0800 Mark Crispin 
<[email-masked]> wrote:
>> draft-crispin-imapv-14.txt
>>   Base-spec bug fixes. Last call 4-Jan-2001. Presumably this can now move
>> forward, or have there been corrections that require it to be re-issued?
>
> I wish that I knew the answer to this, although this isn't an IMAPEXT
> issue. Every time we talk about putting it forward, some specious issue
> comes up that kicks it back.

I'd prefer to see the vagueness of the 8-bit issue and 822 compliance 
clarified, particularly if we're planning to move in the direction of UTF-8 
headers in the future.  But I could live with deferring that clarification 
to the draft standard revision since this is just a recycle at proposed 
status.  Also, since it's an individual submission Mark can just ask for a 
4-week last call if he thinks it's ready.

>> draft-crispin-imap-multiappend-03.txt
>>   Last call 4-Jan-2001. Status?
>
> Can we clear this from the table by unanimous consent to move it forward,
> on the grounds that there are multiple client/server implementations and
> no stated reasons for not doing so?

I just read it.  Looks ready to move to me.  Mark, why don't you just send 
email to the ADs and [email-masked] asking for a 4-week last call?

>> draft-ietf-imapext-sort-06.txt
>> draft-ietf-imapext-thread-06.txt
>> draft-ietf-imapext-view-00.txt
>>   There are now multiple client/server implementations of sort and thread
>> and more people looking to add these to their implementations. Its
>> therefore important we get some kind of consensus on these moving
>> forward. Also, I'm still unsure as to what other people really want from
>> VIEW. There's hasn't been much feedback after my last post.
>
> The lack of feedback strongly suggests to me that we should move forward
> on SORT and THREAD, and let VIEW languish until/unless there is sufficient
> interest.

I'm very uncomfortable moving SORT and THREAD forward without a facility to 
provide scalability on the basis of mailbox size (e.g., windowing).  If the 
rest of the WG wants to move them forward, I won't block rough concensus 
but I will express my concerns to the IESG during last call.

>> draft-ietf-imapext-acl-01.txt
>>   Status?

I suggest the chair nag the document editor directly to get a revision out.

		- Chris

Date: Fri, 23 Feb 2001 15:01:01 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Chris Newman <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 23 Feb 2001 14:50:44 -0800, Chris Newman wrote:
> After having done the engineering exercise, I concur with Mark that we
> shouldn't bother with dynamic update.  The complexity it creates doesn't
> seem to be worth the benefit.

This was the conclusion at the last IETF in San Diego.  I'm actually neutral
about dynamic updating, but accepted that decision.

> A windowing facility is absolutely necessary.  Particularly if we don't do
> the dynamic update facility, then the mechanism the client will use to
> update its view is to re-issue the SORT/THREAD operation.  That makes it
> especially important for scalability by mailbox size that the client gets
> only what it needs rather than information for the entire mailbox.

Whether or not "a windowing facility is absolutely necessary" is a matter of
opinion.  The need is speculative; it assumes the advent of a class of clients
which will behave that way.

I'm willing to work on the design of a windowing facility (and have), but not
at the cost of forcing it upon unwilling implementations.

Date: Fri, 23 Feb 2001 18:10:11 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: VIEW was Re: Progress? Meeting?
Sender: [email-masked]

   Date: Fri, 23 Feb 2001 14:50:44 -0800
   From: Chris Newman <[email-masked]>

   After having done the engineering exercise, I concur with Mark that we 
   shouldn't bother with dynamic update.  The complexity it creates doesn't 
   seem to be worth the benefit.

   A windowing facility is absolutely necessary.  Particularly if we don't do 
   the dynamic update facility, then the mechanism the client will use to 
   update its view is to re-issue the SORT/THREAD operation.  That makes it 
   especially important for scalability by mailbox size that the client gets 
   only what it needs rather than information for the entire mailbox.

I agree with this.  

Windowing SORT seems to be simple, so can we do the simple thing and
publish it?

The engineering problem left is coming up with windowing for THREAD.
Unless this problem is intractable, we might as well solve it before
publishing the THREAD document.

Larry

Date: Fri, 23 Feb 2001 14:50:44 -0800
From: Chris Newman <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

After having done the engineering exercise, I concur with Mark that we 
shouldn't bother with dynamic update.  The complexity it creates doesn't 
seem to be worth the benefit.

A windowing facility is absolutely necessary.  Particularly if we don't do 
the dynamic update facility, then the mechanism the client will use to 
update its view is to re-issue the SORT/THREAD operation.  That makes it 
especially important for scalability by mailbox size that the client gets 
only what it needs rather than information for the entire mailbox.

A 1 hour meeting might be helpful.

		- Chris

Date: Fri, 23 Feb 2001 13:01:00 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: So, do we meet?
To: Cyrus Daboo <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 23 Feb 2001 11:17:12 -0500, Cyrus Daboo wrote:
> My vote is yes. Maybe we only need a one hour session rather than two?

Is it worth meeting if it's only a one-hour session?  Specifically, what
business do we need to do face-to-face (obviously it isn't much if only an
hour is needed), and does it need to be attended to at this IETF or can it be
deferred to the next one?

> draft-crispin-imapv-14.txt
>   Base-spec bug fixes. Last call 4-Jan-2001. Presumably this can now move
> forward, or have there been corrections that require it to be re-issued?

I wish that I knew the answer to this, although this isn't an IMAPEXT issue.
Every time we talk about putting it forward, some specious issue comes up that
kicks it back.

> draft-crispin-imap-multiappend-03.txt
>   Last call 4-Jan-2001. Status?

Can we clear this from the table by unanimous consent to move it forward, on
the grounds that there are multiple client/server implementations and no
stated reasons for not doing so?

> draft-ietf-imapext-sort-06.txt
> draft-ietf-imapext-thread-06.txt
> draft-ietf-imapext-view-00.txt
>   There are now multiple client/server implementations of sort and thread
> and more people looking to add these to their implementations. Its
> therefore important we get some kind of consensus on these moving forward.
> Also, I'm still unsure as to what other people really want from VIEW.
> There's hasn't been much feedback after my last post.

The lack of feedback strongly suggests to me that we should move forward on
SORT and THREAD, and let VIEW languish until/unless there is sufficient
interest.

> draft-ietf-imapext-acl-01.txt
>   Status?

I never was contacted.  My proposed solution leverages on the LIST extensions
work.

Date: Fri, 23 Feb 2001 12:07:08 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: So, do we meet?
Sender: [email-masked]

Cyrus Daboo wrote:

> --On Friday, February 23, 2001 09:35:37 AM -0600 Pete Resnick
> <[email-masked]> wrote:
>
> > OK, the deadline approaches. I have heard several people say they should
> > have drafts ready. Am I to believe from that we will have things to
> > discuss?
> >
> > Shall we meet in Minneapolis? Yay or nay?
>
> My vote is yes.

I am second to say yes.

> Maybe we only need a one hour session rather than two?
>
> There are a number of drafts that are close to last call status IMHO - some
> of them aren't strictly in our charter but we are marshalling them through,
> right. It would be good to have a summary of all the drafts in progress and
> their current status so we can see where we're going with them.
>
> Here's my summary of all IMAP related drafts:
>
> draft-crispin-imapv-14.txt
>   Base-spec bug fixes. Last call 4-Jan-2001. Presumably this can now move
> forward, or have there been corrections that require it to be re-issued?
>
> draft-crispin-imap-multiappend-03.txt
>   Last call 4-Jan-2001. Status?
>
> draft-ietf-imapext-sort-06.txt
> draft-ietf-imapext-thread-06.txt
> draft-ietf-imapext-view-00.txt
>   There are now multiple client/server implementations of sort and thread
> and more people looking to add these to their implementations. Its
> therefore important we get some kind of consensus on these moving forward.
> Also, I'm still unsure as to what other people really want from VIEW.
> There's hasn't been much feedback after my last post.
>
> draft-ietf-imapext-annotate-00.txt
>   Randy's working on an update.
>
> draft-ietf-imapext-acl-01.txt
>   Status?
>
> draft-ietf-imapext-regex-00.txt
>   Status?
>
> draft-ietf-imapext-list-extensions-00.txt
>   Status?
>
> draft-nerenberg-imap-binary-02.txt
>   New draft posted 15-Feb-2001
>
> draft-melnikov-imap-mdn-03.txt
>   Status?

I would like to publish it as Informational or BCP. It is probably time for
Last Call.

I've just submitted a new draft ietf-melnikov-imap-condstore-00.txt. It should
appear in draft repository shortly.

I've also submitted a new revision of LANGUAGE draft (I am co-author now).

Alexey

Date: Fri, 23 Feb 2001 11:17:12 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: So, do we meet?
Sender: [email-masked]

--On Friday, February 23, 2001 09:35:37 AM -0600 Pete Resnick 
<[email-masked]> wrote:

> OK, the deadline approaches. I have heard several people say they should
> have drafts ready. Am I to believe from that we will have things to
> discuss?
>
> Shall we meet in Minneapolis? Yay or nay?

My vote is yes. Maybe we only need a one hour session rather than two?

There are a number of drafts that are close to last call status IMHO - some 
of them aren't strictly in our charter but we are marshalling them through, 
right. It would be good to have a summary of all the drafts in progress and 
their current status so we can see where we're going with them.

Here's my summary of all IMAP related drafts:

draft-crispin-imapv-14.txt
  Base-spec bug fixes. Last call 4-Jan-2001. Presumably this can now move 
forward, or have there been corrections that require it to be re-issued?

draft-crispin-imap-multiappend-03.txt
  Last call 4-Jan-2001. Status?

draft-ietf-imapext-sort-06.txt
draft-ietf-imapext-thread-06.txt
draft-ietf-imapext-view-00.txt
  There are now multiple client/server implementations of sort and thread 
and more people looking to add these to their implementations. Its 
therefore important we get some kind of consensus on these moving forward. 
Also, I'm still unsure as to what other people really want from VIEW. 
There's hasn't been much feedback after my last post.

draft-ietf-imapext-annotate-00.txt
  Randy's working on an update.

draft-ietf-imapext-acl-01.txt
  Status?

draft-ietf-imapext-regex-00.txt
  Status?

draft-ietf-imapext-list-extensions-00.txt
  Status?

draft-nerenberg-imap-binary-02.txt
  New draft posted 15-Feb-2001

draft-melnikov-imap-mdn-03.txt
  Status?

-- 
Cyrus Daboo

Date: Fri, 23 Feb 2001 09:35:37 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: So, do we meet?
Sender: [email-masked]

OK, the deadline approaches. I have heard several people say they 
should have drafts ready. Am I to believe from that we will have 
things to discuss?

Shall we meet in Minneapolis? Yay or nay?

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Wed, 21 Feb 2001 16:59:17 -0800
From: Chris Newman <[email-masked]>
Subject: binary draft and APPEND
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Thursday, February 15, 2001 14:22 -0700 Lyndon Nerenberg 
<[email-masked]> wrote:
> This memo defines the BINARY extension to the Internet Message
> Access Protocol [IMAP4rev1].  It provides a mechanism for IMAP4
> clients and servers to exchange data encoded with the MIME BINARY
> content-transfer-encoding.

I disagree with section 4.4 of this draft on the grounds that it breaks 
backwards compatibility with IMAP clients that are not binary aware.

RFC 2060 section 4.3.1 states "Implementations MUST encode binary data into 
a textual form such as BASE64 before transmitting the data."  I interpret 
this to mean that any RFC 2060 server implementation which receives a 
"binary" body part must behave as if it were downconverted to "base64" CTE 
with respect to BODYSTRUCTURE and FETCH commands.  Arguably this only 
applies if the body part with a "binary" Content-Transfer-Encoding is 
"binary" by the IMAP definition (contains a NUL or excessive CTL 
characters).

I would say:

(1) If the client does a BINARY fetch of a message it stored with a binary 
APPEND, the message MUST be unchanged.  (A "SHOULD" would be acceptable, 
but I prefer "MUST").

(2) If the client does a BODY fetch of a message it stored with a binary 
APPEND, any body parts which had a binary CTE MUST be returned using a 
content-transfer-encoding such as base64 if necessary to comply with 
section 4.3.1 of RFC 2060.

No statement should be made about the message store capabilities.  Both 
implementations (a binary message store which does base64 conversion for 
BODY fetches, or a non-binary message store which removes base64/QP for 
BINARY fetches) are valid, IMHO.

I'm not fond of BINARYSTRUCTURE.  It results in two syntatically identical 
complex FETCH items with subtle semantic differences, neither of which 
necessarily reflect the real bodystructure of the message in the store.  It 
could mislead a client to believe a part had a binary CTE when it was 
originally delivered to the store with a base64 CTE.  If such a body part 
were in a multipart/signed, there's a serious problem.  As a 
counter-proposal, I suggest a fetch item BINARYSIZES, which returns a list 
of "body part section id", "body part size after CTE removed" pairs.

		- Chris

From: "Eric Burger" <[email-masked]>
To: "Lyndon Nerenberg" <[email-masked]>, "Pete Resnick" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Progress? Meeting? 
Date: Wed, 21 Feb 2001 11:28:38 -0500
Importance: Normal
Sender: [email-masked]

I know we need CHANNEL, so I wouldn't mind if the WG takes it up...

> -----Original Message-----
[snip]
> CHANNEL is taking longer than I hoped. I'll have *something* out in
> time for IETF50, and I fully expect there will be discussion on it, but
> the mailing list should be fine (i.e. we don't need WG meeting time).
> Again, the issue of WG charter is up in the air, though. Is the WG
> going to adopt CHANNEL (and BINARY) or not?
> 
> --lyndon

Date: Tue, 20 Feb 2001 17:14:47 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: VIEW was Re: Progress? Meeting?
To: Cyrus Daboo <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 20 Feb 2001 20:07:52 -0500, Cyrus Daboo wrote:
> Is there really ANY interest in the VIEW mechanism at all, or should we
> just add the equivalent functionality directly into SORT and THREAD as
> needed?

My opinion has always been that the functionality is a solution in search of a
problem, presented by people who have little or no practical experience with
server-based sorting and threading.

If there is any interest in the functionality, then it must be in its own
mechanism.  It's a fantasy to believe that adding it to SEARCH, SORT, and
THREAD directly will accomplish windowing of results; each subsequent command
will change the data in unpredictable ways which will break windowing.

Sure, you want updates, but it is vitally important to update and window
independently.  Otherwise, you get client behavior that would suck so badly
that it would kill SORT and THREAD for everybody.

The necessary parts of VIEW is:
 1) a command to set the view -- that is, to load the message set used by the
    other commands
 2) a command to window through the view.
 3) a command to update the VIEW.

Part (2) needs more than "first position to return and number of results to
return".  You need some form of "window including message <n>, positioned <m>
lines from the top [or bottom]".  The functionality is useless without this.

Part (3) is what has everybody hung up.  Updating the view can be as basic an
opportunity as doing (1) over again and tossing out what you knew before.  A
more advanced implementation of (3) would have "insertion" and "removal"
operators.

I suspect that "simple is better".  Since SORT and THREAD are SEARCH-class
commands, untagged EXPUNGE can't happen during SORT/THREAD.  So, a static VIEW
(that requires a new VIEW-set to update) is viable.  It's probably better to
stick with that position for now, and add fancier stuff later.

Date: Tue, 20 Feb 2001 20:07:52 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: VIEW was Re: Progress? Meeting?
Sender: [email-masked]

--On Monday, February 19, 2001 02:22:30 PM -0600 Pete Resnick 
<[email-masked]> wrote:

> I have seen little progress on this list on WG documents since the last
> meeting. Do we need to meet at Minneapolis? What progress is being made?
>

With regards to VIEW, I've been trying to figure out the best way to revise 
it in light of the comments in San Diego. As I recollect we decided that 
VIEW is too complicated and that a lightweight solution to windowing for 
SORT/THREAD is a better approach.

Having implemented support for SORT/THREAD in Mulberry after that meeting, 
here is what I see as important for VIEW (please comment):

1) Windowing of results from SORT/THREAD/SEARCH commands.
2) Mechanism to allow quick discovery of the position of new messages in 
the SORT/THREAD order.

(1) Can be implemented with a simple command modifier for the 
SORT/THREAD/SEARCH commands that allows the client to specify the window 
for the results:

a VIEW WINDOW 10 100 SORT SUBJECT SEARCH UNSEEN

The first number is the first position to return, the second number the 
number of results to return. This may require some specialisation to cope 
with the hierarchical nature of thread results.

(2) is somewhat harder, but I see it as important for removing the need to 
re-issue full/partial sorts just to get the positions of new messages. I'm 
not sure what the best approach is here. Given that the thread structure 
can change significantly with the arrival of a new message it might be 
better to apply this only to SORT. In which case a SORT2 command might be 
better than trying to come up with some mechanism based on VIEW.

Are there any thoughts on this?

Is there really ANY interest in the VIEW mechanism at all, or should we 
just add the equivalent functionality directly into SORT and THREAD as 
needed?

-- 
Cyrus Daboo

From: Lyndon Nerenberg <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Progress? Meeting? 
Organization: ACI / MessagingDirect
Date: Tue, 20 Feb 2001 14:10:59 -0700
Sender: [email-masked]

Pete Resnick wrote:

> I have seen little progress on this list on WG documents since the
> last meeting. Do we need to meet at Minneapolis? What progress is
> being made?

BINARY came out a couple of days ago. I haven't heard anything about
getting it issued as a WG document. Unless something major jumps out
I don't see a need for another draft, so I don't think this really
matters. (Modulo some editorial changes I think the draft is ready
for last call.)

CHANNEL is taking longer than I hoped. I'll have *something* out in
time for IETF50, and I fully expect there will be discussion on it, but
the mailing list should be fine (i.e. we don't need WG meeting time).
Again, the issue of WG charter is up in the air, though. Is the WG
going to adopt CHANNEL (and BINARY) or not?

--lyndon

Date: Tue, 20 Feb 2001 13:51:13 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Progress? Meeting?
Sender: [email-masked]

Pete Resnick wrote:

> I have seen little progress on this list on WG documents since the
> last meeting. Do we need to meet at Minneapolis? What progress is
> being made?

Give me few days to submit MODTIME (conditional store) draft.

Alexey

Date: Tue, 20 Feb 2001 12:15:08 -0800
To: Pete Resnick <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: Progress? Meeting?
Sender: [email-masked]

I'm trying to get an updated Annotations draft done shortly.

Date: Mon, 19 Feb 2001 14:22:30 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Progress? Meeting?
Sender: [email-masked]

I have seen little progress on this list on WG documents since the 
last meeting. Do we need to meet at Minneapolis? What progress is 
being made?

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

From: Edward Hibbert <[email-masked]>
To: [email-masked]
Subject: Extending STATUS command?
Date: Mon, 19 Feb 2001 18:41:58 -0000
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C09AA3.A3B32FB0
Content-Type: text/plain;
	charset="iso-8859-1"

We have a requirement to expose the number of Urgent messages in a folder to
a custom IMAP client.  Now, I know that "Urgent" isn't necessarily a
well-defined concept - but that's ok as long the concept on my server is the
same as the custom client.

So, what I'm looking for is advice on is the best way of exposing this info.
My current leanings are towards extending the STATUS command to allow an
extra data item to be requested (in RFC2060 6.3.10 it says "the currently
defined STATUS data items are..." and gives an exhaustive list), because
that fits best with the processing that the client is doing at the time - it
would be more efficient for my server than forcing the client to do a SELECT
and SEARCH.  It also seems to fit with the existing MESSAGES, RECENT and
UNSEEN data items.

To do this properly, I guess I would produce an extension which publicised
the server's ability to accept this extra data item in STATUS, though I
could put my conscience to one side and assume that nobody else is going to
ask for it :-).

Do any of you have any advice or other suggestions for how to implement
this?

Edward Hibbert 
Internet Applications Group 
Data Connection Ltd 
Tel:    +44 131 662 1212                Fax:    +44 131 662 1345 
Email:  eh <mailto:[email-masked]> @dataconnection.com   Web:
http://www.dat <http://www.dat> aconnection.com 

------_=_NextPart_001_01C09AA3.A3B32FB0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<P><FONT color=#ff00ff><FONT size=2><FONT face=Arial>We have a requirement to 
expose the number of Urgent messages in a folder to a custom IMAP client.&nbsp; 
Now, I know that "Urgent" isn't necessarily a well-defined concept - but that's 
ok as long the concept on my server is the same as the custom client.<BR><BR>So, 
what I'm looking for is advice on is the best way of exposing this info.&nbsp; 
My current leanings are towards extending the STATUS command to allow an extra 
data item to be requested (in RFC2060 6.3.10 it says "the currently defined 
STATUS data items are..." and gives an exhaustive list), because that fits best 
with the processing that the client is doing at the time - it would be more 
efficient for my server than forcing the client to do a SELECT and SEARCH.&nbsp; 
It also seems to fit with the existing MESSAGES, RECENT and UNSEEN data 
items.<BR><BR>To do this properly, I guess I would produce an extension which 
publicised the server's ability to accept this extra data item in STATUS, though 
I could put my conscience to one side and assume that nobody else is going to 
ask for it :-).<BR><BR>Do any of you have any advice or other suggestions for 
how to implement this?<BR></FONT><BR></FONT></FONT><FONT size=2><FONT 
color=#000000 face=Arial>Edward Hibbert</FONT> <BR><FONT color=#000000 
face=Arial>Internet Applications</FONT> <FONT color=#000000 
face=Arial>Group</FONT> <BR><U><FONT color=#000000 face=Arial>Data Connection 
Ltd</FONT></U> <BR><FONT color=#000000 face=Arial>Tel:&nbsp;&nbsp;&nbsp; 
+44</FONT> <FONT color=#000000 face=Arial>131 662 
1212</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT color=#000000 
face=Arial>Fax:&nbsp;&nbsp;&nbsp; +44</FONT> <FONT color=#000000 face=Arial>131 
662 1345</FONT> <BR><FONT color=#000000 face=Arial>Email:&nbsp;</FONT> <FONT 
color=#000000 face=Arial><A href="mailto:[email-masked]">eh</FONT><FONT 
color=#000000 face=Arial>@dat</FONT><FONT color=#000000 
face=Arial>aconnection.com</A></FONT>&nbsp;&nbsp; <FONT color=#000000 
face=Arial>Web</FONT><FONT color=#000000 
face=Arial>:</FONT>&nbsp;&nbsp;&nbsp;<U> <FONT color=#0000ff face=Arial><A 
href="http://www.dat" target=_blank>http://www.dat</A></FONT><FONT color=#0000ff 
face=Arial>aconnection.com</FONT></U> </FONT></P></BODY></HTML>

------_=_NextPart_001_01C09AA3.A3B32FB0--

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-nerenberg-imap-binary-02.txt (fwd)
Organization: ACI / MessagingDirect
Content-Description: IMAP Binary draft v2
Date: Thu, 15 Feb 2001 14:22:14 -0700
Sender: [email-masked]

Delivery-Date: Thu Feb 15 13:36:32 2001
To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nerenberg-imap-binary-02.txt
Date: Thu, 15 Feb 2001 06:47:03 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 Binary Content Extension
	Author(s)	: L. Nerenberg
	Filename	: draft-nerenberg-imap-binary-02.txt
	Pages		: 7
	Date		: 14-Feb-01
	
This memo defines the BINARY extension to the Internet Message
Access Protocol [IMAP4rev1].  It provides a mechanism for IMAP4
clients and servers to exchange data encoded with the MIME BINARY
content-transfer-encoding.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nerenberg-imap-binary-02.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-nerenberg-imap-binary-02.txt".

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-nerenberg-imap-binary-02.txt

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

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

--OtherAccess--

--NextPart--

From: Lyndon Nerenberg <[email-masked]>
To: "Eric Burger" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: newmail notification protocol 
Organization: ACI Worldwide - MessagingDirect
Date: Tue, 13 Feb 2001 14:41:30 -0700
Sender: [email-masked]

> I'm wondering if defining a profile for the SIP message waiting protocol
> (draft-mahy-sip-message-waiting-01.txt) wouldn't be a better approach.
> 
> On the one hand, the IMAP server and biff client would only need to
> implement a VERY small subset of SIP.

An interesting idea. A quick scan of the draft makes me think this might
work, although it would be restricted to the email case only.

> In addition, more and more firewalls are SIP-friendly, so you could use UDP
> (although TCP's an option).

You need authentication in there, otherwise people would be able to
use the SIP service to probe your IMAP server namespace. Since IMAP
uses SASL you'll have to provide at least the same level of security
in SIP as the corresponding IMAP server. This will require some
investigation.

> Work to be done in this case would be on the event profile for subscribing
> to a particular IMAP folder.  That said, that work probably needs to be done
> anyway for the SIP MWI draft.

Do you want to put up a strawman? While I like SINs generality, the
immediate need is clearly for email, and if an existing protocol can
provide the functionality in a light-weight manner, I'm all for it.

--lyndon

Date: Tue, 13 Feb 2001 12:55:33 -0800
From: Chris Newman <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: newmail notification protocol
Sender: [email-masked]

A few suggestions:

(1) Call it "Mail Check Protocol" (or similar) rather than "Simple Internet 
Notifications" and merge the two documents.  The chances of getting a 
generic notification protocol through the IETF process given the current 
furor over instant messaging is very low.  Don't repeat the political 
mistake we made when we generalized IMSP to ACAP.  Focus only on the 
problem you need to solve, generalization can come later.

(2) Use URLs to represent the objects.  Creating a new namespace is always 
problematic -- look at all the mistakes we made in IMAP namespaces.  URLs 
are a fairly well understood namespace with known problems and provide 
plenty of room for extensibility.  There is already a defined syntax for 
POP and IMAP URLs so you can leverage that work.  You can provide a base 
URL in the greeting if you
want to keep the object names shorter.  Besides, I don't consider it 
desirable to let IMAP modified UTF-7 leak outside the IMAP protocol itself 
and IMAP URLs already solve that problem.

(3) Please rename "EXIT" to "BYE".  No need for gratuitous differences from 
IMAP and it's always nice if all the responses have different first letters 
:-).

(4) Is there some reason you only allow one profile?  If I were monitoring 
for both new mail and an address book, I might want multiple profiles.

Otherwise this looks pretty good from a cursory review.

		- Chris

From: Lyndon Nerenberg <[email-masked]>
To: Pete Maclean <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: newmail notification protocol 
Organization: ACI Worldwide - MessagingDirect
Date: Tue, 13 Feb 2001 12:36:26 -0700
Sender: [email-masked]

> Do you mean to exclude the possibility that other events MAY generate an 
> EVENT event notification?

Yes. If you want more that just newmail you would define a new
application profile for that.

> I see there bring value in a more granular specification of events.  One 
> client might, for example, be interested only in the introduction of an 
> unread message while another, say one that maintains a replica of the 
> folder, might want to know about any old change at all.  Is there an 
> intention to specifically not go to this level of detail?

Yes, that's the intention. SIN is meant to be SIMPLE. It's also meant
very specifically to NOT duplicate functionality available elsewhere.
The typical IMAP scenario as I see it is:

1. MUA connects via IMAP, does folder discovery, builds a list of
  interesting folders.
2. MUA connects via SIN, registers WATCHes on the interesting folders,
  then closes the IMAP channels (most IMAP channels, anyway).
3. SIN reports an EVENT on a folder
4. MUA decides if it wants further info, and issues IMAP commands as
  required (possibly opening new IMAP connections)

In this context, SIN is a "helper" protocol. My expectation is that
SIN engines would be imbedded into applications along side other
"primary" protocols. This is why I'm rather adamant about not overloading
SIN with anything more than simple "something happened" functionality.
If you want more than that, we already have SNMP.

> It seems to me that notifications relating to the Inbox might valuably be 
> excluded since IMAP demands that such a folder exist.  This would allow the 
> possibility of monitoring an Inbox without the overhead of providing a 
> password.

No, this would allow for authentication namespace discovery by
unauthorized people.

> Do you think it would make any sense to extend the protocol to check for 
> changes that occurred prior to the SIN session?  Perhaps to obtain the time 
> that the last change was made to a folder?

I did, briefly, and decided against it. Again, this is functionality that
can be accomplished outside of SIN. (In the IMAP example above, this would
happen during step 1.)

The fundamental concept of the protocol is: simple simple simple. If I
cannot hold your feet to the fire for five minutes as you justify each
piece of the protocol (and profile), it should be thrown out. We already
have a fine assortment of bloated protocols to chose from.

--lyndon

Date: Tue, 13 Feb 2001 11:10:20 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Bounced mail to this list
Sender: [email-masked]

A flurry of legitimate mail sent to this list was bounced due to the 
"only subscribers can post" rules. If you respond to any of these, 
please change the subject line of this message.

--Paul Hoffman

>From owner-ietf-imapext  Tue Feb 13 07:43:22 2001
Date: Tue, 13 Feb 2001 10:42:38 -0500
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
From: Pete Maclean <[email-masked]>
Subject: Re: newmail notification protocol
Cc: [email-masked]

  >> 4.3.  Conjestion Control

Surely you gest!

Sorry, I just could not resist that.

Pete

>From owner-ietf-imapext  Tue Feb 13 08:10:05 2001
Date: Tue, 13 Feb 2001 11:09:29 -0500
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
From: Pete Maclean <[email-masked]>
Subject: Re: newmail notification protocol
Cc: [email-masked]

I have a couple of questions about the IMAP4 Application Profile.

>6. Event Triggers
>
>       Introduction of any message into a monitored object (folder) MUST
>       generate an EVENT event notification.

Do you mean to exclude the possibility that other events MAY generate an
EVENT event notification?

I see there bring value in a more granular specification of events.  One
client might, for example, be interested only in the introduction of an
unread message while another, say one that maintains a replica of the
folder, might want to know about any old change at all.  Is there an
intention to specifically not go to this level of detail?

>7. Security Considerations
>
>       Servers MUST perform all operations in the security context of the
>       authenticated entity. Servers MUST NOT expose any information about
>       the IMAP4 folder namespace that would not be available if the same
>       credentials were used to connect to the IMAP4 server.
>
>       Servers MUST NOT send notification events (including LOST
>       responses) for a folder unless the authentication and authorization
>       credentials used for the SIN session, if used to connect to the
>       IMAP4 server, would allow a successful IMAP4 SELECT on that folder.

It seems to me that notifications relating to the Inbox might valuably be
excluded since IMAP demands that such a folder exist.  This would allow the
possibility of monitoring an Inbox without the overhead of providing a
password.

Do you think it would make any sense to extend the protocol to check for
changes that occurred prior to the SIN session?  Perhaps to obtain the time
that the last change was made to a folder?

Pete Maclean

>From owner-ietf-imapext  Tue Feb 13 09:45:26 2001
To: "Eric Burger" <[email-masked]>
Cc: "Lyndon Nerenberg" <[email-masked]>, <[email-masked]>,
         <[email-masked]>, <[email-masked]>
Subject: Re: newmail notification protocol
From: Simon Josefsson <[email-masked]>
("Eric Burger"'s message of "Tue, 13 Feb 2001 11:36:47 -0500")
Date: 13 Feb 2001 18:45:21 +0100
Message-ID: <[email-masked]>
Lines: 28
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/21.0.97
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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

>  I'm wondering if defining a profile for the SIP message waiting protocol
>  (draft-mahy-sip-message-waiting-01.txt) wouldn't be a better approach.
>
>  On the one hand, the IMAP server and biff client would only need to
>  implement a VERY small subset of SIP.

IMHO both solutions are very useful and welcome, as they serve
different audiences.

For full-blown IMAP clients, having notifications of new mail inside
IMAP is less prone to inconsistent/delayed/duplicated notifications,
and also more efficient.  Using notifications rather than polling [1]
increases performance alot (it would solve the biggest bottleneck in
my client).

For simple biff tools, notifications should preferably not require
complete IMAP implementations (but most biff tools today probably do
implement IMAP because of lack of a notification protocol) and would
be better handled in a separate protoocl.  (Which I assume SIP is,
altough I'm not familiar with SIP.)

Notes: [1] Yes, I know the client could open a IMAP connection for
each mailbox it want to monitor, but it doesn't scale very well.  I
have ~500 personal mailboxes that each receive new mail, not to
mention all shared mailboxes I want to monitor.  Notifications would
be very useful for me.

From: "Eric Burger" <[email-masked]>
To: "Lyndon Nerenberg" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: newmail notification protocol
Date: Tue, 13 Feb 2001 11:36:47 -0500
Importance: Normal
Sender: [email-masked]

I'm wondering if defining a profile for the SIP message waiting protocol
(draft-mahy-sip-message-waiting-01.txt) wouldn't be a better approach.

On the one hand, the IMAP server and biff client would only need to
implement a VERY small subset of SIP.

On the other hand, the IMAP server would only need to track client request
state, instead of keeping open a connection for the duration of the request.
In addition, more and more firewalls are SIP-friendly, so you could use UDP
(although TCP's an option).

Work to be done in this case would be on the event profile for subscribing
to a particular IMAP folder.  That said, that work probably needs to be done
anyway for the SIP MWI draft.

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: newmail notification protocol
Date: Mon, 12 Feb 2001 23:03:43 -0700
Sender: [email-masked]

This is a multipart MIME message.

--==_Exmh_11849420220
Content-Type: text/plain; charset=us-ascii

[ I apologise if you get multiple copies of this. I tried sending
  from my home address, but the list servers didn't like that I
  wasn't subscribed with that address. Although I'm re-sending this
  from my work address, this proposal isn't blessed by my employer. ]

Quite a while back (fall 1998) there was some discussion on the IMAP
lists about the need for a biff-like newmail notification protocol.
At the time I wrote down some ideas, but never got around to posting
anything back to the lists. While doing some laptop cleaning tonight
I found the skeleton drafts I had written up for myself. I've dusted
them off and attached them to this message for review. If the concept
looks useful I can clean them up and submit them as IDs. I also have
a profile suitable for use with POP, (and as a direct biff replacement).

Note: the protocol is designed to be useful for more than just e-mail
arrival notifications.

--lyndon

--==_Exmh_11849420220
Content-Type: text/plain ; name="draft-nerenberg-sin-framework.txt"; charset=us-ascii
Content-Description: draft-nerenberg-sin-framework.txt
Content-Disposition: inline; filename="draft-nerenberg-sin-framework.txt"

Network Working Group					Lyndon Nerenberg
Internet Draft: Simple Internet Notifications		 Orthanc Systems
Document: draft-nerenberg-sin-framework-xx.txt		   February 2001

		     Simple Internet Notifications

Status of this memo

     This document is an Internet Draft and is in full conformance with
     all provisions of Section 10 of RFC 2026.

     Internet Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet
     Drafts.

     Internet Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet Drafts
     as reference material or to cite them other than as "work in
     progress.rq

     The list of current Internet Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     A revised version of this draft document will be submitted to the
     RFC editor as a Proposed Standard for the Internet Community.
     Discussion and suggestions for improvement are requested.
     Distribution of this draft is unlimited.

0.  Administrivia

1.  Introduction

     Certain Internet services are interested in light-weight event
     notifications.  An example of this is a mail client monitoring a
     mailbox for new mail. The arrival of a message in the mailbox can
     be considered a delivery event. These events usually trigger
     actions in the client and server (in this example, a client receiv-
     ing a delivery event might download the message headers for display
     to the user). When events occur infrequently, clients and servers
     can spend long periods of time sitting idle waiting for an event to
     happen.  If the server implements a complex application or proto-
     col, considerable system resources can still be consumed by these
     idle servers (e.g.  physical memory, space in the memory backing
     store, process table entries, network buffers). In some cases, a
     significant reduction is resource consumption can be achieved by
     moving these notifications out of the primary protocol.

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 1]

Internet Draft	      Simple Internet Notifications	   February 2001

     Simple Internet Notifications (SIN) is a protocol framework for
     sending event notifications. SIN is application neutral, and very
     light-weight to allow minimal overhead implementations of both
     clients and servers.

2.  Conventions used in this document

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
     in this document are to be interpreted as described in [KEYWORD].

     The protocol syntax specifications use the Augmented Backus-Naur
     Form (ABNF) notation as specified in [ABNF].

3.  Terminology

     The following terms and abbreviations are used throughout this doc-
     ument:

     application profile
	     A specification describing how a SIN server interprets
	     the authentication and object namespaces, and the
	     events that will trigger an event notification, in the
	     context of a particular application service.

     application service
	     The application protocol or service upon whose behalf
	     the SIN server is providing event notifications.

     authentication namespace
	     The application profile-specific context within which a
	     SIN server interprets authentication identifiers.

     event notification
	     An EVENT or LOST response from the server.

     object
	     An entity upon which a WATCH can be placed.

     object namespace
	     The profile-specific context within which an SIN server
	     interprets object names.

     ignored object
	     A object for which the client does not wish to receive
	     event notifications, either implicitly or via an
	     IGNORE request.

     monitored object
	     An object for which the client has requested
	     event notifications via the WATCH command.

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 2]

Internet Draft	      Simple Internet Notifications	   February 2001

4.  Protocol Framework

     SIN defines a general framework for event notifications. This spec-
     ification does not describe the events that trigger an event noti-
     fication, nor does it describe the interpretation of object names
     or authentication identifiers.  Instead, these are described in
     application specific profile documents. As such, the SIN protocol
     specification MUST be used in conjunction with an application pro-
     file to fully specify the over-the-wire protocol implemented by a
     particular server instance.

     SIN servers do not listen at well known transport addresses.
     Clients are expected to discover the appropriate server transport
     address through out-of-band means. Application protocols and ser-
     vices using SIN SHOULD provide an application protocol mechanism
     for clients to discover the transport addresses of relevent SIN
     servers. (See [IMAP-SIN] for an example.)

4.1.  Application Profiles

     An application profile MUST specify the following components of a
     SIN server implementation:

       1) The semantics and interpretation of authentication identifiers
       2) The encoding and interpretation of object names
       3) The conditions that will trigger an event notification

     Application profiles SHOULD make recommendations to server imple-
     menters on ways the server can reduce the number of outstanding
     event notifications queued for transmission to conjested or blocked
     clients.

4.2.  Object Names

     Object names describe events to be monitored. SIN treats object
     names as opaque data. In SIN commands and responses, the object
     name is the sequence of octets beginning immediately after the com-
     mand or response delimiter and continuing up to, but not including,
     the CRLF line end delimiter. Thus,

	 EVENT foo

     and

	 EVENT	foo

     refer to two distinct objects -- the object name in the second
     example has a space as its first character. An application profile
     defining an object namespace that includes either of the ASCII CR
     or LF characters MUST define an encoding scheme that prevents the
     sequence CRLF from appearing in the object name.

     The application profile is responsible for defining how object

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 3]

Internet Draft	      Simple Internet Notifications	   February 2001

     names are interpreted by the client and server.

4.3.  Conjestion Control

     Event notifications are asynchronous. Clients MUST be prepared to
     accept event notifications at any time. Server implementers are
     cautioned that clients may not be able to accept event notifica-
     tions at the rate the server generates them, and MUST take precau-
     tions to ensure that protocol writes to a blocked client do not
     impair the servers ability to send timely event notifications to
     responsive clients. If a client becomes blocked for an extended
     period of time, servers MAY terminate the protocol session. In the
     absence of specific guidance from an application profile, servers
     SHOULD NOT terminate a blocked client session unless the client has
     been blocked for at least five minutes.

5.  Protocol Description

     A SIN session exists in one of two states: the initial state, and
     the authenticated state. During the initial state the server
     announces the application profile it is serving, and the authenti-
     cation mechanisms it supports. The client verifies that the appli-
     cation profile is the expected one, then authenticates itself to
     the server. After a successfull authentication the session switches
     to the authenticated state. The client is now able to register and
     unregister its interest in objects, and the server can send event
     notifications.

     SIN is a line based protocol. Client commands and server responses
     are CRLF terminated strings.  No explicit bounds are placed on line
     lengths.  Clients SHOULD be able to accept response lines of any
     length, and MAY terminate the session if the server sends responses
     the client is unable to cope with. In the event of occasional input
     buffer overflows, client implementers are encouraged to read and
     discard excess input data up to the CRLF line end. (This could hap-
     pen when a client downsizes an input buffer after issuing an IGNORE
     command, but the server hasn't sent all outstanding event notifica-
     tions pertaining to the now ignored object.)  Wherever practical,
     SIN application profiles SHOULD provide guidance on maximum line
     lengths for server responses.

     Client commands are issued in a synchronous lock-step fashion. Only
     one command can be outstanding at a time. In the authenticated
     state, event notifications can be issued while a command is out-
     standing, and clients MUST be prepared to accept these notifica-
     tions while awaiting the completion of an outstanding command.

     Protocol elements other than object names are case independent, and
     both servers and clients MUST recognize and interpret these in a
     case insensitive manner.

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 4]

Internet Draft	      Simple Internet Notifications	   February 2001

5.1.  Server Responses

     Server responses are of four types: synchronous, asynchronous, ban-
     ner, and authentication.  Synchronous reponses indicate the success
     or failure of client commands. Asynchronous responses describe
     object events. The banner response is issued once by the server at
     session startup, and describes the application profile being
     served. Authentication responses are issued at session startup and
     describe the authentication mechanisms supported by the server.

5.1.1.	Banner Response

     Contents: protocol name
	       application profile identifier
	       OPTIONAL human readable text

     State:    initial

     Upon startup the server announces itself by issuing a banner
     response. The banner identifies the protocol (SIN) and the name of
     the application profile being served.

     The human readable text field can be used to communicate informa-
     tion about the implementation that would assist in debugging the
     implementation (e.g. a vendor name, release number, etc.) The
     length of this field SHOULD NOT exceed 60 octets, and clients MUST
     NOT interpret the contents of this field in any way.

5.1.2.	AUTH Response

     Contents: authentication mechanism name

     State:    initial

     The AUTH response identifies an authentication mechanism supported
     by the server. One AUTH response is sent for each supported authen-
     tication mechanism. Servers MUST support at least one authentica-
     tion mechanism. Where authentication identifiers are not applicable
     the application profile MUST specify use of the ANONYMOUS mecha-
     nism.

     AUTH responses are sent only at server startup. They MUST follow
     the banner response, and MUST preceed the servers initial OK or NO
     response.

5.1.3.	OK Response

     Contents: none

     State:    any

     Commands: IGNORE, WATCH

     The OK response indicates the previously issued command completed

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 5]

Internet Draft	      Simple Internet Notifications	   February 2001

     without error.

     At protocol startup, an OK response terminating the servers greet-
     ing indicates it is willing to provide notification services.

5.1.4.	NO Response

     Contents: none

     State:    any

     Commands: IGNORE, WATCH

     The NO response indicates the server was unable to perform the
     requested command.

     At protocol startup, a NO response terminating the servers greeting
     indicates it is unable to provide notification services. Clients
     receiving a NO response at the end of the server greeting MUST
     immediately terminate the session.

5.1.5.	SYNTAX Response

     Contents: none

     State:    any

     Commands: any

     The SYNTAX response indicates the previous command was syntacti-
     cally incorrect. An object name that violates the application pro-
     files object name encoding rules MUST be rejected with a SYNTAX
     response in order to distinguish it from a properly encoded but
     semantically invalid object name.

5.1.6.	EXIT Response

     Contents: none

     State:    authenticated

     Commands: EXIT

     The EXIT response indicates the server is closing the session.
     After issuing an EXIT response, servers SHOULD NOT send any further
     traffic to the client. Servers SHOULD provide clients with a grace
     period in which to terminate the session, however the server MAY
     terminate the session at any time after issuing the EXIT response.

     A server MAY issue an asynchronous EXIT response to request the
     client initiate session termination. This is an implementation
     optimization. In some cases the server can save resources by having
     the client initiate the close of the protocol session. However, the
     server is NOT REQUIRED to issue an EXIT response before shutting

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 6]

Internet Draft	      Simple Internet Notifications	   February 2001

     down, and clients MUST be prepared to shut down gracefully in the
     absence of EXIT responses. A client receiving an asynchronous EXIT
     response MUST NOT issue an EXIT command as part of the shutdown
     sequence.

5.1.7.	EVENT Response

     Contents: object name

     State:    authenticated

     Commands: none

     EVENT responses are issued whenever an event occurs to a monitored
     object. The response includes the name of the object to which the
     event occurred.

     EVENT responses are asynchronous notifications and may be generated
     at any time while the session is in the authenticated state.

5.1.8.	LOST Response

     Contents: object name

     State:    authenticated

     Commands: none

     The server issues a LOST response whenever it can no longer provide
     event notifications for a monitored object. LOST SHOULD be issued
     when the server cannot continue to provide notification services on
     the object for reasons outside its control (for example, the moni-
     tored object has been permanently destroyed, or an operating system
     error prevents continued access to the object).  Application pro-
     files MAY provide additional guidance for issuing LOST responses.
     In the absence of such guidance, servers SHOULD NOT issue a LOST
     response unless they are reasonably certain the object is perma-
     nently unavailable.

     Servers MUST NOT issue a LOST response in response to an IGNORE
     command.

     LOST responses are asynchronous notifications and may be generated
     at any time while the session is in the authenticated state.

5.2.  Client Commands

5.2.1.	AUTHENTICATE Command

     Arguments: authentication mechanism name

     Responses: continuation data can be requested

     Result: OK      - Authentication credentials accepted; server now

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 7]

Internet Draft	      Simple Internet Notifications	   February 2001

		       in authenticated state.
	     NO      - Authentication failure: credentials rejected or
		       underlying backend authentication service
     unavailable.
	     SYNTAX  - Command rejected: invalid arguments or unknown
		       authentication mechanism.

     The AUTHENTICATE command requests an authentication context be
     established with the server, using the specified mechanism. The
     server performs an authentication protocol exchange to authenticate
     and identify the client.  It MAY also negotiate an OPTIONAL protec-
     tion mechanism for subsequent protocol interactions. If the
     requested authentication mechanism is not supported the server MUST
     reject the AUTHENTICATE command by sending a SYNTAX response.

     The authentication protocol exchange consists of a series of server
     challenges and client answers that are specific to the authentica-
     tion mechanism.  A server challenge consists of a command continua-
     tion request response with the "+" token followed by a BASE64
     encoded string.  The client answer consists of a line consisting of
     a BASE64 encoded string.  If the client wishes to cancel an authen-
     tication exchange, it issues a line with a single "*".  If the
     server receives such an answer, it MUST reject the AUTHENTICATE
     command by sending a tagged SYNTAX response.

     A protection mechanism provides integrity and privacy protection to
     the connection.  If a protection mechanism is negotiated, it is
     applied to all subsequent data sent over the connection.  The pro-
     tection mechanism takes effect immediately following the CRLF that
     concludes the authentication exchange for the client, and the CRLF
     of the tagged OK response for the server.	Once the protection
     mechanism is in effect, the stream of command and response octets
     is processed into buffers of ciphertext.  Each buffer is trans-
     ferred over the connection as a stream of octets prepended with a
     four octet field in network byte order that represents the length
     of the following data.  The maximum ciphertext buffer length is
     defined by the protection mechanism.

     Servers MUST implement at least one authentication mechanism.  If
     the application profile describes a service where authentication
     credentials are not applicable the server and client MUST implement
     and use the ANONYMOUS mechanism.

5.2.2.	WATCH Command

     Arguments: object name

     Result:  OK     - The object has been added to the notification
     list.
	      NO     - The object does not exist, the object name is
		       invalid in the context of the application pro-
     file,
		       the application service access policy denies
		       notification access to the object, or the number

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 8]

Internet Draft	      Simple Internet Notifications	   February 2001

     of
		       monitored objects exceeds a system or implementa-
     tion
		       limit.
	      SYNTAX - The object name is improperly encoded.

     The WATCH command changes an objects status from ignored to moni-
     tored.  Upon successful completion of the WATCH command the server
     will send event notifications for the object to the client.

5.2.3.	IGNORE Command

     Arguments: object name

     Result:  OK     - The object has been removed from the
		       notification list.
	      NO     - The object was not on the servers list of
		       monitored objects.
	      SYNTAX - The object name is improperly encoded.

     The IGNORE command changes an objects status from monitored to
     ignored.

     Upon successful completion of the IGNORE command the server will no
     longer send event notifications for the object to the client.

     After successful completion of an IGNORE command there may be unde-
     livered event notifications for the object that the server cannot
     cancel.  For this reason, clients MUST be capable of accepting
     event notifications for objects they are not currently monitoring.

6.  Example Session

     This example shows a SIN session used to provide newmail notifica-
     tion services to a mail client using the IMAP4 application profile.
     Client commands are prefixed with "C: " and server responses with
     "S: "; these are not part of the SIN protocol.

	 S: SIN IMAP4 Frobozz Magic Notifications Server (v1.0)
	 S: AUTH KERBEROS_V4
	 S: AUTH CRAM-MD5
	 S: OK
	 C: AUTHENTICATE CRAM-MD5
	 S: + PDIyNDE5OTguMTMxMzE0MDhAcmVtYnJhbmR0LmVzeXMuY2E+
	 C: bHluZG9uIDU1NmMyZjYyNzQzZGQ0Y2Q5ZjBiYjUyNzg2NWVkYzZk
	 S: OK
	 C: WATCH INBOX
	 S: OK
	 C: WATCH #public/Mailing Lists/%
	 S: NO
	 C: WATCH #public/Mailing Lists/bugtraq
	 S: EVENT INBOX
	 S: OK
	 S: EVENT #public/Mailing Lists/bugtraq

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 9]

Internet Draft	      Simple Internet Notifications	   February 2001

	 S: EVENT #public/Mailing Lists/bugtraq
	 S: EVENT #public/Mailing Lists/bugtraq
	 S: EVENT INBOX
	 S: EVENT #public/Mailing Lists/bugtraq
	 C: IGNORE #public/Mailing Lists/bugtraq
	 S: OK
	 S: EXIT
	 <client terminates connection>

     After accepting the connection the server announces itself as a SIN
     server offering the IMAP4 application profile, and lists the three
     authentication mechanisms it supports.  The client authenticates
     using the CRAM-MD5 SASL mechanism.

     The request for notifications on the #public/Mailing Lists/%
     object, while syntactically correct, was rejected by the server due
     to a violation of the application profile's object namespace pol-
     icy. Note the use of NO to distinguish between policy violations
     and protocol errors. (A protocol error would have provoked a SYNTAX
     response.)

     The last item of interest is the event notification occuring while
     the final WATCH command was in progress. There is no guarantee that
     WATCH commands will complete quickly, so this sequence can be
     expected to happen frequently when monitoring active objects.

7.  Formal Protocol Grammar

8.  Security Considerations

9.  Authors' Addresses

       Lyndon Nerenberg
       Orthanc Systems
       Unit 575-21
       10405 Jasper Avenue
       Edmonton, Alberta
       Canada T5J 3S2

       Email: [email-masked]

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt        [Page 10]


--==_Exmh_11849420220
Content-Type: text/plain ; name="draft-nerenberg-sin-imap.txt"; charset=us-ascii
Content-Description: draft-nerenberg-sin-imap.txt
Content-Disposition: inline; filename="draft-nerenberg-sin-imap.txt"

Network Working Group					Lyndon Nerenberg
Internet Draft: SIN IMAP4 Application Profile		 Orthanc Systems
Document: draft-nerenberg-sin-imap-xx.txt		   February 2001

		     Simple Internet Notifications
		       IMAP4 Application Profile

Status of this memo

     This document is an Internet Draft.  Internet Drafts are working
     documents of the Internet Engineering Task Force (IETF), its Areas,
     and its Working Groups.  Note that other groups may also distribute
     working documents as Internet Drafts.

     Internet Drafts are draft documents valid for a maximum of six
     months.  Internet Drafts may be updated, replaced, or obsoleted by
     other documents at any time.  It is not appropriate to use Internet
     Drafts as reference material or to cite them other than as a
     "working draft" or "work in progress."

     To learn the current status of any Internet-Draft, please check the
     1id-abstracts.txt listing contained in the Internet-Drafts Shadow
     Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
     munnari.oz.au.

     Discussion and suggestions for improvement are requested.	This
     document will expire six months after publication.  Distribution of
     this draft is unlimited.

1. Introduction

     Simple Internet Notifications [SIN] provides a generic event noti-
     fication framework. SIN application profiles define the character-
     istics of a SIN server for a specific application.

     This document defines a SIN application profile that provides new
     mail arrival notification services on behalf on Internet Message
     Access Protocol [IMAP4rev1] servers.

2. Conventions used in this document

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
     in this document are to be interpreted as described in [KEYWORD].

     The protocol syntax specifications use the Augmented Backus-Naur
     Form (ABNF) notation as specified in [ABNF].

3. Application Profile Identifier

Nerenberg							[Page 1]

Internet Draft	      SIN IMAP4 Application Profile	   February 2001

     The identifier for this application profile is IMAP4.

4. Authentication Namespace

     The authentication namespace exported by a SIN server running this
     profile MUST be identical to the authentication namespace exported
     by the corresponding IMAP4 server.

     If the IMAP4 server does not support any SASL authentication mecha-
     nisms (i.e. it only supports the IMAP4 LOGIN command), the SIN
     server MUST offer the PLAIN authentication mechanism, and MUST
     treat AUTH PLAIN requests as the IMAP4 server would LOGIN requests.

5. Objects

5.1. Object Namespace

     Object names in this profile represent IMAP4 folder names.

     An object names a unique IMAP4 folder. Servers MUST NOT perform
     wildcard expansion on object names.

5.2. Object Name Encoding

     Object names are encoded using the modified UTF-7 encoding scheme
     described in [IMAP4].

6. Event Triggers

     Introduction of any message into a monitored object (folder) MUST
     generate an EVENT event notification.

     If the monitored object (folder) is destroyed or becomes perma-
     nently unaccessable (for example, through a change in security pol-
     icy), the server MUST generate a LOST event notification.

7. Security Considerations

     Servers MUST perform all operations in the security context of the
     authenticated entity. Servers MUST NOT expose any information about
     the IMAP4 folder namespace that would not be available if the same
     credentials were used to connect to the IMAP4 server.

     Servers MUST NOT send notification events (including LOST
     responses) for a folder unless the authentication and authorization
     credentials used for the SIN session, if used to connect to the
     IMAP4 server, would allow a successful IMAP4 SELECT on that folder.

Nerenberg							[Page 2]

Internet Draft	      SIN IMAP4 Application Profile	   February 2001

8. Authors' Addresses

  Lyndon Nerenberg
  Orthanc Systems
  Unit 575-21
  10405 Jasper Avenue
  Edmonton, Alberta
  Canada T5J 3S2

  Email: [email-masked]

Nerenberg							[Page 3]


--==_Exmh_11849420220--

Date: Thu, 08 Feb 2001 07:15:14 -0800
From: Chris Newman <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance
Sender: [email-masked]

--On Wednesday, February 7, 2001 16:08 -0700 Lyndon Nerenberg 
<[email-masked]> wrote:
> Just to be clear, you're saying:
>
> 1) FETCH SHOULD return well-formed RFC822/MIME message content, but
>    servers MAY send anything allowed by the IMAP4 protocol syntax, and
>
> 2) APPEND data SHOULD be a well-formed RFC822/MIME message, but servers
>    MAY accept anything that fits in the IMAP4 protocol syntax for APPEND.

Yes, although those statements are too vague for a formal standard.

RFC 2060 says (2) so we're stuck with it.  However, since 2060 does not say 
(1), FETCH inherits all requirements of RFC 822/MIME by reference.  That 
implies the only way to be fully compliant with 2060 is to somehow fix 
everything accepted under (2) so it's 822/MIME compliant on FETCH.  Since 
it doesn't specify the downconversion procedure adequately (especially for 
8-bit headers), I'd say the status quo is unacceptable.

If Mark can translate the core ideas from his most recent messsage on this 
thread to standards-style language, that would be good enough for me.  Mark 
and I obviously disagree somewhat on the value of a server rejecting or 
down-converting ill-formed 822/MIME messages, but as long as the spec 
doesn't forbid doing so, I don't forsee any problems.

		- Chris

Date: Wed, 7 Feb 2001 15:25:18 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance 
To: Lyndon Nerenberg <[email-masked]>
cc: Chris Newman <[email-masked]>, IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Sender: [email-masked]

On Wed, 07 Feb 2001 16:08:51 -0700, Lyndon Nerenberg wrote:
> 1) FETCH SHOULD return well-formed RFC822/MIME message content, but
>    servers MAY send anything allowed by the IMAP4 protocol syntax, and

FETCH should return an accurate representation of what is in the mailbox.  An
IMAP server is not required to "fix" FETCH data to comply with RFC822/MIME.

Client authors must therefore expect to encounter FETCH data that complies
with IMAP, but not necessarily with RFC822/MIME.

> 2) APPEND data SHOULD be a well-formed RFC822/MIME message, but servers
>    MAY accept anything that fits in the IMAP4 protocol syntax for APPEND.

It is desirable that message data placed in a mailbox (whether via APPEND,
SMTP, LMTP, or NNTP) be well-formed according to RFC822/MIME.  However, this
assumption is openly violated by NNTP.  There is no requirement that APPEND or
SMTP "fix" (or not fix) incoming data to comply with RFC822/MIME; I don't know
if LMTP has any such requirement.  There is no requirement that APPEND or SMTP
accept incoming data that does not comply with RFC822/MIME.  However, the SMTP
specification encourages servers to err on the side of permissiveness in the
face of client non-compliance.

> #2 I can live with, although I would feel better if there was some wording
> that makes it clear that servers can (and probably will) reject things that
> don't fit the '822/MIME syntax.

I agree that an IMAP server may reject APPEND of a message due to RFC822/MIME
non-compliance.

However, I consider such behavior grounds for rejecting a particular
implementation from consideration for deployment, and would recommend
accordingly.  It is not difficult to prepare a demonstration on how that
server fails to perform to user expectations.

It is more difficult to argue against a server which accepts such messages,
but "fixes" them to comply.  However, I would try to find an example in which
the server "fixes" it into a worse condition, and would recommend against the
server if I found such an example.  Conversely, I would be favorably impressed
if I can't find such an example.

> For #1 my concern is that this can be read as a license for the injection
> mechanism (e.g. LMTP) to let anything in to the message store.

That is something that the LMTP specification must address.  It is not an IMAP
issue.

I would consider a client that generates non-compliant messages to APPEND (as
opposed to using APPEND to copy a message from another source) to have a
quality of implementation problem, and would probably recommend against
deployment of such a client.

However, since it is not possible for a server to determine whether the client
generated the non-compliant text, or is simply copying a message from another
source, I look upon this less harshly than I would a server that refuses to
accept user data in APPEND.

> Here's another wrench to ponder: could we make \draft explicitly relax the
> RFC822/MIME syntax requirements for a message?

That has bad implications for STORE FLAGS.

There is a fundamental principle which ranks up there with "be conservative in
what you generate, be liberal in what you accept."  In fact, this is the most
important principle: "garbage in, garbage out."

Of course, one man's garbage may be another man's treasure.

I treat message data (even garbage) as treasure to the maximum extent
possible, and restrict my strict demands on protocol compliance to those
matters dictated by IMAP syntax.

From: Lyndon Nerenberg <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance 
Organization: ACI Worldwide - MessagingDirect
Date: Wed, 07 Feb 2001 16:08:51 -0700
Sender: [email-masked]

> RFC 822 requires a from header, a recipient header (To, Cc, or Bcc) and a 
> date header (see the formal syntax).  So while I agree that Mark's answer 
> is appropriate for IMAP, the RFC 822 rule needs to be explicitly waived for 
> IMAP.  MIME had the same issue with multipart/digest.

Just to be clear, you're saying:

1) FETCH SHOULD return well-formed RFC822/MIME message content, but
   servers MAY send anything allowed by the IMAP4 protocol syntax, and

2) APPEND data SHOULD be a well-formed RFC822/MIME message, but servers
   MAY accept anything that fits in the IMAP4 protocol syntax for APPEND.

#2 I can live with, although I would feel better if there was some wording
that makes it clear that servers can (and probably will) reject things that
don't fit the '822/MIME syntax.

For #1 my concern is that this can be read as a license for the injection
mechanism (e.g. LMTP) to let anything in to the message store. I would
prefer to see wording that makes it completely clear that that's not the case.

Here's another wrench to ponder: could we make \draft explicitly relax the
RFC822/MIME syntax requirements for a message?

--lyndon

Date: Wed, 07 Feb 2001 14:42:07 -0800
From: Chris Newman <[email-masked]>
To: Mark Crispin <[email-masked]>, Lyndon Nerenberg <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance
Sender: [email-masked]

--On Monday, February 5, 2001 20:13 -0800 Mark Crispin 
<[email-masked]> wrote:
> Otherwise, what is a server supposed to do with messages in a mailbox
> which do not strictly conform to RFC 822?   It's one thing to generate as
> best an envelope as it can; it is quite another to "fix" them to be
> "valid".  May anyone who thinks otherwise be condemned to relive the
> early 1980s when various systems running sendmail commonly "fixed"
> message headers into total gubbish.

The problem with older versions of sendmail was not that it made 
non-standards compliant headers compliant, but rather that it attempted to 
do so without fully implementing the standard and understanding the 
consequences of the changes it made.  Indeed it made some compliant headers 
non-complaint (e.g., "group:;" -> "group:;@host") and thus created new 
compliance problems.

The 8BITMIME spec describes a specific procedure to deal with message 
bodies that aren't complaint with the SMTP or 822 base specs, and this 
procedure works just fine in practice.

PMDF has repaired standards compliance errors in email headers for over 15 
years, and it works great.  Clients routinely core dump (or bomb or blue 
screen) when they encounter incompliant messages.  Most enterprises or ISPs 
would rather have messages fixed by the server so they don't get 200 
support calls to the IT helpdesk about the client crashing.

>> But on a related note, is it valid to have *no* headers? (I.e. the
>> message starts with CRLF.)  Presumably it would be valid for a client
>> to want to store a draft message that contains body text but no headers.
>
> I believe that the answer is "yes".  BODY[HEADER] would be 4 octets (CR
> LF CR LF) and BODY[TEXT] would be everything after that.

RFC 822 requires a from header, a recipient header (To, Cc, or Bcc) and a 
date header (see the formal syntax).  So while I agree that Mark's answer 
is appropriate for IMAP, the RFC 822 rule needs to be explicitly waived for 
IMAP.  MIME had the same issue with multipart/digest.

		- Chris

Date: Tue, 6 Feb 2001 16:40:04 -0700 (MST)
From: Lyndon Nerenberg <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance 
Sender: [email-masked]

> However, there is a valid IMAP representation even for non-sensical results.

Well, okay :-)  I can guess what will happen when one of those is
presented to a client, though.

Date: Mon, 5 Feb 2001 20:13:16 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance 
To: Lyndon Nerenberg <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Sender: [email-masked]

On Mon, 05 Feb 2001 15:58:07 -0700, Lyndon Nerenberg wrote:
> I agree that this must specify that the text at least conform
> to the 822 header syntax. For servers that parse 822 and MIME headers
> at injection time (such as ours and Cyrus) anything else is
> going to be rejected or result in non-sensical FETCH results.

However, there is a valid IMAP representation even for non-sensical results.

Otherwise, what is a server supposed to do with messages in a mailbox which do
not strictly conform to RFC 822?   It's one thing to generate as best an
envelope as it can; it is quite another to "fix" them to be "valid".  May
anyone who thinks otherwise be condemned to relive the early 1980s when
various systems running sendmail commonly "fixed" message headers into total
gubbish.

> But on a related note, is it valid to have *no* headers? (I.e. the
> message starts with CRLF.)  Presumably it would be valid for a client
> to want to store a draft message that contains body text but no headers.

I believe that the answer is "yes".  BODY[HEADER] would be 4 octets (CR LF CR
LF) and BODY[TEXT] would be everything after that.

From: Lyndon Nerenberg <[email-masked]>
to: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance 
Organization: ACI Worldwide - MessagingDirect
Date: Mon, 05 Feb 2001 15:58:07 -0700
Sender: [email-masked]

> --On Monday, February 5, 2001 12:12 -0800 Mark Crispin 
> <[email-masked]> wrote:
> > So, I don't see how it's possible to have any other interpretation for
> > "[RFC-822] header" than "that part of the message which appears prior to
> > the first CRLF CRLF".
> 
> I interpret "[RFC-822] header" as the subset of an RFC-822 conformant 
> message prior to the CRLF CRLF.
> 
> If "[RFC-822] header" doesn't conform to the syntax defined in RFC-822, 
> then what syntax does it conform to?

I agree that this must specify that the text at least conform
to the 822 header syntax. For servers that parse 822 and MIME headers
at injection time (such as ours and Cyrus) anything else is
going to be rejected or result in non-sensical FETCH results. There's
no way our implementation could accept anything in that part of the
message that doesn't conform to the 822 header syntax.

But on a related note, is it valid to have *no* headers? (I.e. the
message starts with CRLF.)  Presumably it would be valid for a client
to want to store a draft message that contains body text but no headers.
(If the body represents a single part 7bit text/plain there's no
requirement for an explicit MIME-Version header at any stage of the
draft composition.)

--lyndon

Date: Mon, 05 Feb 2001 14:11:11 -0800
From: Chris Newman <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: re: Major error in IMAP base spec: 822/MIME conformance
Sender: [email-masked]

--On Monday, February 5, 2001 12:12 -0800 Mark Crispin 
<[email-masked]> wrote:
> So, I don't see how it's possible to have any other interpretation for
> "[RFC-822] header" than "that part of the message which appears prior to
> the first CRLF CRLF".

I interpret "[RFC-822] header" as the subset of an RFC-822 conformant 
message prior to the CRLF CRLF.

If "[RFC-822] header" doesn't conform to the syntax defined in RFC-822, 
then what syntax does it conform to?

To fix this problem, I suggest something along the lines of taking the 
language from the APPEND section and making it clear it also applies to 
FETCH.  If you feel it would be constructive for me to suggest strawman 
language, I'll do so, but I'd rather leave the specifics to your judgement.

		- Chris

Date: Mon, 5 Feb 2001 12:12:43 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: re: Major error in IMAP base spec: 822/MIME conformance
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 5 Feb 2001, Chris Newman wrote:
> However, while the base spec is quite clear in allowing non-RFC 822
> messages on APPEND, it also states that FETCH returns RFC 822 formatted
> headers.  These statements can't both be true.  I propose that you resolve
> the discrepancy in the manner you feel is most appropriate as I trust your
> judgement on i18n issues.  If the way to resolve the discrepancy with
> minimal backwards compatibility issues is to state that FETCH can return
> non-RFC 822 headers and messages, so be it.

I would agree to make a fix to any statement that says that "FETCH returns
RFC 822 formatted headers" if I could find such a statement.  The word
"formatted" appears nowhere in the document.  The closest that I can find
are references to "[RFC-822] header".

RFC 822 does not define anything called a "header"; instead, it uses the
term "header fields".

RFC 2060, in turn, only uses "header fields" in the context of subsetting
header fields.  RFC 2060 definitely permits an ENVELOPE to have NIL for
items which can not be NIL in an RFC 822 message.

On top of that, very few news messages comply with RFC 822; yet I have not
heard anyone claim that this precludes the use of RFC 822 to describe the
syntax of headers in news.

So, I don't see how it's possible to have any other interpretation for
"[RFC-822] header" than "that part of the message which appears prior to
the first CRLF CRLF".

-- Mark --

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

Date: Mon, 05 Feb 2001 11:24:59 -0800
From: Chris Newman <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: re: Major error in IMAP base spec: 822/MIME conformance
Sender: [email-masked]

Mark,

My previous proposal on this issue was crafted before I understood the 
implications of the language in 2060 permitting 8-bit throughout the 
message on APPEND.  I agree my original proposal was incorrect and withdraw 
it.

However, while the base spec is quite clear in allowing non-RFC 822 
messages on APPEND, it also states that FETCH returns RFC 822 formatted 
headers.  These statements can't both be true.  I propose that you resolve 
the discrepancy in the manner you feel is most appropriate as I trust your 
judgement on i18n issues.  If the way to resolve the discrepancy with 
minimal backwards compatibility issues is to state that FETCH can return 
non-RFC 822 headers and messages, so be it.

But I do not believe it is appropriate to publish a revision of the base 
spec with contradictory statements once they have been identified.

		- Chris

--On Friday, February 2, 2001 19:10 -0800 Mark Crispin 
<[email-masked]> wrote:

> In the interest of saving time for everyone:
>  . this matter is outside of the charter of IMAPEXT, and thus should be
>     discussed in IMAP, not IMAPEXT.
>  . the proposed change introduces a major incompatibility that breaks:
>    . existing compliant implementations
>    . existing use of IMAP to access netnews
>    . existing use of IMAP in certain European and Asian countries
>
> Furthermore, the argument that supports the proposed change also renders
> in error the facility whereby APPEND can write drafts that lack headers
> required by RFC 822.  I do not believe that client writers who use for
> this would be pleased with such a change.
>
> Consequently, the proposed change is outside of the scope of the effort to
> update the base specification, and thus is not within my discretion to
> make even if I supported it (which I do not).
>
> Is there concensus to abandon the update work on the IMAP4rev1 base
> specification, and reconstitute the IMAP Working Group to create an
> incompatible replacement to IMAP4rev1 that will incorporate the proposed
> chang and disallow use of IMAP to access messages in "just send 8-bit"
> environments (netnews, and certain European and Asian countries)?
>
> For all the reasons indicated above, I vote NO.  I do not believe that the
> argument in favor of the change is correct; nor that there is any error
> in the base specification; nor that this matter warrants a change to the
> text of the base specification.
>
> If you feel that otherwise, please present your case on the IMAP mailing
> list.
>

Date: Fri, 2 Feb 2001 19:10:25 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Major error in IMAP base spec: 822/MIME conformance
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

In the interest of saving time for everyone:
 . this matter is outside of the charter of IMAPEXT, and thus should be
    discussed in IMAP, not IMAPEXT.
 . the proposed change introduces a major incompatibility that breaks:
   . existing compliant implementations
   . existing use of IMAP to access netnews
   . existing use of IMAP in certain European and Asian countries

Furthermore, the argument that supports the proposed change also renders in
error the facility whereby APPEND can write drafts that lack headers required
by RFC 822.  I do not believe that client writers who use for this would be
pleased with such a change.

Consequently, the proposed change is outside of the scope of the effort to
update the base specification, and thus is not within my discretion to make
even if I supported it (which I do not).

Is there concensus to abandon the update work on the IMAP4rev1 base
specification, and reconstitute the IMAP Working Group to create an
incompatible replacement to IMAP4rev1 that will incorporate the proposed chang
and disallow use of IMAP to access messages in "just send 8-bit" environments
(netnews, and certain European and Asian countries)?

For all the reasons indicated above, I vote NO.  I do not believe that the
argument in favor of the change is correct; nor that there is any error in the
base specification; nor that this matter warrants a change to the text of the
base specification.

If you feel that otherwise, please present your case on the IMAP mailing list.

Date: Fri, 02 Feb 2001 18:26:40 -0800
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Major error in IMAP base spec: 822/MIME conformance
Sender: [email-masked]

The syntax which APPEND permits in section 6.3.11:

      The APPEND command appends the literal argument as a new message
      to the end of the specified destination mailbox.  This argument
      SHOULD be in the format of an [RFC-822] message.  8-bit characters
      are permitted in the message.  A server implementation that is
      unable to preserve 8-bit data properly MUST be able to reversibly
      convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content
      transfer encoding.

      Note: There MAY be exceptions, e.g. draft messages, in which
      required [RFC-822] header lines are omitted in the message literal
      argument to APPEND.  The full implications of doing so MUST be
      understood and carefully weighed.

Is different from the syntax which FETCH returns in section 6.4.5:

                     The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT
                     part specifiers refer to the [RFC-822] header of
                     the message or of an encapsulated [MIME-IMT]
                     MESSAGE/RFC822 message.  HEADER.FIELDS and
                     HEADER.FIELDS.NOT are followed by a list of
                     field-name (as defined in [RFC-822]) names, and
                     return a subset of the header.  The subset returned
                     by HEADER.FIELDS contains only those header fields
                     with a field-name that matches one of the names in
                     the list; similarly, the subset returned by
                     HEADER.FIELDS.NOT contains only the header fields
                     with a non-matching field-name.  The field-matching
                     is case-insensitive but otherwise exact.  In all
                     cases, the delimiting blank line between the header
                     and the body is always included.

Since the FETCH HEADER items reference RFC-822/MIME for the syntax, they 
inherit the restriction from those specifications which forbid 8-bit in all 
headers in all cases.

Thus the syntax of APPEND requires a server to accept things that it is 
forbidden to send in response to FETCH.  This needs to be fixed.

Rather than argue with Mark, I suggest he fix it however he prefers.  I 
expect I'll go along with any proposal that has a reasonable chance of 
getting by the area directors.

		- Chris

Date: Fri, 2 Feb 2001 15:24:43 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: LAST CALL: IMAP base and MULTIAPPEND drafts
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Fri, 02 Feb 2001 14:51:08 -0800, Chris Newman wrote:
> While this applies to validation for the presence of required header
> fields, it does not apply to illegal 8-bit in headers.

What standards-track document makes such a distinction?

The only document which makes any references to messages which do not have
required fields in the context of IMAP is the IMAP specification, and that
text explicitly permits 8-bit characters.

> Indeed,
> Cyrus-derived servers tend to reject APPEND commands with illegal 8-bit in
> headers.

Although that is its perogative, it may not be in full compliance with IMAP.

> The fact remains that an IMAP server which sends illegal 8-bit header data
> in response to a FETCH is not standards compliant.

Incorrect.  RFC 2060, page 13:

   [...]  IMAP4rev1 implementations MAY
   transmit 8-bit or multi-octet characters in literals, but SHOULD do
   so only when the [CHARSET] is identified.

Later, on page 34:

      [...] This argument
      SHOULD be in the format of an [RFC-822] message.  8-bit characters
      are permitted in the message.  A server implementation that is
      unable to preserve 8-bit data properly MUST be able to reversibly
      convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content
      transfer encoding.

In other words, such behavior, while a violation of what RFC 2060 considers to
be good practice, is compliant since the term is "SHOULD" instead of "MUST".

It would be impossible to make it a MUST; it is widely violated in Europe and
Japan.  A MUST which is unenforcible and widely violated is a sick joke, and I
am not interested in making sick jokes.

> Thus if an IMAP server
> accepts illegal 8-bit header data it must do something to make FETCH
> compliant.

It may do something; or it may decide to leave bad enough alone in the name of
avoiding sendmail disease (that is, "fixing" data into a broken state).

>     An IMAP server MUST NOT send illegal 8-bit characters in headers
>     in response to a FETCH command.

Earlier, you claimed that this requirement already existed; now you're trying
to add it as a new requirement.

>     [...] When an IMAP server receives an
>     APPEND command which contains illegal 8-bit characters in headers,
>     it MAY accept the command only if appropriate down-conversion to
>     MIME header encoding [RFC2047] is performed.

"Illegal 8-bit character" is undefined, unless you mean "8-bit octet which
does not comply with UTF-8 encoding."  There is no way for a server to
distinguish a string which complies with UTF-8 encoding, but is in a character
set other than Unicode, from UTF-8.

Consequently, the server is given a mandate which it can not reliably execute.
Furthermore, what constitutes an "illegal 8-bit character" could conceivably
change over time.

The only server mandate which currently exists is that a 7-bit server must do
MIME down-conversion.  As the author of the only 7-bit server in existance
(the TOPS-20 one, which supports RFC 1176 IMAP2), if I ever implemented
IMAP4rev1 (and thus the APPEND command) in that server the very first thing I
would do is make it be 8-bit, simply because I don't know how to implement the
down-convert mandate if I don't know the character set.  The principle of "do
the least harm" indicates leaving it in 8-bit with undefined character set and
not down-convert with a guess of the character set.

Your proposed change, on the other hand, forces all server implementations to
implement down-conversion with character set guessing.  This creates harm that
currently does not exist.

> The message format document is distinctly the wrong place for this wording,
> as this also applies to MIME headers and validation is only appropriate for
> interactive protocols (e.g., IMAP APPEND and Submit, but not SMTP relay).

It absolutely is correct to be in the message format document.  Otherwise, you
have to change every "interactive" protocol document to comply when the
message format document changes.  Furthermore, the distinction between Submit
and SMTP relay in real life is often illusory, since in most cases the two are
the same service.

Much of the pain in MIME would not have been necessary if the SMTP document
had not imposed a restriction of the message format document that was later
overturned.

As matters stand now, responsibility for compliance with the current message
format document rests with the client, not the server.  The IMAP specification
(page 34) explicitly indicates the possibility of a append argument which does
not comply with RFC-822, and which contains 8-bit characters.  This status quo
is a Good Thing and should not be broken.

Date: Fri, 02 Feb 2001 14:51:08 -0800
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: LAST CALL: IMAP base and MULTIAPPEND drafts
Sender: [email-masked]

--On Friday, January 5, 2001 11:24 -0800 Mark Crispin 
<[email-masked]> wrote:
> There seems to be a concensus (which I share) that IMAP servers should not
> attempt to do message format validation on APPEND because of the issue
> with drafts.

While this applies to validation for the presence of required header 
fields, it does not apply to illegal 8-bit in headers.  Indeed, 
Cyrus-derived servers tend to reject APPEND commands with illegal 8-bit in 
headers.

>  However, if such validation is done, I feel that the
> specification of the validation should be in the message format document
> (RFC 822 or successor) and not in an IMAP document.  As far as the IMAP
> document is concerned, the APPEND text is simply a literal.

The fact remains that an IMAP server which sends illegal 8-bit header data 
in response to a FETCH is not standards compliant.  Thus if an IMAP server 
accepts illegal 8-bit header data it must do something to make FETCH 
compliant.  Here's strawman wording:

    An IMAP server MUST NOT send illegal 8-bit characters in headers
    in response to a FETCH command.  When an IMAP server receives an
    APPEND command which contains illegal 8-bit characters in headers,
    it MAY accept the command only if appropriate down-conversion to
    MIME header encoding [RFC2047] is performed.  IMAP servers are
    encouraged to accept APPEND commands with UTF-8 characters in headers.

This wording would remain correct if a future standard explicitly legalized 
unencoded UTF-8 headers.

The message format document is distinctly the wrong place for this wording, 
as this also applies to MIME headers and validation is only appropriate for 
interactive protocols (e.g., IMAP APPEND and Submit, but not SMTP relay). 
I'd prefer this went into the IMAP base spec, but I could live with 
deferring it for a future standard on handling 8-bit characters in message 
headers.

		- Chris

From: "Eric Burger" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: FW: I-D ACTION:draft-ietf-vpim-hint-02.txt
Date: Thu, 1 Feb 2001 10:22:54 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0033_01C08C38.F07C2960
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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

	Title		: Message Context for Internet Mail
	Author(s)	: E. Burger, E. Candell, C. Eliot, G. Klyne
	Filename	: draft-ietf-vpim-hint-02.txt
	Pages		: 19
	Date		: 26-Jan-01

This memo describes a new RFC822 message header, 'Message-Context'.
This header provides information about the context and presentation
characteristics of a message.
A receiving user agent (UA) may use this information as a hint to
optimally present the message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-02.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-vpim-hint-02.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-vpim-hint-02.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_000_0033_01C08C38.F07C2960
Content-Type: Message/External-body;
	name="ATT00024.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00024.dat"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-vpim-hint-02.txt

------=_NextPart_000_0033_01C08C38.F07C2960
Content-Type: Message/External-body;
	name="draft-ietf-vpim-hint-02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-ietf-vpim-hint-02.txt"

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

------=_NextPart_000_0033_01C08C38.F07C2960--

Date: Wed, 28 Feb 2001 16:48:40 -0800
To: Randall Gellens <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: Progress? Meeting?
Sender: [email-masked]

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>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
One of the greatest labor saving inventions of today is tomorrow.  -
                                               --Vincent T. Foss

Date: Wed, 28 Feb 2001 13:52:58 -0800
From: Chris Newman <[email-masked]>
Subject: Re: binary draft and APPEND
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
Cc: [email-masked]
Sender: [email-masked]

--On Tuesday, February 27, 2001 13:20 -0700 Lyndon Nerenberg 
<[email-masked]> wrote:

>> I disagree with section 4.4 of this draft on the grounds that it breaks
>> backwards compatibility with IMAP clients that are not binary aware.
>>
>> RFC 2060 section 4.3.1 states "Implementations MUST encode binary data
>> into  a textual form such as BASE64 before transmitting the data."  I
>> interpret  this to mean that any RFC 2060 server implementation which
>> receives a  "binary" body part must behave as if it were downconverted
>> to "base64" CTE  with respect to BODYSTRUCTURE and FETCH commands.
>
> I don't see how this breaks non-binary clients. If the client doesn't
> do BINARY, it would never issue an APPEND with a <literal8> to
> begin with.

Scenario:
* Client A supports BINARY, Client B doesn't
* Client A does an APPEND using <literal8> of a message with a true binary
  transfer-encoding to a shared IMAP mailbox
* Client B does a BODY FETCH of that message from the IMAP mailbox

Section 4.4 says:
     The server SHOULD NOT perform any content-transfer-encoding conversion
     of the data.

but in this scenario, the server MUST perform a content-transfer-encoding 
in order to maintain compatibility with the IMAP base spec.

>> I'm not fond of BINARYSTRUCTURE.  It results in two syntatically
>> identical  complex FETCH items with subtle semantic differences, neither
>> of which  necessarily reflect the real bodystructure of the message in
>> the store.
>
> I'm not a fan of BINARYSTRUCTURE either, and I like your BINARYSIZES
> proposal a lot better. In fact, I would prefer to remove this altogether,
> however a few people had requested the ability to obtain the BINARY
> fetch size prior to issuing the FETCH. Tony, you were one of the
> proponents of this: could you provide a rationale for this feature?
> Maybe I'm misunderstanding what people actually asking for here.

Then I suggest we remove it altogether now unless someone has a compelling 
reason.  There are two reasons to desire sizes in advance: (1) to know how 
many resources to allocate.  (2) as a trigger for alternate behavior (e.g., 
don't download attachments over 2MB over a modem link).  The existing sizes 
in BODYSTRUCTURE provides an upper-bound for 1 and can be turned into an 
adequate estimate for 2.

	- Chris

Date: Tue, 27 Feb 2001 18:27:29 -0500
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: Lyndon Nerenberg <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: binary draft and APPEND
Sender: [email-masked]

Lyndon Nerenberg wrote:
> 
> > I'm not fond of BINARYSTRUCTURE.  It results in two syntatically identical
> > complex FETCH items with subtle semantic differences, neither of which
> > necessarily reflect the real bodystructure of the message in the store.
> 
> I'm not a fan of BINARYSTRUCTURE either, and I like your BINARYSIZES
> proposal a lot better. In fact, I would prefer to remove this altogether,
> however a few people had requested the ability to obtain the BINARY
> fetch size prior to issuing the FETCH. Tony, you were one of the
> proponents of this: could you provide a rationale for this feature?
> Maybe I'm misunderstanding what people actually asking for here.

No, wasn't me, at least not that I remember. Sorry.

	Tony Hansen
	[email-masked]

From: Lyndon Nerenberg <[email-masked]>
Organization: ACI / Messagingdirect
To: Chris Newman <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: binary draft and APPEND 
Date: Tue, 27 Feb 2001 13:20:22 -0700
Sender: [email-masked]

> I disagree with section 4.4 of this draft on the grounds that it breaks 
> backwards compatibility with IMAP clients that are not binary aware.
> 
> RFC 2060 section 4.3.1 states "Implementations MUST encode binary data into 
> a textual form such as BASE64 before transmitting the data."  I interpret 
> this to mean that any RFC 2060 server implementation which receives a 
> "binary" body part must behave as if it were downconverted to "base64" CTE 
> with respect to BODYSTRUCTURE and FETCH commands.

I don't see how this breaks non-binary clients. If the client doesn't
do BINARY, it would never issue an APPEND with a <literal8> to
begin with.

> No statement should be made about the message store capabilities.  Both 
> implementations (a binary message store which does base64 conversion for 
> BODY fetches, or a non-binary message store which removes base64/QP for 
> BINARY fetches) are valid, IMHO.

You're right. I'll remove that text.

> I'm not fond of BINARYSTRUCTURE.  It results in two syntatically identical 
> complex FETCH items with subtle semantic differences, neither of which 
> necessarily reflect the real bodystructure of the message in the store.

I'm not a fan of BINARYSTRUCTURE either, and I like your BINARYSIZES
proposal a lot better. In fact, I would prefer to remove this altogether,
however a few people had requested the ability to obtain the BINARY
fetch size prior to issuing the FETCH. Tony, you were one of the
proponents of this: could you provide a rationale for this feature?
Maybe I'm misunderstanding what people actually asking for here.

--lyndon

From: Lyndon Nerenberg <[email-masked]>
Organization: ACI / Messagingdirect
To: "Neystadt, John" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: newmail notification protocol 
Date: Mon, 26 Feb 2001 15:36:26 -0700
Sender: [email-masked]

> I am thinking about notification gateway application - for example to
> monitor multiple subscribers accounts and send them sms'es.

SIN (or its successor) isn't the correct solution for this problem.
What you want for this application is to have your local delivery
agent push the SMS messages out.

> Another issue is with availability. How can we enable client to request from
> server to queue events persistently if it currently is not connected to SIN
> server?

You don't. This is a deliberate design decistion. SIN reports event
*triggers* without communicating any context. If you want the
context you get that through the primary application protocol.

--lyndon

Date: Mon, 26 Feb 2001 13:54:52 -0800
From: Chris Newman <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Mark Crispin <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Saturday, February 24, 2001 0:49 -0800 Mark Crispin 
<[email-masked]> wrote:
> Assuming that pejorative terms such as "weakness" are not a requirement,

I'd prefer if all opinions about the severity of the problem were omitted. 
But the problem (that the network bandwidth needed for the SORT/THREAD 
response grows unbounded with the number of messages in the mailbox, unlike 
the FETCH command) should be clearly described.

> Assuming that such a prohibition exists, what about a reference to a
> "separate document dealing with IMAP message set windowing", similar to
> the existing reference to a "separate document dealing with IMAP
> internationalization."?

That's fine.

> If that is out of the way, we can push SORT/THREAD and start windowing.
> You can be assured that the push of SORT/THREAD essentially requires a
> windowing document, just as it requires an i18n document.
>
> Does this work for you?

Close, but not quite.  The problem is that as long as the windowing problem 
remains unsolved, it may be necessary to tweak the existing SORT/THREAD to 
make windowing simpler.  This is particularly risky if we wish to window 
threads, where the windowing and thread hierarchy model will be tightly 
intertwined.  The basic principle of concern: "if you know you're going to 
extend a facility, make sure the facility is designed to accommodate the 
expected extension."  I'm honestly not sure SORT/THREAD meet that test.  So 
here are some options I see:

(A) We put out SORT/THREAD as experimental so that if we have to tweak them 
it's no big deal.

(B) We put out SORT/THREAD as proposed standard, but have a firm agreement 
that if the windowing extension can be made simpler by a tweak to 
SORT/THREAD we'll recycle them at proposed with that tweak.

(C) Let SORT/THREAD sit where they are until we have rough concensus on a 
windowing strawman with a firm level of confidence that we won't need to 
tweak SORT/THREAD.

		- Chris

Date: Mon, 26 Feb 2001 10:49:53 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Chris Newman <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

Chris -

You have made your claims about "non-scalability" of SORT and THREAD many
times.  Considerable first-hand implementation experience, as well as
production operational experience over a period of years, contradicts these
claims.

SORT and THREAD have multiple client and server implementations.  They are
proven to work, and work well enough that servers which don't have the
facility are at a considerable disadvantage compared to those which do.

I have also spent some time talking with developers of MUAs for Palms and
other PDA type devices who indicate that the form of windowing that you
outline is not the direction in what PDA email applications are going.

To the best of my knowledge, you have no first-hand experience with IMAP
clients that use SORT and THREAD.  In fact, I believe that you have not
written an IMAP client at all.  I'm not such if you've talked with PDA
implementors eeither.  If you have such experience, please share it.

There is no evidence that windowing is anything other than a solution in
search of a problem.  I am willing to work on it, for the political reasons if
nothing else.  However, given that windowing is orthogonal to searching,
sorting, and threading, the latter functionalities should not be burdened with
a mandatory-to-implement windowing mechanism.  Windowing should stand or die
on its own (lack of) merit.

The fact that people seriously suggest "punt on windowing THREAD, just window
SORT" indicates to me that the people making such statements aren't directly
involved in what users want.  Threading is what most users want; sorting is
much less interesting if threading is available.

If windowing isn't worth doing right, it's not worth doing.

Date: Fri, 23 Feb 2001 17:44:29 -0800
From: Chris Newman <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Mark Crispin <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Friday, February 23, 2001 15:13 -0800 Mark Crispin 
<[email-masked]> wrote:
> What this indicates is that SORT and THREAD should be published now

As I have for the past several years, I remain opposed to moving SORT and 
THREAD forward on the standards track unless a facility to provide 
scalability on the basis of mailbox size is also complete.

The fact that building such a facility as a separate extension layered on 
top of SORT and THREAD has proved difficult and complex indicates to me 
that SORT and THREAD may not be adequately designed to accommodate 
necessary functionality and thus are not ready to move forward on the 
standards track.

The IESG has decided that IMAP is too complex and doesn't work well enough 
and have indicated there will be significant pushback on IMAP extensions. 
I may disagree with the IESG on the former conclusion (IMAP seems far 
simpler and more interoperable than HTTP to me, especially given it's 
solving a much more complex problem), but we would be ill-advised to move 
forward with extensions when we suspect there's a need for one or more 
"tune up" extensions later.

> I object to kludges being hammered through in a rush for a partial 
solution,

I agree 100% with this statement, and it explains exactly why I don't want 
SORT and THREAD to be moved on the standards track.  SORT and THREAD as 
currently specified are a partial solution since they are not scalable on 
the basis of mailbox size.  I also have some concern about the extra round 
trip they currently require.

		- Chris

From: "Neystadt, John" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: newmail notification protocol 
Date: Mon, 26 Feb 2001 17:11:54 +0200
Sender: [email-masked]

I am thinking about notification gateway application - for example to
monitor multiple subscribers accounts and send them sms'es.

Such a client will need to monitor more than one account.
Current porposed protocol requires to open a SIN connection per account,
which is not scalable.

I propose to extend namespaces within the protocol to include account name.

There is an issue with authentication is such a case. Two options:

1. Allow to authenticate consequently for more than one account. 
2. Allow trusted applications with master password (similiar to Netscape's
PROXYAUTH proprietry extension).

Another issue is with availability. How can we enable client to request from
server to queue events persistently if it currently is not connected to SIN
server?

What do you think?

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

-----Original Message-----
From: Lyndon Nerenberg [mailto:[email-masked]]
Sent: Tue, February 13, 2001 11:42 PM
To: Eric Burger
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: newmail notification protocol 

> I'm wondering if defining a profile for the SIP message waiting protocol
> (draft-mahy-sip-message-waiting-01.txt) wouldn't be a better approach.
> 
> On the one hand, the IMAP server and biff client would only need to
> implement a VERY small subset of SIP.

An interesting idea. A quick scan of the draft makes me think this might
work, although it would be restricted to the email case only.

> In addition, more and more firewalls are SIP-friendly, so you could use
UDP
> (although TCP's an option).

You need authentication in there, otherwise people would be able to
use the SIP service to probe your IMAP server namespace. Since IMAP
uses SASL you'll have to provide at least the same level of security
in SIP as the corresponding IMAP server. This will require some
investigation.

> Work to be done in this case would be on the event profile for subscribing
> to a particular IMAP folder.  That said, that work probably needs to be
done
> anyway for the SIP MWI draft.

Do you want to put up a strawman? While I like SINs generality, the
immediate need is clearly for email, and if an existing protocol can
provide the functionality in a light-weight manner, I'm all for it.

--lyndon

Date: Sun, 25 Feb 2001 22:11:26 -0600
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: So, do we meet?
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2/23/01 at 1:01 PM -0800, Mark Crispin wrote:

>Is it worth meeting if it's only a one-hour session?  Specifically, what
>business do we need to do face-to-face (obviously it isn't much if only an
>hour is needed), and does it need to be attended to at this IETF or can it be
>deferred to the next one?

At this point, I'm inclined to agree. I haven't heard screaming for a 
meeting in Minneapolis, or a list of issues that are currently 
front-burner that can't be addressed on the list. I'd be glad to hear 
that the "usual suspects" who do go to Minneapolis get together for a 
"bar-BOF" to kickstart some work, but unless I hear strong arguments 
otherwise before noon US Eastern Time Monday, we'll leave an official 
meeting until London.

pr

-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Sat, 24 Feb 2001 00:49:27 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Chris Newman <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 23 Feb 2001 16:08:20 -0800, Chris Newman wrote:
> But
> as protocol designers it's our responsibility to make the protocol
> sufficent if a client chooses to support large mailboxes.

I probably have more experience with developing IMAP clients that support
large mailboxes than anyone else.  Even my earliest efforts supported
mailboxes with a number of messages in the 5-digit range (and a lot of popular
clients today collapse before 4-digits).

Scalability is a good thing, but it is possible to take such arguments to
needless extremes.

> An acceptable compromise to me would be:
> SORT/THREAD move onto the standards track at the same time as the windowing
> facility.  SORT/THREAD drafts should note the weakness they have with
> respect to scalability on the basis of mailbox size and include at least a
> non-normative reference to the windowing facility as a way to address the
> problem.

Assuming that pejorative terms such as "weakness" are not a requirement, this
may be a foundation to work on.

The problem with moving them out simultaneously is that it puts us in the
position of simultaneously stalling SORT/THREAD and rushing windowing.  We're
clearly spinning our wheels having three pots on the stove at a time.

Can a reference to a "work in progress" can be in a standards-track document?
Clearly it can't be in a Draft or Full Standard, but I believe that a similar
prohibition exists with a Proposed Standard, right?

Assuming that such a prohibition exists, what about a reference to a "separate
document dealing with IMAP message set windowing", similar to the existing
reference to a "separate document dealing with IMAP internationalization."?

If that is out of the way, we can push SORT/THREAD and start windowing.  You
can be assured that the push of SORT/THREAD essentially requires a windowing
document, just as it requires an i18n document.

Does this work for you?

Date: Sat, 24 Feb 2001 02:53:21 -0500
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: draft-leiba-imap-search-multiple-00.txt
Sender: [email-masked]

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

Sigh... and here's the draft that I didn't attach to the other note.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

--==========290856023==========
Content-Type: text/plain; charset=us-ascii;
 name="draft-leiba-imap-search-multiple-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="draft-leiba-imap-search-multiple-00.txt"; size=6784

Network Working Group                                           B. Leiba
Internet Draft                           IBM T.J. Watson Research Center
Document: draft-leiba-imap-search-multiple-00.txt          February 2001
                                                     Expires August 2001

              IMAP4 SEARCHM Command for Multiple Mailboxes

Status of this Document

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

   A revised version of this draft document will be submitted to the RFC
   editor as an Proposed Standard for the Internet Community. 
   Discussion and suggestions for improvement are requested, and should
   be sent to [email-masked].  This document will expire before 31
   August 2001.  Distribution of this memo is unlimited.

1. Abstract

   The IMAP4 specification allows the searching only of the selected
   mailbox.  A user often wants to search multiple mailboxes, and a
   client that wishes to support this must issue a series of SELECT and
   SEARCH commands, waiting for each to complete before moving on to the
   next.  This extension allows a client to search multiple mailboxes
   with one command, limiting the round-trips and waiting for various
   searches to complete.  This also introduces named searches, allowing
   a client to pipeline the searches if it chooses.

B. Leiba                  Expires August 2001                  [Page 1]

Internet DRAFT    IMAP4 SEARCHM for Multiple Mailboxes     February 2001

2. Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Keywords].

3. The SEARCHM command

   The basic syntax if the SEARCHM command (see the formal grammar for
   the exact syntax) is

          tag SEARCHM "search-name" (options) (list of mailbox URLs)
            (search criteria)

   The mailbox URLs MUST be relative URLs that point to IMAP mailboxes
   on this server; this command does not do referrals.  The URLs MAY
   contain the IMAP mailbox wildcard characters.  The search criteria
   are the same as those specified in [IMAP].

   The search name is used to related the SEARCHM responses to the
   search performed, allowing the client to send multiple SEARCHM
   commands without having to wait for all responses.  The server MAY
   perform those searches in parallel; it MAY instead serialize them.

   The options control the operation of the SEARCHM command.  There is
   one option defined by this document: "depth".  The option "depth(n)"
   causes the SEARCHM command to traverse the hierarchy "n" levels down
   (including the current level).  Thus, "xyz*" with depth(2) and
   "xyz/*" with depth(1) will both match child mailboxes of "xyz", but
   will not match child mailboxes of those children (of course, the
   former will also match "xyzabc", while the latter will not).

   Other options may be defined by extensions.

   The server returns one untagged SEARCHM response for each mailbox
   that matches one or more of the URLs and that has messages that match
   the search criteria.  The server MUST NOT return a SEARCHM response
   that lists no message numbers.  There are also no errors that come
   from unmatched mailbox URLs.

   The command "UID SEARCHM" behaves in an analogous way to "UID SEARCH"
   (see [IMAP]), returning UIDs instead of message numbers.

B. Leiba                  Expires August 2001                  [Page
2]

Internet DRAFT    IMAP4 SEARCHM for Multiple Mailboxes     February 2001

4. Example

   C: tag1 SEARCHM "unseen" (depth(1)) ("folder1" "folder2/*") (unseen)
   C: tag2 SEARCHM "chad" () ("folder1" "folder2/*") (subject "chad")
   S: * SEARCHM "unseen" "folder1" (1 3 5 7 9)
   S: * SEARCHM "chad" "folder1" (1 2 3 4 8)
   S: * SEARCHM "unseen" "folder2/banana" (2 4)
   S: * SEARCHM "unseen" "folder2/peach" (691)
   S: tag1 OK done
   S: * SEARCHM "chad" "folder2/dubya" (3 6 9 12)
   S: tag2 OK done

5. Formal Grammar

   Items not defined here are defined in the formal grammar of [IMAP].

   mailbox_list    ::= 1#mailbox_URL
   mailbox_URL     ::= ???
                       ;; relative URL -- see [IMAPURL]
                       ;; may contain list_wildcards
   searchm         ::= "SEARCHM" SPACE search_name
                                 SPACE "(" search_options ")"
                                 SPACE "(" mailbox_list ")"
                                 SPACE "(" search_criteria ")"
   search_criteria ::= ["CHARSET" SPACE astring SPACE] 1#search_key
   search_name     ::= string
   search_option   ::= "DEPTH(" number ")"
   search_options  ::= 0#search_option
                       ;; a given option may only appear once

6. Security Considerations

   This document describes an IMAP4 command similar to the SEARCH
   command, and has the same security considerations as that command. 
   Those considerations are described in [IMAP].

7. References

   [IMAP]; Crispin, M.; "Internet Message Access Protocol - Version
   4rev1"; RFC 2060; University of Washington; December 1996.

   [IMAPURL]; Newman, C.; "IMAP URL Scheme"; RFC 2192; Innosoft;
   September 1997.

   [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate

B. Leiba                  Expires August 2001                  [Page 3]

Internet DRAFT    IMAP4 SEARCHM for Multiple Mailboxes     February 2001

   Requirement Levels"; RFC 2119; Harvard University; March 1997.

8. Author's Address

   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532

   Phone: 1-914-784-7941
   Email: [email-masked]

B. Leiba                  Expires
August 2001                  [Page 4]

--==========290856023==========--

Date: Sat, 24 Feb 2001 02:51:55 -0500
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: draft-leiba-imap-search-multiple-00.txt
Sender: [email-masked]

I've just submitted the attached draft to the I-D editor.  May we discuss
it here?  I think it's out of the working group's charter, unless Pete
thinks it should be in, and so I submitted it as an individual draft.  But
since the IMAP mailing list is almost useless now, having turned into the
UW-IMAP implementation discussion mailing list, I hope the WG Chair won't
mind our discussing it here.

It proposes a SEARCHM command that allows a few things:
1. named searches, so a client may have multiple SEARCHM commands pending
at once, and can relate the responses to the search that caused them,
2. the ability to search multiple mailboxes in one command, and
3. the ability to use mailbox URLs to name the mailboxes.

In order to get it out in time, I didn't specify a few things that I do
want to specify in an update, so I'll outline them here.

First, I'm looking for whether we want to put the "mailbox name/list in URL
format" syntax into the "list extensions" draft, as we're currently
planning (I plan to have an update to that, incorporating the discussion
leading up to and in San Diego, next week), or whether we want to pull it
out as a separate draft and refer to it in both list extensions and SEARCHM.

Second, I want to be clear that the ability to search multiple mailboxes,
and, in particular, the use of wildcards, can be hazardous.  I intend to
add words indicating that a server MAY (SHOULD?) limit the number of
mailboxes that may be searched with one command, and, in fact, that the
server SHOULD reject the specification of "*".  The intent here is more to
allow a search like "inbox/*" to search a mailbox and its sub-mailboxes.
Of course, that can still get weird -- for instance, searching
"#news.alt.*" -- and therefore the server MAY/SHOULD limit it.  So I'm
looking for opinions here on what to say and how to say it.

Finally, I'm particularly looking for feedback from the client developers
about whether this is something you'd use.  For server developers, remember
that a client *can* currently do this with a series of SELECT and SEARCH
commands, and this is an attempt to be more efficient about it, and,
especially, to be easier on lightweight clients.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Fri, 23 Feb 2001 17:51:24 -0800
To: Cyrus Daboo <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: So, do we meet?
Sender: [email-masked]

At 11:17 AM -0500 2/23/01, Cyrus Daboo wrote:

>
>  draft-ietf-imapext-regex-00.txt
>   Status?

I'd like to get an update out, but I may not be able to do so 
before the deadline.

Also, I'm still waiting to hear if I can attend.  (If not, this 
will be the first I've missed a long time.)  Right now it doesn't 
look good.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Nice guys finish last, but we get to sleep in.  --Evan Davis

Date: Fri, 23 Feb 2001 16:08:20 -0800
From: Chris Newman <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Mark Crispin <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Friday, February 23, 2001 15:01 -0800 Mark Crispin 
<[email-masked]> wrote:
> Whether or not "a windowing facility is absolutely necessary" is a matter
> of opinion.  The need is speculative; it assumes the advent of a class of
> clients which will behave that way.

Obviously we can't force clients to write scalable implementations.  Plenty 
of clients still do a "FETCH 1:* <whatever>" regularly without need.  But 
as protocol designers it's our responsibility to make the protocol 
sufficent if a client chooses to support large mailboxes.

> I'm willing to work on the design of a windowing facility (and have), but
> not at the cost of forcing it upon unwilling implementations.

An acceptable compromise to me would be:

SORT/THREAD move onto the standards track at the same time as the windowing 
facility.  SORT/THREAD drafts should note the weakness they have with 
respect to scalability on the basis of mailbox size and include at least a 
non-normative reference to the windowing facility as a way to address the 
problem.

I believe that meets your requirement.

		- Chris

Date: Fri, 23 Feb 2001 16:09:51 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: So, do we meet?
To: Chris Newman <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 23 Feb 2001 15:11:57 -0800, Chris Newman wrote:
> >> draft-ietf-imapext-acl-01.txt
> >>   Status?
> I suggest the chair nag the document editor directly to get a revision out.

It was decided at San Diego that the document editor work with me to address
the concerns I've raised about the current ACL framework.  To date, this has
not happened.  I'll take some of the blame for this; but it's nevertheless
premature to talk about a revised document without determining the nature of
the revisions.

Date: Fri, 23 Feb 2001 15:13:26 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 23 Feb 2001 18:10:11 -0500, Lawrence Greenfield wrote:
> Windowing SORT seems to be simple, so can we do the simple thing and
> publish it?

The windowing facility must not forced into SORT:
 1) A client must not do a new SORT simply to move through the window.
 2) The dynamic update problem precludes windowing as part of an existing
    SEARCH-class command (SEARCH, SORT, and THREAD) because the input is
    dynamic.

Windowing must be through a static set.  Otherwise, you'll get inexplicable
user interface behavior because of an update happening underneath.  The result
will be a protocol feature that clients can't use but servers are forced to
implement anyway.

> The engineering problem left is coming up with windowing for THREAD.
> Unless this problem is intractable, we might as well solve it before
> publishing the THREAD document.

The three problems with putting windowing in THREAD are:
 1) the tree-address problem, unique to threading
 2) the new-THREAD simply to move through the window problem, shared by
     SEARCH and SORT
 3) the dynamic update problem, shared by SEARCH and SORT

What this indicates is that SORT and THREAD should be published now, and
windowing addressed separately in a way that addresses all known problems.  If
windowing is to happen, there should be a single form of windowing.  Not SORT
windowing that works differently from THREAD windowing because some people
wanted a quick-and-dirty solution for SORT and didn't want to think about
THREAD.

For example, a separate VIEW mechanism:
 1) can solve the tree-address problem if there is sober reflection upon what
     the windowing parameters are
 2) addresses the new SEARCH/SORT/THREAD just to move through the window
     problem, by having a preliminary "set view" operation
 3) addresses the dynamic update problem by having a static data set.

There is no need to rush through a windowing solution in order to get SORT and
THREAD published.  The only "need" is a fear that maybe windowing won't ever
happen unless it's piggy-backed on SORT and THREAD.  If windowing is as vital
as its supporters claim, then windowing will happen even if SORT and THREAD
are published first.

I object to kludges being hammered through in a rush for a partial solution,
particularly if the kludge is shoehorned into an orthogonal mechanism.

Date: Fri, 23 Feb 2001 15:11:57 -0800
From: Chris Newman <[email-masked]>
Subject: Re: So, do we meet?
To: Mark Crispin <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Friday, February 23, 2001 13:01 -0800 Mark Crispin 
<[email-masked]> wrote:
>> draft-crispin-imapv-14.txt
>>   Base-spec bug fixes. Last call 4-Jan-2001. Presumably this can now move
>> forward, or have there been corrections that require it to be re-issued?
>
> I wish that I knew the answer to this, although this isn't an IMAPEXT
> issue. Every time we talk about putting it forward, some specious issue
> comes up that kicks it back.

I'd prefer to see the vagueness of the 8-bit issue and 822 compliance 
clarified, particularly if we're planning to move in the direction of UTF-8 
headers in the future.  But I could live with deferring that clarification 
to the draft standard revision since this is just a recycle at proposed 
status.  Also, since it's an individual submission Mark can just ask for a 
4-week last call if he thinks it's ready.

>> draft-crispin-imap-multiappend-03.txt
>>   Last call 4-Jan-2001. Status?
>
> Can we clear this from the table by unanimous consent to move it forward,
> on the grounds that there are multiple client/server implementations and
> no stated reasons for not doing so?

I just read it.  Looks ready to move to me.  Mark, why don't you just send 
email to the ADs and [email-masked] asking for a 4-week last call?

>> draft-ietf-imapext-sort-06.txt
>> draft-ietf-imapext-thread-06.txt
>> draft-ietf-imapext-view-00.txt
>>   There are now multiple client/server implementations of sort and thread
>> and more people looking to add these to their implementations. Its
>> therefore important we get some kind of consensus on these moving
>> forward. Also, I'm still unsure as to what other people really want from
>> VIEW. There's hasn't been much feedback after my last post.
>
> The lack of feedback strongly suggests to me that we should move forward
> on SORT and THREAD, and let VIEW languish until/unless there is sufficient
> interest.

I'm very uncomfortable moving SORT and THREAD forward without a facility to 
provide scalability on the basis of mailbox size (e.g., windowing).  If the 
rest of the WG wants to move them forward, I won't block rough concensus 
but I will express my concerns to the IESG during last call.

>> draft-ietf-imapext-acl-01.txt
>>   Status?

I suggest the chair nag the document editor directly to get a revision out.

		- Chris

Date: Fri, 23 Feb 2001 15:01:01 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Chris Newman <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 23 Feb 2001 14:50:44 -0800, Chris Newman wrote:
> After having done the engineering exercise, I concur with Mark that we
> shouldn't bother with dynamic update.  The complexity it creates doesn't
> seem to be worth the benefit.

This was the conclusion at the last IETF in San Diego.  I'm actually neutral
about dynamic updating, but accepted that decision.

> A windowing facility is absolutely necessary.  Particularly if we don't do
> the dynamic update facility, then the mechanism the client will use to
> update its view is to re-issue the SORT/THREAD operation.  That makes it
> especially important for scalability by mailbox size that the client gets
> only what it needs rather than information for the entire mailbox.

Whether or not "a windowing facility is absolutely necessary" is a matter of
opinion.  The need is speculative; it assumes the advent of a class of clients
which will behave that way.

I'm willing to work on the design of a windowing facility (and have), but not
at the cost of forcing it upon unwilling implementations.

Date: Fri, 23 Feb 2001 18:10:11 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: VIEW was Re: Progress? Meeting?
Sender: [email-masked]

   Date: Fri, 23 Feb 2001 14:50:44 -0800
   From: Chris Newman <[email-masked]>

   After having done the engineering exercise, I concur with Mark that we 
   shouldn't bother with dynamic update.  The complexity it creates doesn't 
   seem to be worth the benefit.

   A windowing facility is absolutely necessary.  Particularly if we don't do 
   the dynamic update facility, then the mechanism the client will use to 
   update its view is to re-issue the SORT/THREAD operation.  That makes it 
   especially important for scalability by mailbox size that the client gets 
   only what it needs rather than information for the entire mailbox.

I agree with this.  

Windowing SORT seems to be simple, so can we do the simple thing and
publish it?

The engineering problem left is coming up with windowing for THREAD.
Unless this problem is intractable, we might as well solve it before
publishing the THREAD document.

Larry

Date: Fri, 23 Feb 2001 14:50:44 -0800
From: Chris Newman <[email-masked]>
Subject: Re: VIEW was Re: Progress? Meeting?
To: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

After having done the engineering exercise, I concur with Mark that we 
shouldn't bother with dynamic update.  The complexity it creates doesn't 
seem to be worth the benefit.

A windowing facility is absolutely necessary.  Particularly if we don't do 
the dynamic update facility, then the mechanism the client will use to 
update its view is to re-issue the SORT/THREAD operation.  That makes it 
especially important for scalability by mailbox size that the client gets 
only what it needs rather than information for the entire mailbox.

A 1 hour meeting might be helpful.

		- Chris

Date: Fri, 23 Feb 2001 13:01:00 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: So, do we meet?
To: Cyrus Daboo <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 23 Feb 2001 11:17:12 -0500, Cyrus Daboo wrote:
> My vote is yes. Maybe we only need a one hour session rather than two?

Is it worth meeting if it's only a one-hour session?  Specifically, what
business do we need to do face-to-face (obviously it isn't much if only an
hour is needed), and does it need to be attended to at this IETF or can it be
deferred to the next one?

> draft-crispin-imapv-14.txt
>   Base-spec bug fixes. Last call 4-Jan-2001. Presumably this can now move
> forward, or have there been corrections that require it to be re-issued?

I wish that I knew the answer to this, although this isn't an IMAPEXT issue.
Every time we talk about putting it forward, some specious issue comes up that
kicks it back.

> draft-crispin-imap-multiappend-03.txt
>   Last call 4-Jan-2001. Status?

Can we clear this from the table by unanimous consent to move it forward, on
the grounds that there are multiple client/server implementations and no
stated reasons for not doing so?

> draft-ietf-imapext-sort-06.txt
> draft-ietf-imapext-thread-06.txt
> draft-ietf-imapext-view-00.txt
>   There are now multiple client/server implementations of sort and thread
> and more people looking to add these to their implementations. Its
> therefore important we get some kind of consensus on these moving forward.
> Also, I'm still unsure as to what other people really want from VIEW.
> There's hasn't been much feedback after my last post.

The lack of feedback strongly suggests to me that we should move forward on
SORT and THREAD, and let VIEW languish until/unless there is sufficient
interest.

> draft-ietf-imapext-acl-01.txt
>   Status?

I never was contacted.  My proposed solution leverages on the LIST extensions
work.

Date: Fri, 23 Feb 2001 12:07:08 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: So, do we meet?
Sender: [email-masked]

Cyrus Daboo wrote:

> --On Friday, February 23, 2001 09:35:37 AM -0600 Pete Resnick
> <[email-masked]> wrote:
>
> > OK, the deadline approaches. I have heard several people say they should
> > have drafts ready. Am I to believe from that we will have things to
> > discuss?
> >
> > Shall we meet in Minneapolis? Yay or nay?
>
> My vote is yes.

I am second to say yes.

> Maybe we only need a one hour session rather than two?
>
> There are a number of drafts that are close to last call status IMHO - some
> of them aren't strictly in our charter but we are marshalling them through,
> right. It would be good to have a summary of all the drafts in progress and
> their current status so we can see where we're going with them.
>
> Here's my summary of all IMAP related drafts:
>
> draft-crispin-imapv-14.txt
>   Base-spec bug fixes. Last call 4-Jan-2001. Presumably this can now move
> forward, or have there been corrections that require it to be re-issued?
>
> draft-crispin-imap-multiappend-03.txt
>   Last call 4-Jan-2001. Status?
>
> draft-ietf-imapext-sort-06.txt
> draft-ietf-imapext-thread-06.txt
> draft-ietf-imapext-view-00.txt
>   There are now multiple client/server implementations of sort and thread
> and more people looking to add these to their implementations. Its
> therefore important we get some kind of consensus on these moving forward.
> Also, I'm still unsure as to what other people really want from VIEW.
> There's hasn't been much feedback after my last post.
>
> draft-ietf-imapext-annotate-00.txt
>   Randy's working on an update.
>
> draft-ietf-imapext-acl-01.txt
>   Status?
>
> draft-ietf-imapext-regex-00.txt
>   Status?
>
> draft-ietf-imapext-list-extensions-00.txt
>   Status?
>
> draft-nerenberg-imap-binary-02.txt
>   New draft posted 15-Feb-2001
>
> draft-melnikov-imap-mdn-03.txt
>   Status?

I would like to publish it as Informational or BCP. It is probably time for
Last Call.

I've just submitted a new draft ietf-melnikov-imap-condstore-00.txt. It should
appear in draft repository shortly.

I've also submitted a new revision of LANGUAGE draft (I am co-author now).

Alexey

Date: Fri, 23 Feb 2001 11:17:12 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: So, do we meet?
Sender: [email-masked]

--On Friday, February 23, 2001 09:35:37 AM -0600 Pete Resnick 
<[email-masked]> wrote:

> OK, the deadline approaches. I have heard several people say they should
> have drafts ready. Am I to believe from that we will have things to
> discuss?
>
> Shall we meet in Minneapolis? Yay or nay?

My vote is yes. Maybe we only need a one hour session rather than two?

There are a number of drafts that are close to last call status IMHO - some 
of them aren't strictly in our charter but we are marshalling them through, 
right. It would be good to have a summary of all the drafts in progress and 
their current status so we can see where we're going with them.

Here's my summary of all IMAP related drafts:

draft-crispin-imapv-14.txt
  Base-spec bug fixes. Last call 4-Jan-2001. Presumably this can now move 
forward, or have there been corrections that require it to be re-issued?

draft-crispin-imap-multiappend-03.txt
  Last call 4-Jan-2001. Status?

draft-ietf-imapext-sort-06.txt
draft-ietf-imapext-thread-06.txt
draft-ietf-imapext-view-00.txt
  There are now multiple client/server implementations of sort and thread 
and more people looking to add these to their implementations. Its 
therefore important we get some kind of consensus on these moving forward. 
Also, I'm still unsure as to what other people really want from VIEW. 
There's hasn't been much feedback after my last post.

draft-ietf-imapext-annotate-00.txt
  Randy's working on an update.

draft-ietf-imapext-acl-01.txt
  Status?

draft-ietf-imapext-regex-00.txt
  Status?

draft-ietf-imapext-list-extensions-00.txt
  Status?

draft-nerenberg-imap-binary-02.txt
  New draft posted 15-Feb-2001

draft-melnikov-imap-mdn-03.txt
  Status?

-- 
Cyrus Daboo

Date: Fri, 23 Feb 2001 09:35:37 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: So, do we meet?
Sender: [email-masked]

OK, the deadline approaches. I have heard several people say they 
should have drafts ready. Am I to believe from that we will have 
things to discuss?

Shall we meet in Minneapolis? Yay or nay?

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Wed, 21 Feb 2001 16:59:17 -0800
From: Chris Newman <[email-masked]>
Subject: binary draft and APPEND
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Thursday, February 15, 2001 14:22 -0700 Lyndon Nerenberg 
<[email-masked]> wrote:
> This memo defines the BINARY extension to the Internet Message
> Access Protocol [IMAP4rev1].  It provides a mechanism for IMAP4
> clients and servers to exchange data encoded with the MIME BINARY
> content-transfer-encoding.

I disagree with section 4.4 of this draft on the grounds that it breaks 
backwards compatibility with IMAP clients that are not binary aware.

RFC 2060 section 4.3.1 states "Implementations MUST encode binary data into 
a textual form such as BASE64 before transmitting the data."  I interpret 
this to mean that any RFC 2060 server implementation which receives a 
"binary" body part must behave as if it were downconverted to "base64" CTE 
with respect to BODYSTRUCTURE and FETCH commands.  Arguably this only 
applies if the body part with a "binary" Content-Transfer-Encoding is 
"binary" by the IMAP definition (contains a NUL or excessive CTL 
characters).

I would say:

(1) If the client does a BINARY fetch of a message it stored with a binary 
APPEND, the message MUST be unchanged.  (A "SHOULD" would be acceptable, 
but I prefer "MUST").

(2) If the client does a BODY fetch of a message it stored with a binary 
APPEND, any body parts which had a binary CTE MUST be returned using a 
content-transfer-encoding such as base64 if necessary to comply with 
section 4.3.1 of RFC 2060.

No statement should be made about the message store capabilities.  Both 
implementations (a binary message store which does base64 conversion for 
BODY fetches, or a non-binary message store which removes base64/QP for 
BINARY fetches) are valid, IMHO.

I'm not fond of BINARYSTRUCTURE.  It results in two syntatically identical 
complex FETCH items with subtle semantic differences, neither of which 
necessarily reflect the real bodystructure of the message in the store.  It 
could mislead a client to believe a part had a binary CTE when it was 
originally delivered to the store with a base64 CTE.  If such a body part 
were in a multipart/signed, there's a serious problem.  As a 
counter-proposal, I suggest a fetch item BINARYSIZES, which returns a list 
of "body part section id", "body part size after CTE removed" pairs.

		- Chris

From: "Eric Burger" <[email-masked]>
To: "Lyndon Nerenberg" <[email-masked]>, "Pete Resnick" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Progress? Meeting? 
Date: Wed, 21 Feb 2001 11:28:38 -0500
Importance: Normal
Sender: [email-masked]

I know we need CHANNEL, so I wouldn't mind if the WG takes it up...

> -----Original Message-----
[snip]
> CHANNEL is taking longer than I hoped. I'll have *something* out in
> time for IETF50, and I fully expect there will be discussion on it, but
> the mailing list should be fine (i.e. we don't need WG meeting time).
> Again, the issue of WG charter is up in the air, though. Is the WG
> going to adopt CHANNEL (and BINARY) or not?
> 
> --lyndon

Date: Tue, 20 Feb 2001 17:14:47 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: VIEW was Re: Progress? Meeting?
To: Cyrus Daboo <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 20 Feb 2001 20:07:52 -0500, Cyrus Daboo wrote:
> Is there really ANY interest in the VIEW mechanism at all, or should we
> just add the equivalent functionality directly into SORT and THREAD as
> needed?

My opinion has always been that the functionality is a solution in search of a
problem, presented by people who have little or no practical experience with
server-based sorting and threading.

If there is any interest in the functionality, then it must be in its own
mechanism.  It's a fantasy to believe that adding it to SEARCH, SORT, and
THREAD directly will accomplish windowing of results; each subsequent command
will change the data in unpredictable ways which will break windowing.

Sure, you want updates, but it is vitally important to update and window
independently.  Otherwise, you get client behavior that would suck so badly
that it would kill SORT and THREAD for everybody.

The necessary parts of VIEW is:
 1) a command to set the view -- that is, to load the message set used by the
    other commands
 2) a command to window through the view.
 3) a command to update the VIEW.

Part (2) needs more than "first position to return and number of results to
return".  You need some form of "window including message <n>, positioned <m>
lines from the top [or bottom]".  The functionality is useless without this.

Part (3) is what has everybody hung up.  Updating the view can be as basic an
opportunity as doing (1) over again and tossing out what you knew before.  A
more advanced implementation of (3) would have "insertion" and "removal"
operators.

I suspect that "simple is better".  Since SORT and THREAD are SEARCH-class
commands, untagged EXPUNGE can't happen during SORT/THREAD.  So, a static VIEW
(that requires a new VIEW-set to update) is viable.  It's probably better to
stick with that position for now, and add fancier stuff later.

Date: Tue, 20 Feb 2001 20:07:52 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: VIEW was Re: Progress? Meeting?
Sender: [email-masked]

--On Monday, February 19, 2001 02:22:30 PM -0600 Pete Resnick 
<[email-masked]> wrote:

> I have seen little progress on this list on WG documents since the last
> meeting. Do we need to meet at Minneapolis? What progress is being made?
>

With regards to VIEW, I've been trying to figure out the best way to revise 
it in light of the comments in San Diego. As I recollect we decided that 
VIEW is too complicated and that a lightweight solution to windowing for 
SORT/THREAD is a better approach.

Having implemented support for SORT/THREAD in Mulberry after that meeting, 
here is what I see as important for VIEW (please comment):

1) Windowing of results from SORT/THREAD/SEARCH commands.
2) Mechanism to allow quick discovery of the position of new messages in 
the SORT/THREAD order.

(1) Can be implemented with a simple command modifier for the 
SORT/THREAD/SEARCH commands that allows the client to specify the window 
for the results:

a VIEW WINDOW 10 100 SORT SUBJECT SEARCH UNSEEN

The first number is the first position to return, the second number the 
number of results to return. This may require some specialisation to cope 
with the hierarchical nature of thread results.

(2) is somewhat harder, but I see it as important for removing the need to 
re-issue full/partial sorts just to get the positions of new messages. I'm 
not sure what the best approach is here. Given that the thread structure 
can change significantly with the arrival of a new message it might be 
better to apply this only to SORT. In which case a SORT2 command might be 
better than trying to come up with some mechanism based on VIEW.

Are there any thoughts on this?

Is there really ANY interest in the VIEW mechanism at all, or should we 
just add the equivalent functionality directly into SORT and THREAD as 
needed?

-- 
Cyrus Daboo

From: Lyndon Nerenberg <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Progress? Meeting? 
Organization: ACI / MessagingDirect
Date: Tue, 20 Feb 2001 14:10:59 -0700
Sender: [email-masked]

Pete Resnick wrote:

> I have seen little progress on this list on WG documents since the
> last meeting. Do we need to meet at Minneapolis? What progress is
> being made?

BINARY came out a couple of days ago. I haven't heard anything about
getting it issued as a WG document. Unless something major jumps out
I don't see a need for another draft, so I don't think this really
matters. (Modulo some editorial changes I think the draft is ready
for last call.)

CHANNEL is taking longer than I hoped. I'll have *something* out in
time for IETF50, and I fully expect there will be discussion on it, but
the mailing list should be fine (i.e. we don't need WG meeting time).
Again, the issue of WG charter is up in the air, though. Is the WG
going to adopt CHANNEL (and BINARY) or not?

--lyndon

Date: Tue, 20 Feb 2001 13:51:13 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Progress? Meeting?
Sender: [email-masked]

Pete Resnick wrote:

> I have seen little progress on this list on WG documents since the
> last meeting. Do we need to meet at Minneapolis? What progress is
> being made?

Give me few days to submit MODTIME (conditional store) draft.

Alexey

Date: Tue, 20 Feb 2001 12:15:08 -0800
To: Pete Resnick <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: Progress? Meeting?
Sender: [email-masked]

I'm trying to get an updated Annotations draft done shortly.

Date: Mon, 19 Feb 2001 14:22:30 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Progress? Meeting?
Sender: [email-masked]

I have seen little progress on this list on WG documents since the 
last meeting. Do we need to meet at Minneapolis? What progress is 
being made?

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

From: Edward Hibbert <[email-masked]>
To: [email-masked]
Subject: Extending STATUS command?
Date: Mon, 19 Feb 2001 18:41:58 -0000
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C09AA3.A3B32FB0
Content-Type: text/plain;
	charset="iso-8859-1"

We have a requirement to expose the number of Urgent messages in a folder to
a custom IMAP client.  Now, I know that "Urgent" isn't necessarily a
well-defined concept - but that's ok as long the concept on my server is the
same as the custom client.

So, what I'm looking for is advice on is the best way of exposing this info.
My current leanings are towards extending the STATUS command to allow an
extra data item to be requested (in RFC2060 6.3.10 it says "the currently
defined STATUS data items are..." and gives an exhaustive list), because
that fits best with the processing that the client is doing at the time - it
would be more efficient for my server than forcing the client to do a SELECT
and SEARCH.  It also seems to fit with the existing MESSAGES, RECENT and
UNSEEN data items.

To do this properly, I guess I would produce an extension which publicised
the server's ability to accept this extra data item in STATUS, though I
could put my conscience to one side and assume that nobody else is going to
ask for it :-).

Do any of you have any advice or other suggestions for how to implement
this?

Edward Hibbert 
Internet Applications Group 
Data Connection Ltd 
Tel:    +44 131 662 1212                Fax:    +44 131 662 1345 
Email:  eh <mailto:[email-masked]> @dataconnection.com   Web:
http://www.dat <http://www.dat> aconnection.com 

------_=_NextPart_001_01C09AA3.A3B32FB0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<P><FONT color=#ff00ff><FONT size=2><FONT face=Arial>We have a requirement to 
expose the number of Urgent messages in a folder to a custom IMAP client.&nbsp; 
Now, I know that "Urgent" isn't necessarily a well-defined concept - but that's 
ok as long the concept on my server is the same as the custom client.<BR><BR>So, 
what I'm looking for is advice on is the best way of exposing this info.&nbsp; 
My current leanings are towards extending the STATUS command to allow an extra 
data item to be requested (in RFC2060 6.3.10 it says "the currently defined 
STATUS data items are..." and gives an exhaustive list), because that fits best 
with the processing that the client is doing at the time - it would be more 
efficient for my server than forcing the client to do a SELECT and SEARCH.&nbsp; 
It also seems to fit with the existing MESSAGES, RECENT and UNSEEN data 
items.<BR><BR>To do this properly, I guess I would produce an extension which 
publicised the server's ability to accept this extra data item in STATUS, though 
I could put my conscience to one side and assume that nobody else is going to 
ask for it :-).<BR><BR>Do any of you have any advice or other suggestions for 
how to implement this?<BR></FONT><BR></FONT></FONT><FONT size=2><FONT 
color=#000000 face=Arial>Edward Hibbert</FONT> <BR><FONT color=#000000 
face=Arial>Internet Applications</FONT> <FONT color=#000000 
face=Arial>Group</FONT> <BR><U><FONT color=#000000 face=Arial>Data Connection 
Ltd</FONT></U> <BR><FONT color=#000000 face=Arial>Tel:&nbsp;&nbsp;&nbsp; 
+44</FONT> <FONT color=#000000 face=Arial>131 662 
1212</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT color=#000000 
face=Arial>Fax:&nbsp;&nbsp;&nbsp; +44</FONT> <FONT color=#000000 face=Arial>131 
662 1345</FONT> <BR><FONT color=#000000 face=Arial>Email:&nbsp;</FONT> <FONT 
color=#000000 face=Arial><A href="mailto:[email-masked]">eh</FONT><FONT 
color=#000000 face=Arial>@dat</FONT><FONT color=#000000 
face=Arial>aconnection.com</A></FONT>&nbsp;&nbsp; <FONT color=#000000 
face=Arial>Web</FONT><FONT color=#000000 
face=Arial>:</FONT>&nbsp;&nbsp;&nbsp;<U> <FONT color=#0000ff face=Arial><A 
href="http://www.dat" target=_blank>http://www.dat</A></FONT><FONT color=#0000ff 
face=Arial>aconnection.com</FONT></U> </FONT></P></BODY></HTML>

------_=_NextPart_001_01C09AA3.A3B32FB0--

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-nerenberg-imap-binary-02.txt (fwd)
Organization: ACI / MessagingDirect
Content-Description: IMAP Binary draft v2
Date: Thu, 15 Feb 2001 14:22:14 -0700
Sender: [email-masked]

Delivery-Date: Thu Feb 15 13:36:32 2001
To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nerenberg-imap-binary-02.txt
Date: Thu, 15 Feb 2001 06:47:03 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 Binary Content Extension
	Author(s)	: L. Nerenberg
	Filename	: draft-nerenberg-imap-binary-02.txt
	Pages		: 7
	Date		: 14-Feb-01
	
This memo defines the BINARY extension to the Internet Message
Access Protocol [IMAP4rev1].  It provides a mechanism for IMAP4
clients and servers to exchange data encoded with the MIME BINARY
content-transfer-encoding.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nerenberg-imap-binary-02.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-nerenberg-imap-binary-02.txt".

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-nerenberg-imap-binary-02.txt

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

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

--OtherAccess--

--NextPart--

From: Lyndon Nerenberg <[email-masked]>
To: "Eric Burger" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: newmail notification protocol 
Organization: ACI Worldwide - MessagingDirect
Date: Tue, 13 Feb 2001 14:41:30 -0700
Sender: [email-masked]

> I'm wondering if defining a profile for the SIP message waiting protocol
> (draft-mahy-sip-message-waiting-01.txt) wouldn't be a better approach.
> 
> On the one hand, the IMAP server and biff client would only need to
> implement a VERY small subset of SIP.

An interesting idea. A quick scan of the draft makes me think this might
work, although it would be restricted to the email case only.

> In addition, more and more firewalls are SIP-friendly, so you could use UDP
> (although TCP's an option).

You need authentication in there, otherwise people would be able to
use the SIP service to probe your IMAP server namespace. Since IMAP
uses SASL you'll have to provide at least the same level of security
in SIP as the corresponding IMAP server. This will require some
investigation.

> Work to be done in this case would be on the event profile for subscribing
> to a particular IMAP folder.  That said, that work probably needs to be done
> anyway for the SIP MWI draft.

Do you want to put up a strawman? While I like SINs generality, the
immediate need is clearly for email, and if an existing protocol can
provide the functionality in a light-weight manner, I'm all for it.

--lyndon

Date: Tue, 13 Feb 2001 12:55:33 -0800
From: Chris Newman <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: newmail notification protocol
Sender: [email-masked]

A few suggestions:

(1) Call it "Mail Check Protocol" (or similar) rather than "Simple Internet 
Notifications" and merge the two documents.  The chances of getting a 
generic notification protocol through the IETF process given the current 
furor over instant messaging is very low.  Don't repeat the political 
mistake we made when we generalized IMSP to ACAP.  Focus only on the 
problem you need to solve, generalization can come later.

(2) Use URLs to represent the objects.  Creating a new namespace is always 
problematic -- look at all the mistakes we made in IMAP namespaces.  URLs 
are a fairly well understood namespace with known problems and provide 
plenty of room for extensibility.  There is already a defined syntax for 
POP and IMAP URLs so you can leverage that work.  You can provide a base 
URL in the greeting if you
want to keep the object names shorter.  Besides, I don't consider it 
desirable to let IMAP modified UTF-7 leak outside the IMAP protocol itself 
and IMAP URLs already solve that problem.

(3) Please rename "EXIT" to "BYE".  No need for gratuitous differences from 
IMAP and it's always nice if all the responses have different first letters 
:-).

(4) Is there some reason you only allow one profile?  If I were monitoring 
for both new mail and an address book, I might want multiple profiles.

Otherwise this looks pretty good from a cursory review.

		- Chris

From: Lyndon Nerenberg <[email-masked]>
To: Pete Maclean <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: newmail notification protocol 
Organization: ACI Worldwide - MessagingDirect
Date: Tue, 13 Feb 2001 12:36:26 -0700
Sender: [email-masked]

> Do you mean to exclude the possibility that other events MAY generate an 
> EVENT event notification?

Yes. If you want more that just newmail you would define a new
application profile for that.

> I see there bring value in a more granular specification of events.  One 
> client might, for example, be interested only in the introduction of an 
> unread message while another, say one that maintains a replica of the 
> folder, might want to know about any old change at all.  Is there an 
> intention to specifically not go to this level of detail?

Yes, that's the intention. SIN is meant to be SIMPLE. It's also meant
very specifically to NOT duplicate functionality available elsewhere.
The typical IMAP scenario as I see it is:

1. MUA connects via IMAP, does folder discovery, builds a list of
  interesting folders.
2. MUA connects via SIN, registers WATCHes on the interesting folders,
  then closes the IMAP channels (most IMAP channels, anyway).
3. SIN reports an EVENT on a folder
4. MUA decides if it wants further info, and issues IMAP commands as
  required (possibly opening new IMAP connections)

In this context, SIN is a "helper" protocol. My expectation is that
SIN engines would be imbedded into applications along side other
"primary" protocols. This is why I'm rather adamant about not overloading
SIN with anything more than simple "something happened" functionality.
If you want more than that, we already have SNMP.

> It seems to me that notifications relating to the Inbox might valuably be 
> excluded since IMAP demands that such a folder exist.  This would allow the 
> possibility of monitoring an Inbox without the overhead of providing a 
> password.

No, this would allow for authentication namespace discovery by
unauthorized people.

> Do you think it would make any sense to extend the protocol to check for 
> changes that occurred prior to the SIN session?  Perhaps to obtain the time 
> that the last change was made to a folder?

I did, briefly, and decided against it. Again, this is functionality that
can be accomplished outside of SIN. (In the IMAP example above, this would
happen during step 1.)

The fundamental concept of the protocol is: simple simple simple. If I
cannot hold your feet to the fire for five minutes as you justify each
piece of the protocol (and profile), it should be thrown out. We already
have a fine assortment of bloated protocols to chose from.

--lyndon

Date: Tue, 13 Feb 2001 11:10:20 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Bounced mail to this list
Sender: [email-masked]

A flurry of legitimate mail sent to this list was bounced due to the 
"only subscribers can post" rules. If you respond to any of these, 
please change the subject line of this message.

--Paul Hoffman

>From owner-ietf-imapext  Tue Feb 13 07:43:22 2001
Date: Tue, 13 Feb 2001 10:42:38 -0500
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
From: Pete Maclean <[email-masked]>
Subject: Re: newmail notification protocol
Cc: [email-masked]

  >> 4.3.  Conjestion Control

Surely you gest!

Sorry, I just could not resist that.

Pete

>From owner-ietf-imapext  Tue Feb 13 08:10:05 2001
Date: Tue, 13 Feb 2001 11:09:29 -0500
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
From: Pete Maclean <[email-masked]>
Subject: Re: newmail notification protocol
Cc: [email-masked]

I have a couple of questions about the IMAP4 Application Profile.

>6. Event Triggers
>
>       Introduction of any message into a monitored object (folder) MUST
>       generate an EVENT event notification.

Do you mean to exclude the possibility that other events MAY generate an
EVENT event notification?

I see there bring value in a more granular specification of events.  One
client might, for example, be interested only in the introduction of an
unread message while another, say one that maintains a replica of the
folder, might want to know about any old change at all.  Is there an
intention to specifically not go to this level of detail?

>7. Security Considerations
>
>       Servers MUST perform all operations in the security context of the
>       authenticated entity. Servers MUST NOT expose any information about
>       the IMAP4 folder namespace that would not be available if the same
>       credentials were used to connect to the IMAP4 server.
>
>       Servers MUST NOT send notification events (including LOST
>       responses) for a folder unless the authentication and authorization
>       credentials used for the SIN session, if used to connect to the
>       IMAP4 server, would allow a successful IMAP4 SELECT on that folder.

It seems to me that notifications relating to the Inbox might valuably be
excluded since IMAP demands that such a folder exist.  This would allow the
possibility of monitoring an Inbox without the overhead of providing a
password.

Do you think it would make any sense to extend the protocol to check for
changes that occurred prior to the SIN session?  Perhaps to obtain the time
that the last change was made to a folder?

Pete Maclean

>From owner-ietf-imapext  Tue Feb 13 09:45:26 2001
To: "Eric Burger" <[email-masked]>
Cc: "Lyndon Nerenberg" <[email-masked]>, <[email-masked]>,
         <[email-masked]>, <[email-masked]>
Subject: Re: newmail notification protocol
From: Simon Josefsson <[email-masked]>
("Eric Burger"'s message of "Tue, 13 Feb 2001 11:36:47 -0500")
Date: 13 Feb 2001 18:45:21 +0100
Message-ID: <[email-masked]>
Lines: 28
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/21.0.97
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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

>  I'm wondering if defining a profile for the SIP message waiting protocol
>  (draft-mahy-sip-message-waiting-01.txt) wouldn't be a better approach.
>
>  On the one hand, the IMAP server and biff client would only need to
>  implement a VERY small subset of SIP.

IMHO both solutions are very useful and welcome, as they serve
different audiences.

For full-blown IMAP clients, having notifications of new mail inside
IMAP is less prone to inconsistent/delayed/duplicated notifications,
and also more efficient.  Using notifications rather than polling [1]
increases performance alot (it would solve the biggest bottleneck in
my client).

For simple biff tools, notifications should preferably not require
complete IMAP implementations (but most biff tools today probably do
implement IMAP because of lack of a notification protocol) and would
be better handled in a separate protoocl.  (Which I assume SIP is,
altough I'm not familiar with SIP.)

Notes: [1] Yes, I know the client could open a IMAP connection for
each mailbox it want to monitor, but it doesn't scale very well.  I
have ~500 personal mailboxes that each receive new mail, not to
mention all shared mailboxes I want to monitor.  Notifications would
be very useful for me.

From: "Eric Burger" <[email-masked]>
To: "Lyndon Nerenberg" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: newmail notification protocol
Date: Tue, 13 Feb 2001 11:36:47 -0500
Importance: Normal
Sender: [email-masked]

I'm wondering if defining a profile for the SIP message waiting protocol
(draft-mahy-sip-message-waiting-01.txt) wouldn't be a better approach.

On the one hand, the IMAP server and biff client would only need to
implement a VERY small subset of SIP.

On the other hand, the IMAP server would only need to track client request
state, instead of keeping open a connection for the duration of the request.
In addition, more and more firewalls are SIP-friendly, so you could use UDP
(although TCP's an option).

Work to be done in this case would be on the event profile for subscribing
to a particular IMAP folder.  That said, that work probably needs to be done
anyway for the SIP MWI draft.

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: newmail notification protocol
Date: Mon, 12 Feb 2001 23:03:43 -0700
Sender: [email-masked]

This is a multipart MIME message.

--==_Exmh_11849420220
Content-Type: text/plain; charset=us-ascii

[ I apologise if you get multiple copies of this. I tried sending
  from my home address, but the list servers didn't like that I
  wasn't subscribed with that address. Although I'm re-sending this
  from my work address, this proposal isn't blessed by my employer. ]

Quite a while back (fall 1998) there was some discussion on the IMAP
lists about the need for a biff-like newmail notification protocol.
At the time I wrote down some ideas, but never got around to posting
anything back to the lists. While doing some laptop cleaning tonight
I found the skeleton drafts I had written up for myself. I've dusted
them off and attached them to this message for review. If the concept
looks useful I can clean them up and submit them as IDs. I also have
a profile suitable for use with POP, (and as a direct biff replacement).

Note: the protocol is designed to be useful for more than just e-mail
arrival notifications.

--lyndon

--==_Exmh_11849420220
Content-Type: text/plain ; name="draft-nerenberg-sin-framework.txt"; charset=us-ascii
Content-Description: draft-nerenberg-sin-framework.txt
Content-Disposition: inline; filename="draft-nerenberg-sin-framework.txt"

Network Working Group					Lyndon Nerenberg
Internet Draft: Simple Internet Notifications		 Orthanc Systems
Document: draft-nerenberg-sin-framework-xx.txt		   February 2001

		     Simple Internet Notifications

Status of this memo

     This document is an Internet Draft and is in full conformance with
     all provisions of Section 10 of RFC 2026.

     Internet Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet
     Drafts.

     Internet Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet Drafts
     as reference material or to cite them other than as "work in
     progress.rq

     The list of current Internet Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     A revised version of this draft document will be submitted to the
     RFC editor as a Proposed Standard for the Internet Community.
     Discussion and suggestions for improvement are requested.
     Distribution of this draft is unlimited.

0.  Administrivia

1.  Introduction

     Certain Internet services are interested in light-weight event
     notifications.  An example of this is a mail client monitoring a
     mailbox for new mail. The arrival of a message in the mailbox can
     be considered a delivery event. These events usually trigger
     actions in the client and server (in this example, a client receiv-
     ing a delivery event might download the message headers for display
     to the user). When events occur infrequently, clients and servers
     can spend long periods of time sitting idle waiting for an event to
     happen.  If the server implements a complex application or proto-
     col, considerable system resources can still be consumed by these
     idle servers (e.g.  physical memory, space in the memory backing
     store, process table entries, network buffers). In some cases, a
     significant reduction is resource consumption can be achieved by
     moving these notifications out of the primary protocol.

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 1]

Internet Draft	      Simple Internet Notifications	   February 2001

     Simple Internet Notifications (SIN) is a protocol framework for
     sending event notifications. SIN is application neutral, and very
     light-weight to allow minimal overhead implementations of both
     clients and servers.

2.  Conventions used in this document

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
     in this document are to be interpreted as described in [KEYWORD].

     The protocol syntax specifications use the Augmented Backus-Naur
     Form (ABNF) notation as specified in [ABNF].

3.  Terminology

     The following terms and abbreviations are used throughout this doc-
     ument:

     application profile
	     A specification describing how a SIN server interprets
	     the authentication and object namespaces, and the
	     events that will trigger an event notification, in the
	     context of a particular application service.

     application service
	     The application protocol or service upon whose behalf
	     the SIN server is providing event notifications.

     authentication namespace
	     The application profile-specific context within which a
	     SIN server interprets authentication identifiers.

     event notification
	     An EVENT or LOST response from the server.

     object
	     An entity upon which a WATCH can be placed.

     object namespace
	     The profile-specific context within which an SIN server
	     interprets object names.

     ignored object
	     A object for which the client does not wish to receive
	     event notifications, either implicitly or via an
	     IGNORE request.

     monitored object
	     An object for which the client has requested
	     event notifications via the WATCH command.

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 2]

Internet Draft	      Simple Internet Notifications	   February 2001

4.  Protocol Framework

     SIN defines a general framework for event notifications. This spec-
     ification does not describe the events that trigger an event noti-
     fication, nor does it describe the interpretation of object names
     or authentication identifiers.  Instead, these are described in
     application specific profile documents. As such, the SIN protocol
     specification MUST be used in conjunction with an application pro-
     file to fully specify the over-the-wire protocol implemented by a
     particular server instance.

     SIN servers do not listen at well known transport addresses.
     Clients are expected to discover the appropriate server transport
     address through out-of-band means. Application protocols and ser-
     vices using SIN SHOULD provide an application protocol mechanism
     for clients to discover the transport addresses of relevent SIN
     servers. (See [IMAP-SIN] for an example.)

4.1.  Application Profiles

     An application profile MUST specify the following components of a
     SIN server implementation:

       1) The semantics and interpretation of authentication identifiers
       2) The encoding and interpretation of object names
       3) The conditions that will trigger an event notification

     Application profiles SHOULD make recommendations to server imple-
     menters on ways the server can reduce the number of outstanding
     event notifications queued for transmission to conjested or blocked
     clients.

4.2.  Object Names

     Object names describe events to be monitored. SIN treats object
     names as opaque data. In SIN commands and responses, the object
     name is the sequence of octets beginning immediately after the com-
     mand or response delimiter and continuing up to, but not including,
     the CRLF line end delimiter. Thus,

	 EVENT foo

     and

	 EVENT	foo

     refer to two distinct objects -- the object name in the second
     example has a space as its first character. An application profile
     defining an object namespace that includes either of the ASCII CR
     or LF characters MUST define an encoding scheme that prevents the
     sequence CRLF from appearing in the object name.

     The application profile is responsible for defining how object

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 3]

Internet Draft	      Simple Internet Notifications	   February 2001

     names are interpreted by the client and server.

4.3.  Conjestion Control

     Event notifications are asynchronous. Clients MUST be prepared to
     accept event notifications at any time. Server implementers are
     cautioned that clients may not be able to accept event notifica-
     tions at the rate the server generates them, and MUST take precau-
     tions to ensure that protocol writes to a blocked client do not
     impair the servers ability to send timely event notifications to
     responsive clients. If a client becomes blocked for an extended
     period of time, servers MAY terminate the protocol session. In the
     absence of specific guidance from an application profile, servers
     SHOULD NOT terminate a blocked client session unless the client has
     been blocked for at least five minutes.

5.  Protocol Description

     A SIN session exists in one of two states: the initial state, and
     the authenticated state. During the initial state the server
     announces the application profile it is serving, and the authenti-
     cation mechanisms it supports. The client verifies that the appli-
     cation profile is the expected one, then authenticates itself to
     the server. After a successfull authentication the session switches
     to the authenticated state. The client is now able to register and
     unregister its interest in objects, and the server can send event
     notifications.

     SIN is a line based protocol. Client commands and server responses
     are CRLF terminated strings.  No explicit bounds are placed on line
     lengths.  Clients SHOULD be able to accept response lines of any
     length, and MAY terminate the session if the server sends responses
     the client is unable to cope with. In the event of occasional input
     buffer overflows, client implementers are encouraged to read and
     discard excess input data up to the CRLF line end. (This could hap-
     pen when a client downsizes an input buffer after issuing an IGNORE
     command, but the server hasn't sent all outstanding event notifica-
     tions pertaining to the now ignored object.)  Wherever practical,
     SIN application profiles SHOULD provide guidance on maximum line
     lengths for server responses.

     Client commands are issued in a synchronous lock-step fashion. Only
     one command can be outstanding at a time. In the authenticated
     state, event notifications can be issued while a command is out-
     standing, and clients MUST be prepared to accept these notifica-
     tions while awaiting the completion of an outstanding command.

     Protocol elements other than object names are case independent, and
     both servers and clients MUST recognize and interpret these in a
     case insensitive manner.

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 4]

Internet Draft	      Simple Internet Notifications	   February 2001

5.1.  Server Responses

     Server responses are of four types: synchronous, asynchronous, ban-
     ner, and authentication.  Synchronous reponses indicate the success
     or failure of client commands. Asynchronous responses describe
     object events. The banner response is issued once by the server at
     session startup, and describes the application profile being
     served. Authentication responses are issued at session startup and
     describe the authentication mechanisms supported by the server.

5.1.1.	Banner Response

     Contents: protocol name
	       application profile identifier
	       OPTIONAL human readable text

     State:    initial

     Upon startup the server announces itself by issuing a banner
     response. The banner identifies the protocol (SIN) and the name of
     the application profile being served.

     The human readable text field can be used to communicate informa-
     tion about the implementation that would assist in debugging the
     implementation (e.g. a vendor name, release number, etc.) The
     length of this field SHOULD NOT exceed 60 octets, and clients MUST
     NOT interpret the contents of this field in any way.

5.1.2.	AUTH Response

     Contents: authentication mechanism name

     State:    initial

     The AUTH response identifies an authentication mechanism supported
     by the server. One AUTH response is sent for each supported authen-
     tication mechanism. Servers MUST support at least one authentica-
     tion mechanism. Where authentication identifiers are not applicable
     the application profile MUST specify use of the ANONYMOUS mecha-
     nism.

     AUTH responses are sent only at server startup. They MUST follow
     the banner response, and MUST preceed the servers initial OK or NO
     response.

5.1.3.	OK Response

     Contents: none

     State:    any

     Commands: IGNORE, WATCH

     The OK response indicates the previously issued command completed

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 5]

Internet Draft	      Simple Internet Notifications	   February 2001

     without error.

     At protocol startup, an OK response terminating the servers greet-
     ing indicates it is willing to provide notification services.

5.1.4.	NO Response

     Contents: none

     State:    any

     Commands: IGNORE, WATCH

     The NO response indicates the server was unable to perform the
     requested command.

     At protocol startup, a NO response terminating the servers greeting
     indicates it is unable to provide notification services. Clients
     receiving a NO response at the end of the server greeting MUST
     immediately terminate the session.

5.1.5.	SYNTAX Response

     Contents: none

     State:    any

     Commands: any

     The SYNTAX response indicates the previous command was syntacti-
     cally incorrect. An object name that violates the application pro-
     files object name encoding rules MUST be rejected with a SYNTAX
     response in order to distinguish it from a properly encoded but
     semantically invalid object name.

5.1.6.	EXIT Response

     Contents: none

     State:    authenticated

     Commands: EXIT

     The EXIT response indicates the server is closing the session.
     After issuing an EXIT response, servers SHOULD NOT send any further
     traffic to the client. Servers SHOULD provide clients with a grace
     period in which to terminate the session, however the server MAY
     terminate the session at any time after issuing the EXIT response.

     A server MAY issue an asynchronous EXIT response to request the
     client initiate session termination. This is an implementation
     optimization. In some cases the server can save resources by having
     the client initiate the close of the protocol session. However, the
     server is NOT REQUIRED to issue an EXIT response before shutting

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 6]

Internet Draft	      Simple Internet Notifications	   February 2001

     down, and clients MUST be prepared to shut down gracefully in the
     absence of EXIT responses. A client receiving an asynchronous EXIT
     response MUST NOT issue an EXIT command as part of the shutdown
     sequence.

5.1.7.	EVENT Response

     Contents: object name

     State:    authenticated

     Commands: none

     EVENT responses are issued whenever an event occurs to a monitored
     object. The response includes the name of the object to which the
     event occurred.

     EVENT responses are asynchronous notifications and may be generated
     at any time while the session is in the authenticated state.

5.1.8.	LOST Response

     Contents: object name

     State:    authenticated

     Commands: none

     The server issues a LOST response whenever it can no longer provide
     event notifications for a monitored object. LOST SHOULD be issued
     when the server cannot continue to provide notification services on
     the object for reasons outside its control (for example, the moni-
     tored object has been permanently destroyed, or an operating system
     error prevents continued access to the object).  Application pro-
     files MAY provide additional guidance for issuing LOST responses.
     In the absence of such guidance, servers SHOULD NOT issue a LOST
     response unless they are reasonably certain the object is perma-
     nently unavailable.

     Servers MUST NOT issue a LOST response in response to an IGNORE
     command.

     LOST responses are asynchronous notifications and may be generated
     at any time while the session is in the authenticated state.

5.2.  Client Commands

5.2.1.	AUTHENTICATE Command

     Arguments: authentication mechanism name

     Responses: continuation data can be requested

     Result: OK      - Authentication credentials accepted; server now

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 7]

Internet Draft	      Simple Internet Notifications	   February 2001

		       in authenticated state.
	     NO      - Authentication failure: credentials rejected or
		       underlying backend authentication service
     unavailable.
	     SYNTAX  - Command rejected: invalid arguments or unknown
		       authentication mechanism.

     The AUTHENTICATE command requests an authentication context be
     established with the server, using the specified mechanism. The
     server performs an authentication protocol exchange to authenticate
     and identify the client.  It MAY also negotiate an OPTIONAL protec-
     tion mechanism for subsequent protocol interactions. If the
     requested authentication mechanism is not supported the server MUST
     reject the AUTHENTICATE command by sending a SYNTAX response.

     The authentication protocol exchange consists of a series of server
     challenges and client answers that are specific to the authentica-
     tion mechanism.  A server challenge consists of a command continua-
     tion request response with the "+" token followed by a BASE64
     encoded string.  The client answer consists of a line consisting of
     a BASE64 encoded string.  If the client wishes to cancel an authen-
     tication exchange, it issues a line with a single "*".  If the
     server receives such an answer, it MUST reject the AUTHENTICATE
     command by sending a tagged SYNTAX response.

     A protection mechanism provides integrity and privacy protection to
     the connection.  If a protection mechanism is negotiated, it is
     applied to all subsequent data sent over the connection.  The pro-
     tection mechanism takes effect immediately following the CRLF that
     concludes the authentication exchange for the client, and the CRLF
     of the tagged OK response for the server.	Once the protection
     mechanism is in effect, the stream of command and response octets
     is processed into buffers of ciphertext.  Each buffer is trans-
     ferred over the connection as a stream of octets prepended with a
     four octet field in network byte order that represents the length
     of the following data.  The maximum ciphertext buffer length is
     defined by the protection mechanism.

     Servers MUST implement at least one authentication mechanism.  If
     the application profile describes a service where authentication
     credentials are not applicable the server and client MUST implement
     and use the ANONYMOUS mechanism.

5.2.2.	WATCH Command

     Arguments: object name

     Result:  OK     - The object has been added to the notification
     list.
	      NO     - The object does not exist, the object name is
		       invalid in the context of the application pro-
     file,
		       the application service access policy denies
		       notification access to the object, or the number

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 8]

Internet Draft	      Simple Internet Notifications	   February 2001

     of
		       monitored objects exceeds a system or implementa-
     tion
		       limit.
	      SYNTAX - The object name is improperly encoded.

     The WATCH command changes an objects status from ignored to moni-
     tored.  Upon successful completion of the WATCH command the server
     will send event notifications for the object to the client.

5.2.3.	IGNORE Command

     Arguments: object name

     Result:  OK     - The object has been removed from the
		       notification list.
	      NO     - The object was not on the servers list of
		       monitored objects.
	      SYNTAX - The object name is improperly encoded.

     The IGNORE command changes an objects status from monitored to
     ignored.

     Upon successful completion of the IGNORE command the server will no
     longer send event notifications for the object to the client.

     After successful completion of an IGNORE command there may be unde-
     livered event notifications for the object that the server cannot
     cancel.  For this reason, clients MUST be capable of accepting
     event notifications for objects they are not currently monitoring.

6.  Example Session

     This example shows a SIN session used to provide newmail notifica-
     tion services to a mail client using the IMAP4 application profile.
     Client commands are prefixed with "C: " and server responses with
     "S: "; these are not part of the SIN protocol.

	 S: SIN IMAP4 Frobozz Magic Notifications Server (v1.0)
	 S: AUTH KERBEROS_V4
	 S: AUTH CRAM-MD5
	 S: OK
	 C: AUTHENTICATE CRAM-MD5
	 S: + PDIyNDE5OTguMTMxMzE0MDhAcmVtYnJhbmR0LmVzeXMuY2E+
	 C: bHluZG9uIDU1NmMyZjYyNzQzZGQ0Y2Q5ZjBiYjUyNzg2NWVkYzZk
	 S: OK
	 C: WATCH INBOX
	 S: OK
	 C: WATCH #public/Mailing Lists/%
	 S: NO
	 C: WATCH #public/Mailing Lists/bugtraq
	 S: EVENT INBOX
	 S: OK
	 S: EVENT #public/Mailing Lists/bugtraq

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt 	[Page 9]

Internet Draft	      Simple Internet Notifications	   February 2001

	 S: EVENT #public/Mailing Lists/bugtraq
	 S: EVENT #public/Mailing Lists/bugtraq
	 S: EVENT INBOX
	 S: EVENT #public/Mailing Lists/bugtraq
	 C: IGNORE #public/Mailing Lists/bugtraq
	 S: OK
	 S: EXIT
	 <client terminates connection>

     After accepting the connection the server announces itself as a SIN
     server offering the IMAP4 application profile, and lists the three
     authentication mechanisms it supports.  The client authenticates
     using the CRAM-MD5 SASL mechanism.

     The request for notifications on the #public/Mailing Lists/%
     object, while syntactically correct, was rejected by the server due
     to a violation of the application profile's object namespace pol-
     icy. Note the use of NO to distinguish between policy violations
     and protocol errors. (A protocol error would have provoked a SYNTAX
     response.)

     The last item of interest is the event notification occuring while
     the final WATCH command was in progress. There is no guarantee that
     WATCH commands will complete quickly, so this sequence can be
     expected to happen frequently when monitoring active objects.

7.  Formal Protocol Grammar

8.  Security Considerations

9.  Authors' Addresses

       Lyndon Nerenberg
       Orthanc Systems
       Unit 575-21
       10405 Jasper Avenue
       Edmonton, Alberta
       Canada T5J 3S2

       Email: [email-masked]

Nerenberg	  drraft-nerenberg-sin-framework-xx.txt        [Page 10]


--==_Exmh_11849420220
Content-Type: text/plain ; name="draft-nerenberg-sin-imap.txt"; charset=us-ascii
Content-Description: draft-nerenberg-sin-imap.txt
Content-Disposition: inline; filename="draft-nerenberg-sin-imap.txt"

Network Working Group					Lyndon Nerenberg
Internet Draft: SIN IMAP4 Application Profile		 Orthanc Systems
Document: draft-nerenberg-sin-imap-xx.txt		   February 2001

		     Simple Internet Notifications
		       IMAP4 Application Profile

Status of this memo

     This document is an Internet Draft.  Internet Drafts are working
     documents of the Internet Engineering Task Force (IETF), its Areas,
     and its Working Groups.  Note that other groups may also distribute
     working documents as Internet Drafts.

     Internet Drafts are draft documents valid for a maximum of six
     months.  Internet Drafts may be updated, replaced, or obsoleted by
     other documents at any time.  It is not appropriate to use Internet
     Drafts as reference material or to cite them other than as a
     "working draft" or "work in progress."

     To learn the current status of any Internet-Draft, please check the
     1id-abstracts.txt listing contained in the Internet-Drafts Shadow
     Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
     munnari.oz.au.

     Discussion and suggestions for improvement are requested.	This
     document will expire six months after publication.  Distribution of
     this draft is unlimited.

1. Introduction

     Simple Internet Notifications [SIN] provides a generic event noti-
     fication framework. SIN application profiles define the character-
     istics of a SIN server for a specific application.

     This document defines a SIN application profile that provides new
     mail arrival notification services on behalf on Internet Message
     Access Protocol [IMAP4rev1] servers.

2. Conventions used in this document

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
     in this document are to be interpreted as described in [KEYWORD].

     The protocol syntax specifications use the Augmented Backus-Naur
     Form (ABNF) notation as specified in [ABNF].

3. Application Profile Identifier

Nerenberg							[Page 1]

Internet Draft	      SIN IMAP4 Application Profile	   February 2001

     The identifier for this application profile is IMAP4.

4. Authentication Namespace

     The authentication namespace exported by a SIN server running this
     profile MUST be identical to the authentication namespace exported
     by the corresponding IMAP4 server.

     If the IMAP4 server does not support any SASL authentication mecha-
     nisms (i.e. it only supports the IMAP4 LOGIN command), the SIN
     server MUST offer the PLAIN authentication mechanism, and MUST
     treat AUTH PLAIN requests as the IMAP4 server would LOGIN requests.

5. Objects

5.1. Object Namespace

     Object names in this profile represent IMAP4 folder names.

     An object names a unique IMAP4 folder. Servers MUST NOT perform
     wildcard expansion on object names.

5.2. Object Name Encoding

     Object names are encoded using the modified UTF-7 encoding scheme
     described in [IMAP4].

6. Event Triggers

     Introduction of any message into a monitored object (folder) MUST
     generate an EVENT event notification.

     If the monitored object (folder) is destroyed or becomes perma-
     nently unaccessable (for example, through a change in security pol-
     icy), the server MUST generate a LOST event notification.

7. Security Considerations

     Servers MUST perform all operations in the security context of the
     authenticated entity. Servers MUST NOT expose any information about
     the IMAP4 folder namespace that would not be available if the same
     credentials were used to connect to the IMAP4 server.

     Servers MUST NOT send notification events (including LOST
     responses) for a folder unless the authentication and authorization
     credentials used for the SIN session, if used to connect to the
     IMAP4 server, would allow a successful IMAP4 SELECT on that folder.

Nerenberg							[Page 2]

Internet Draft	      SIN IMAP4 Application Profile	   February 2001

8. Authors' Addresses

  Lyndon Nerenberg
  Orthanc Systems
  Unit 575-21
  10405 Jasper Avenue
  Edmonton, Alberta
  Canada T5J 3S2

  Email: [email-masked]

Nerenberg							[Page 3]


--==_Exmh_11849420220--

Date: Thu, 08 Feb 2001 07:15:14 -0800
From: Chris Newman <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance
Sender: [email-masked]

--On Wednesday, February 7, 2001 16:08 -0700 Lyndon Nerenberg 
<[email-masked]> wrote:
> Just to be clear, you're saying:
>
> 1) FETCH SHOULD return well-formed RFC822/MIME message content, but
>    servers MAY send anything allowed by the IMAP4 protocol syntax, and
>
> 2) APPEND data SHOULD be a well-formed RFC822/MIME message, but servers
>    MAY accept anything that fits in the IMAP4 protocol syntax for APPEND.

Yes, although those statements are too vague for a formal standard.

RFC 2060 says (2) so we're stuck with it.  However, since 2060 does not say 
(1), FETCH inherits all requirements of RFC 822/MIME by reference.  That 
implies the only way to be fully compliant with 2060 is to somehow fix 
everything accepted under (2) so it's 822/MIME compliant on FETCH.  Since 
it doesn't specify the downconversion procedure adequately (especially for 
8-bit headers), I'd say the status quo is unacceptable.

If Mark can translate the core ideas from his most recent messsage on this 
thread to standards-style language, that would be good enough for me.  Mark 
and I obviously disagree somewhat on the value of a server rejecting or 
down-converting ill-formed 822/MIME messages, but as long as the spec 
doesn't forbid doing so, I don't forsee any problems.

		- Chris

Date: Wed, 7 Feb 2001 15:25:18 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance 
To: Lyndon Nerenberg <[email-masked]>
cc: Chris Newman <[email-masked]>, IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Sender: [email-masked]

On Wed, 07 Feb 2001 16:08:51 -0700, Lyndon Nerenberg wrote:
> 1) FETCH SHOULD return well-formed RFC822/MIME message content, but
>    servers MAY send anything allowed by the IMAP4 protocol syntax, and

FETCH should return an accurate representation of what is in the mailbox.  An
IMAP server is not required to "fix" FETCH data to comply with RFC822/MIME.

Client authors must therefore expect to encounter FETCH data that complies
with IMAP, but not necessarily with RFC822/MIME.

> 2) APPEND data SHOULD be a well-formed RFC822/MIME message, but servers
>    MAY accept anything that fits in the IMAP4 protocol syntax for APPEND.

It is desirable that message data placed in a mailbox (whether via APPEND,
SMTP, LMTP, or NNTP) be well-formed according to RFC822/MIME.  However, this
assumption is openly violated by NNTP.  There is no requirement that APPEND or
SMTP "fix" (or not fix) incoming data to comply with RFC822/MIME; I don't know
if LMTP has any such requirement.  There is no requirement that APPEND or SMTP
accept incoming data that does not comply with RFC822/MIME.  However, the SMTP
specification encourages servers to err on the side of permissiveness in the
face of client non-compliance.

> #2 I can live with, although I would feel better if there was some wording
> that makes it clear that servers can (and probably will) reject things that
> don't fit the '822/MIME syntax.

I agree that an IMAP server may reject APPEND of a message due to RFC822/MIME
non-compliance.

However, I consider such behavior grounds for rejecting a particular
implementation from consideration for deployment, and would recommend
accordingly.  It is not difficult to prepare a demonstration on how that
server fails to perform to user expectations.

It is more difficult to argue against a server which accepts such messages,
but "fixes" them to comply.  However, I would try to find an example in which
the server "fixes" it into a worse condition, and would recommend against the
server if I found such an example.  Conversely, I would be favorably impressed
if I can't find such an example.

> For #1 my concern is that this can be read as a license for the injection
> mechanism (e.g. LMTP) to let anything in to the message store.

That is something that the LMTP specification must address.  It is not an IMAP
issue.

I would consider a client that generates non-compliant messages to APPEND (as
opposed to using APPEND to copy a message from another source) to have a
quality of implementation problem, and would probably recommend against
deployment of such a client.

However, since it is not possible for a server to determine whether the client
generated the non-compliant text, or is simply copying a message from another
source, I look upon this less harshly than I would a server that refuses to
accept user data in APPEND.

> Here's another wrench to ponder: could we make \draft explicitly relax the
> RFC822/MIME syntax requirements for a message?

That has bad implications for STORE FLAGS.

There is a fundamental principle which ranks up there with "be conservative in
what you generate, be liberal in what you accept."  In fact, this is the most
important principle: "garbage in, garbage out."

Of course, one man's garbage may be another man's treasure.

I treat message data (even garbage) as treasure to the maximum extent
possible, and restrict my strict demands on protocol compliance to those
matters dictated by IMAP syntax.

From: Lyndon Nerenberg <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance 
Organization: ACI Worldwide - MessagingDirect
Date: Wed, 07 Feb 2001 16:08:51 -0700
Sender: [email-masked]

> RFC 822 requires a from header, a recipient header (To, Cc, or Bcc) and a 
> date header (see the formal syntax).  So while I agree that Mark's answer 
> is appropriate for IMAP, the RFC 822 rule needs to be explicitly waived for 
> IMAP.  MIME had the same issue with multipart/digest.

Just to be clear, you're saying:

1) FETCH SHOULD return well-formed RFC822/MIME message content, but
   servers MAY send anything allowed by the IMAP4 protocol syntax, and

2) APPEND data SHOULD be a well-formed RFC822/MIME message, but servers
   MAY accept anything that fits in the IMAP4 protocol syntax for APPEND.

#2 I can live with, although I would feel better if there was some wording
that makes it clear that servers can (and probably will) reject things that
don't fit the '822/MIME syntax.

For #1 my concern is that this can be read as a license for the injection
mechanism (e.g. LMTP) to let anything in to the message store. I would
prefer to see wording that makes it completely clear that that's not the case.

Here's another wrench to ponder: could we make \draft explicitly relax the
RFC822/MIME syntax requirements for a message?

--lyndon

Date: Wed, 07 Feb 2001 14:42:07 -0800
From: Chris Newman <[email-masked]>
To: Mark Crispin <[email-masked]>, Lyndon Nerenberg <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance
Sender: [email-masked]

--On Monday, February 5, 2001 20:13 -0800 Mark Crispin 
<[email-masked]> wrote:
> Otherwise, what is a server supposed to do with messages in a mailbox
> which do not strictly conform to RFC 822?   It's one thing to generate as
> best an envelope as it can; it is quite another to "fix" them to be
> "valid".  May anyone who thinks otherwise be condemned to relive the
> early 1980s when various systems running sendmail commonly "fixed"
> message headers into total gubbish.

The problem with older versions of sendmail was not that it made 
non-standards compliant headers compliant, but rather that it attempted to 
do so without fully implementing the standard and understanding the 
consequences of the changes it made.  Indeed it made some compliant headers 
non-complaint (e.g., "group:;" -> "group:;@host") and thus created new 
compliance problems.

The 8BITMIME spec describes a specific procedure to deal with message 
bodies that aren't complaint with the SMTP or 822 base specs, and this 
procedure works just fine in practice.

PMDF has repaired standards compliance errors in email headers for over 15 
years, and it works great.  Clients routinely core dump (or bomb or blue 
screen) when they encounter incompliant messages.  Most enterprises or ISPs 
would rather have messages fixed by the server so they don't get 200 
support calls to the IT helpdesk about the client crashing.

>> But on a related note, is it valid to have *no* headers? (I.e. the
>> message starts with CRLF.)  Presumably it would be valid for a client
>> to want to store a draft message that contains body text but no headers.
>
> I believe that the answer is "yes".  BODY[HEADER] would be 4 octets (CR
> LF CR LF) and BODY[TEXT] would be everything after that.

RFC 822 requires a from header, a recipient header (To, Cc, or Bcc) and a 
date header (see the formal syntax).  So while I agree that Mark's answer 
is appropriate for IMAP, the RFC 822 rule needs to be explicitly waived for 
IMAP.  MIME had the same issue with multipart/digest.

		- Chris

Date: Tue, 6 Feb 2001 16:40:04 -0700 (MST)
From: Lyndon Nerenberg <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance 
Sender: [email-masked]

> However, there is a valid IMAP representation even for non-sensical results.

Well, okay :-)  I can guess what will happen when one of those is
presented to a client, though.

Date: Mon, 5 Feb 2001 20:13:16 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance 
To: Lyndon Nerenberg <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Sender: [email-masked]

On Mon, 05 Feb 2001 15:58:07 -0700, Lyndon Nerenberg wrote:
> I agree that this must specify that the text at least conform
> to the 822 header syntax. For servers that parse 822 and MIME headers
> at injection time (such as ours and Cyrus) anything else is
> going to be rejected or result in non-sensical FETCH results.

However, there is a valid IMAP representation even for non-sensical results.

Otherwise, what is a server supposed to do with messages in a mailbox which do
not strictly conform to RFC 822?   It's one thing to generate as best an
envelope as it can; it is quite another to "fix" them to be "valid".  May
anyone who thinks otherwise be condemned to relive the early 1980s when
various systems running sendmail commonly "fixed" message headers into total
gubbish.

> But on a related note, is it valid to have *no* headers? (I.e. the
> message starts with CRLF.)  Presumably it would be valid for a client
> to want to store a draft message that contains body text but no headers.

I believe that the answer is "yes".  BODY[HEADER] would be 4 octets (CR LF CR
LF) and BODY[TEXT] would be everything after that.

From: Lyndon Nerenberg <[email-masked]>
to: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: Re: Major error in IMAP base spec: 822/MIME conformance 
Organization: ACI Worldwide - MessagingDirect
Date: Mon, 05 Feb 2001 15:58:07 -0700
Sender: [email-masked]

> --On Monday, February 5, 2001 12:12 -0800 Mark Crispin 
> <[email-masked]> wrote:
> > So, I don't see how it's possible to have any other interpretation for
> > "[RFC-822] header" than "that part of the message which appears prior to
> > the first CRLF CRLF".
> 
> I interpret "[RFC-822] header" as the subset of an RFC-822 conformant 
> message prior to the CRLF CRLF.
> 
> If "[RFC-822] header" doesn't conform to the syntax defined in RFC-822, 
> then what syntax does it conform to?

I agree that this must specify that the text at least conform
to the 822 header syntax. For servers that parse 822 and MIME headers
at injection time (such as ours and Cyrus) anything else is
going to be rejected or result in non-sensical FETCH results. There's
no way our implementation could accept anything in that part of the
message that doesn't conform to the 822 header syntax.

But on a related note, is it valid to have *no* headers? (I.e. the
message starts with CRLF.)  Presumably it would be valid for a client
to want to store a draft message that contains body text but no headers.
(If the body represents a single part 7bit text/plain there's no
requirement for an explicit MIME-Version header at any stage of the
draft composition.)

--lyndon

Date: Mon, 05 Feb 2001 14:11:11 -0800
From: Chris Newman <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: re: Major error in IMAP base spec: 822/MIME conformance
Sender: [email-masked]

--On Monday, February 5, 2001 12:12 -0800 Mark Crispin 
<[email-masked]> wrote:
> So, I don't see how it's possible to have any other interpretation for
> "[RFC-822] header" than "that part of the message which appears prior to
> the first CRLF CRLF".

I interpret "[RFC-822] header" as the subset of an RFC-822 conformant 
message prior to the CRLF CRLF.

If "[RFC-822] header" doesn't conform to the syntax defined in RFC-822, 
then what syntax does it conform to?

To fix this problem, I suggest something along the lines of taking the 
language from the APPEND section and making it clear it also applies to 
FETCH.  If you feel it would be constructive for me to suggest strawman 
language, I'll do so, but I'd rather leave the specifics to your judgement.

		- Chris

Date: Mon, 5 Feb 2001 12:12:43 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: re: Major error in IMAP base spec: 822/MIME conformance
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 5 Feb 2001, Chris Newman wrote:
> However, while the base spec is quite clear in allowing non-RFC 822
> messages on APPEND, it also states that FETCH returns RFC 822 formatted
> headers.  These statements can't both be true.  I propose that you resolve
> the discrepancy in the manner you feel is most appropriate as I trust your
> judgement on i18n issues.  If the way to resolve the discrepancy with
> minimal backwards compatibility issues is to state that FETCH can return
> non-RFC 822 headers and messages, so be it.

I would agree to make a fix to any statement that says that "FETCH returns
RFC 822 formatted headers" if I could find such a statement.  The word
"formatted" appears nowhere in the document.  The closest that I can find
are references to "[RFC-822] header".

RFC 822 does not define anything called a "header"; instead, it uses the
term "header fields".

RFC 2060, in turn, only uses "header fields" in the context of subsetting
header fields.  RFC 2060 definitely permits an ENVELOPE to have NIL for
items which can not be NIL in an RFC 822 message.

On top of that, very few news messages comply with RFC 822; yet I have not
heard anyone claim that this precludes the use of RFC 822 to describe the
syntax of headers in news.

So, I don't see how it's possible to have any other interpretation for
"[RFC-822] header" than "that part of the message which appears prior to
the first CRLF CRLF".

-- Mark --

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

Date: Mon, 05 Feb 2001 11:24:59 -0800
From: Chris Newman <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, IMAP Discusson List <[email-masked]>
Subject: re: Major error in IMAP base spec: 822/MIME conformance
Sender: [email-masked]

Mark,

My previous proposal on this issue was crafted before I understood the 
implications of the language in 2060 permitting 8-bit throughout the 
message on APPEND.  I agree my original proposal was incorrect and withdraw 
it.

However, while the base spec is quite clear in allowing non-RFC 822 
messages on APPEND, it also states that FETCH returns RFC 822 formatted 
headers.  These statements can't both be true.  I propose that you resolve 
the discrepancy in the manner you feel is most appropriate as I trust your 
judgement on i18n issues.  If the way to resolve the discrepancy with 
minimal backwards compatibility issues is to state that FETCH can return 
non-RFC 822 headers and messages, so be it.

But I do not believe it is appropriate to publish a revision of the base 
spec with contradictory statements once they have been identified.

		- Chris

--On Friday, February 2, 2001 19:10 -0800 Mark Crispin 
<[email-masked]> wrote:

> In the interest of saving time for everyone:
>  . this matter is outside of the charter of IMAPEXT, and thus should be
>     discussed in IMAP, not IMAPEXT.
>  . the proposed change introduces a major incompatibility that breaks:
>    . existing compliant implementations
>    . existing use of IMAP to access netnews
>    . existing use of IMAP in certain European and Asian countries
>
> Furthermore, the argument that supports the proposed change also renders
> in error the facility whereby APPEND can write drafts that lack headers
> required by RFC 822.  I do not believe that client writers who use for
> this would be pleased with such a change.
>
> Consequently, the proposed change is outside of the scope of the effort to
> update the base specification, and thus is not within my discretion to
> make even if I supported it (which I do not).
>
> Is there concensus to abandon the update work on the IMAP4rev1 base
> specification, and reconstitute the IMAP Working Group to create an
> incompatible replacement to IMAP4rev1 that will incorporate the proposed
> chang and disallow use of IMAP to access messages in "just send 8-bit"
> environments (netnews, and certain European and Asian countries)?
>
> For all the reasons indicated above, I vote NO.  I do not believe that the
> argument in favor of the change is correct; nor that there is any error
> in the base specification; nor that this matter warrants a change to the
> text of the base specification.
>
> If you feel that otherwise, please present your case on the IMAP mailing
> list.
>

Date: Fri, 2 Feb 2001 19:10:25 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Major error in IMAP base spec: 822/MIME conformance
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

In the interest of saving time for everyone:
 . this matter is outside of the charter of IMAPEXT, and thus should be
    discussed in IMAP, not IMAPEXT.
 . the proposed change introduces a major incompatibility that breaks:
   . existing compliant implementations
   . existing use of IMAP to access netnews
   . existing use of IMAP in certain European and Asian countries

Furthermore, the argument that supports the proposed change also renders in
error the facility whereby APPEND can write drafts that lack headers required
by RFC 822.  I do not believe that client writers who use for this would be
pleased with such a change.

Consequently, the proposed change is outside of the scope of the effort to
update the base specification, and thus is not within my discretion to make
even if I supported it (which I do not).

Is there concensus to abandon the update work on the IMAP4rev1 base
specification, and reconstitute the IMAP Working Group to create an
incompatible replacement to IMAP4rev1 that will incorporate the proposed chang
and disallow use of IMAP to access messages in "just send 8-bit" environments
(netnews, and certain European and Asian countries)?

For all the reasons indicated above, I vote NO.  I do not believe that the
argument in favor of the change is correct; nor that there is any error in the
base specification; nor that this matter warrants a change to the text of the
base specification.

If you feel that otherwise, please present your case on the IMAP mailing list.

Date: Fri, 02 Feb 2001 18:26:40 -0800
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Major error in IMAP base spec: 822/MIME conformance
Sender: [email-masked]

The syntax which APPEND permits in section 6.3.11:

      The APPEND command appends the literal argument as a new message
      to the end of the specified destination mailbox.  This argument
      SHOULD be in the format of an [RFC-822] message.  8-bit characters
      are permitted in the message.  A server implementation that is
      unable to preserve 8-bit data properly MUST be able to reversibly
      convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content
      transfer encoding.

      Note: There MAY be exceptions, e.g. draft messages, in which
      required [RFC-822] header lines are omitted in the message literal
      argument to APPEND.  The full implications of doing so MUST be
      understood and carefully weighed.

Is different from the syntax which FETCH returns in section 6.4.5:

                     The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT
                     part specifiers refer to the [RFC-822] header of
                     the message or of an encapsulated [MIME-IMT]
                     MESSAGE/RFC822 message.  HEADER.FIELDS and
                     HEADER.FIELDS.NOT are followed by a list of
                     field-name (as defined in [RFC-822]) names, and
                     return a subset of the header.  The subset returned
                     by HEADER.FIELDS contains only those header fields
                     with a field-name that matches one of the names in
                     the list; similarly, the subset returned by
                     HEADER.FIELDS.NOT contains only the header fields
                     with a non-matching field-name.  The field-matching
                     is case-insensitive but otherwise exact.  In all
                     cases, the delimiting blank line between the header
                     and the body is always included.

Since the FETCH HEADER items reference RFC-822/MIME for the syntax, they 
inherit the restriction from those specifications which forbid 8-bit in all 
headers in all cases.

Thus the syntax of APPEND requires a server to accept things that it is 
forbidden to send in response to FETCH.  This needs to be fixed.

Rather than argue with Mark, I suggest he fix it however he prefers.  I 
expect I'll go along with any proposal that has a reasonable chance of 
getting by the area directors.

		- Chris

Date: Fri, 2 Feb 2001 15:24:43 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: LAST CALL: IMAP base and MULTIAPPEND drafts
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Fri, 02 Feb 2001 14:51:08 -0800, Chris Newman wrote:
> While this applies to validation for the presence of required header
> fields, it does not apply to illegal 8-bit in headers.

What standards-track document makes such a distinction?

The only document which makes any references to messages which do not have
required fields in the context of IMAP is the IMAP specification, and that
text explicitly permits 8-bit characters.

> Indeed,
> Cyrus-derived servers tend to reject APPEND commands with illegal 8-bit in
> headers.

Although that is its perogative, it may not be in full compliance with IMAP.

> The fact remains that an IMAP server which sends illegal 8-bit header data
> in response to a FETCH is not standards compliant.

Incorrect.  RFC 2060, page 13:

   [...]  IMAP4rev1 implementations MAY
   transmit 8-bit or multi-octet characters in literals, but SHOULD do
   so only when the [CHARSET] is identified.

Later, on page 34:

      [...] This argument
      SHOULD be in the format of an [RFC-822] message.  8-bit characters
      are permitted in the message.  A server implementation that is
      unable to preserve 8-bit data properly MUST be able to reversibly
      convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content
      transfer encoding.

In other words, such behavior, while a violation of what RFC 2060 considers to
be good practice, is compliant since the term is "SHOULD" instead of "MUST".

It would be impossible to make it a MUST; it is widely violated in Europe and
Japan.  A MUST which is unenforcible and widely violated is a sick joke, and I
am not interested in making sick jokes.

> Thus if an IMAP server
> accepts illegal 8-bit header data it must do something to make FETCH
> compliant.

It may do something; or it may decide to leave bad enough alone in the name of
avoiding sendmail disease (that is, "fixing" data into a broken state).

>     An IMAP server MUST NOT send illegal 8-bit characters in headers
>     in response to a FETCH command.

Earlier, you claimed that this requirement already existed; now you're trying
to add it as a new requirement.

>     [...] When an IMAP server receives an
>     APPEND command which contains illegal 8-bit characters in headers,
>     it MAY accept the command only if appropriate down-conversion to
>     MIME header encoding [RFC2047] is performed.

"Illegal 8-bit character" is undefined, unless you mean "8-bit octet which
does not comply with UTF-8 encoding."  There is no way for a server to
distinguish a string which complies with UTF-8 encoding, but is in a character
set other than Unicode, from UTF-8.

Consequently, the server is given a mandate which it can not reliably execute.
Furthermore, what constitutes an "illegal 8-bit character" could conceivably
change over time.

The only server mandate which currently exists is that a 7-bit server must do
MIME down-conversion.  As the author of the only 7-bit server in existance
(the TOPS-20 one, which supports RFC 1176 IMAP2), if I ever implemented
IMAP4rev1 (and thus the APPEND command) in that server the very first thing I
would do is make it be 8-bit, simply because I don't know how to implement the
down-convert mandate if I don't know the character set.  The principle of "do
the least harm" indicates leaving it in 8-bit with undefined character set and
not down-convert with a guess of the character set.

Your proposed change, on the other hand, forces all server implementations to
implement down-conversion with character set guessing.  This creates harm that
currently does not exist.

> The message format document is distinctly the wrong place for this wording,
> as this also applies to MIME headers and validation is only appropriate for
> interactive protocols (e.g., IMAP APPEND and Submit, but not SMTP relay).

It absolutely is correct to be in the message format document.  Otherwise, you
have to change every "interactive" protocol document to comply when the
message format document changes.  Furthermore, the distinction between Submit
and SMTP relay in real life is often illusory, since in most cases the two are
the same service.

Much of the pain in MIME would not have been necessary if the SMTP document
had not imposed a restriction of the message format document that was later
overturned.

As matters stand now, responsibility for compliance with the current message
format document rests with the client, not the server.  The IMAP specification
(page 34) explicitly indicates the possibility of a append argument which does
not comply with RFC-822, and which contains 8-bit characters.  This status quo
is a Good Thing and should not be broken.

Date: Fri, 02 Feb 2001 14:51:08 -0800
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: LAST CALL: IMAP base and MULTIAPPEND drafts
Sender: [email-masked]

--On Friday, January 5, 2001 11:24 -0800 Mark Crispin 
<[email-masked]> wrote:
> There seems to be a concensus (which I share) that IMAP servers should not
> attempt to do message format validation on APPEND because of the issue
> with drafts.

While this applies to validation for the presence of required header 
fields, it does not apply to illegal 8-bit in headers.  Indeed, 
Cyrus-derived servers tend to reject APPEND commands with illegal 8-bit in 
headers.

>  However, if such validation is done, I feel that the
> specification of the validation should be in the message format document
> (RFC 822 or successor) and not in an IMAP document.  As far as the IMAP
> document is concerned, the APPEND text is simply a literal.

The fact remains that an IMAP server which sends illegal 8-bit header data 
in response to a FETCH is not standards compliant.  Thus if an IMAP server 
accepts illegal 8-bit header data it must do something to make FETCH 
compliant.  Here's strawman wording:

    An IMAP server MUST NOT send illegal 8-bit characters in headers
    in response to a FETCH command.  When an IMAP server receives an
    APPEND command which contains illegal 8-bit characters in headers,
    it MAY accept the command only if appropriate down-conversion to
    MIME header encoding [RFC2047] is performed.  IMAP servers are
    encouraged to accept APPEND commands with UTF-8 characters in headers.

This wording would remain correct if a future standard explicitly legalized 
unencoded UTF-8 headers.

The message format document is distinctly the wrong place for this wording, 
as this also applies to MIME headers and validation is only appropriate for 
interactive protocols (e.g., IMAP APPEND and Submit, but not SMTP relay). 
I'd prefer this went into the IMAP base spec, but I could live with 
deferring it for a future standard on handling 8-bit characters in message 
headers.

		- Chris

From: "Eric Burger" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: FW: I-D ACTION:draft-ietf-vpim-hint-02.txt
Date: Thu, 1 Feb 2001 10:22:54 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0033_01C08C38.F07C2960
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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

	Title		: Message Context for Internet Mail
	Author(s)	: E. Burger, E. Candell, C. Eliot, G. Klyne
	Filename	: draft-ietf-vpim-hint-02.txt
	Pages		: 19
	Date		: 26-Jan-01

This memo describes a new RFC822 message header, 'Message-Context'.
This header provides information about the context and presentation
characteristics of a message.
A receiving user agent (UA) may use this information as a hint to
optimally present the message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-02.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-vpim-hint-02.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-vpim-hint-02.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_000_0033_01C08C38.F07C2960
Content-Type: Message/External-body;
	name="ATT00024.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00024.dat"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-vpim-hint-02.txt

------=_NextPart_000_0033_01C08C38.F07C2960
Content-Type: Message/External-body;
	name="draft-ietf-vpim-hint-02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-ietf-vpim-hint-02.txt"

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

------=_NextPart_000_0033_01C08C38.F07C2960--