Subject: [lemonade] Embedded URI variant

From: Pete Resnick <[email-masked]>
Date: Fri, 6 Feb 2004 20:10:01 -0600

The Embedded URI variant described in 
draft-crispin-lemonade-pull-01.txt is not a pull-specific mechanism. 
It can also be done using push (e.g., as part of the SUBMIT command). 
Personally, I find Embedded URI troublesome, for either push or pull, 
since it requires MIME parsing on the part of the assembler, again 
upping the ante on the task at hand. But either way, I think it 
should be either removed from the pull document, or added to the push 
document, if we want a reasonable comparison of the mechanisms. 
Again, speaking personally, I would prefer it simply be removed from 
the pull document.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Fri, 6 Feb 2004 18:46:06 -0800 (Pacific Standard Time)

On Fri, 6 Feb 2004, Pete Resnick wrote:
> The Embedded URI variant described in draft-crispin-lemonade-pull-01.txt is not 
> a pull-specific mechanism. It can also be done using push (e.g., as part of the 
> SUBMIT command).

I disagree.  The URIs have to be pulled before they could be pushed.  
There is no way to push an external URI.

> Personally, I find Embedded URI troublesome, for either push 
> or pull, since it requires MIME parsing on the part of the assembler, again 
> upping the ante on the task at hand.

Fortunately, IMAP has an excellent MIME parser so this is not a problem.  
One obvious way of addressing the problem is to have the URLFETCH command 
do the necessary processing.  Conceivably, URLFETCH could even do some 
limited on-the-fly assembly.

> But either way, I think it should be 
> either removed from the pull document, or added to the push document, if we 
> want a reasonable comparison of the mechanisms.

Embedded URI is something that particularly highlights the superiority of 
pull.  Requesting that Embedded URI be removed to make a "reasonable 
comparison" is tantamount to saying that pull should be handicapped.

If you wish to propose a push-type mechanism for Embedded URI, please be 
my guest.  I am starting to believe that, due to the draft and fcc 
problems, embedded URI is a necessary part of any solution; either alone 
or in conjunction with CATENATE.  Several interesting possibilities open 
up with a form of CATENATE that is savvy about Embedded URIs.

-- Mark --

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

---

From: Pete Resnick <[email-masked]>
Date: Sat, 7 Feb 2004 10:37:56 -0600

On 2/6/04 at 6:46 PM -0800, Mark Crispin wrote:

>>draft-crispin-lemonade-pull-01.txt is not a pull-specific 
>>mechanism. It can also be done using push (e.g., as part of the 
>>SUBMIT command).
>

The distinction between "push" and "pull", as far as we have been 
using those terms in LEMONADE, is whether the mail message in the 
user's IMAP store that is to be submitted is pushed from the IMAP 
store or pulled from the IMAP store. Though I don't disagree that 
external content (i.e., from outside of the user's IMAP store) will 
always be pulled, our conversation in this group to date hasn't made 
the distinction on that level. (See earlier suggestions that the 
"push" mechanism use a template message with references to other 
content.) We're trying to figure out whether all of this should be 
implemented by the client interacting with the IMAP server alone or 
by interacting with the submission server.

>>Personally, I find Embedded URI troublesome, for either push or 
>>pull, since it requires MIME parsing on the part of the assembler, 
>>again upping the ante on the task at hand.
>
>Fortunately, IMAP has an excellent MIME parser so this is not a 
>problem.  One obvious way of addressing the problem is to have the 
>URLFETCH command do the necessary processing.  Conceivably, URLFETCH 
>could even do some limited on-the-fly assembly.

Again, the same can be said for the IMAP SUBMIT command in the push 
proposal. I don't think it's impossible, but this raises the ante.

>>But either way, I think it should be either removed from the pull 
>>document, or added to the push document, if we want a reasonable 
>>comparison of the mechanisms.
>
>Embedded URI is something that particularly highlights the 
>superiority of pull.

I disagree. Embedded URI is something that can be done from either 
the IMAP server or the submission server. Therefore it makes no 
distinction at all between using one of those mechanisms. In fact, 
your draft says that the advantages of embedded URI are:

- No assembly burden for client
- Draft friendly (if you want unassembled drafts)

If you want to describe a superiority of doing embedded URI from the 
SUBMIT server instead of doing it from the IMAP server, then you'd be 
making a reasonable comparison.

For the record, I didn't think that any of the advantage/disadvantage 
discussion should be going on in this document in the first place. I 
had thought the intention of this document was to document usage, 
just as the push document did, and that Randy's 
draft-ietf-lemonade-submit-* was supposed to document advantages and 
disadvantages of each strategy.

(And on that score: This document does not give a detailed 
description of embedded URI. It describes possible mechanisms, like 
"some easily-identifiable form, perhaps as an added parameter to the 
[MIME] Content-Type header", but doesn't actually make a proposal. If 
we are actually going to be comparing mechanisms, I'd like to see the 
mechanism.)

>Requesting that Embedded URI be removed to make a "reasonable 

Nonsense. All that I asked for was for the comparison to be made 
between the two strategies being discussed or not made at all. The 
present text attributes advantages to one strategy without noting 
that they apply equally well to the other strategy.

>If you wish to propose a push-type mechanism for Embedded URI, 
>please be my guest.

I'd first like to see the mechanism that you are proposing for the 
pull document and see if it can be re-used for the SUBMIT command. 
We're supposed to be comparing apples to apples here, at least so far 
as we can.

>I am starting to believe that, due to the draft and fcc problems, 
>embedded URI is a necessary part of any solution; either alone or in 
>conjunction with CATENATE.  Several interesting possibilities open 

Can you detail what you mean by "a form of CATENATE that is savvy 
about Embedded URIs"? What would end up on the server after you use 
such a CATENATE?

pr

---

From: Mark Crispin <[email-masked]>
Date: Sat, 7 Feb 2004 10:59:02 -0800 (PST)

On Sat, 7 Feb 2004, Pete Resnick wrote:
> The distinction between "push" and "pull", as far as we have been using those 
> terms in LEMONADE, is whether the mail message in the user's IMAP store that 
> is to be submitted is pushed from the IMAP store or pulled from the IMAP 
> store. 

There is more to it than that.  There is also the question of external content, 
and whether it is pushed to the MSA or does the MSA pull it.

This is a critical question.  It has enormous implications for existing service 
facilities and their overall architecture.  Push has the effect of declaring a 
great many existing facilities "broken", and of closing a great many doors in 
how a service facility is designed.

> Though I don't disagree that external content (i.e., from outside of the 
> user's IMAP store) will always be pulled, our conversation in this group to 
> date hasn't made the distinction on that level.

Which is probably why there is still a discussion on the push/pull question at 
all.  Once you consider these details, it becomes clear that push is an 
unmitigated diaster.

> (See earlier suggestions that the "push" mechanism use a template message 
> with references to other content.) 

Which is a concession by you that some form of Embedded URI is necessary.  In 
fact, it was those suggestions of yours that made me realize that fact.

> We're trying to figure out whether all of this should be implemented by the 
> client interacting with the IMAP server alone or by interacting with the 
> submission server.

It is far more complicated than that.  It is a question of roles: of the 
client, of the IMAP server, and of the MSA.

> Again, the same can be said for the IMAP SUBMIT command in the push proposal. 
> I don't think it's impossible, but this raises the ante.

Wrong, unless you wish to mandate that the IMAP server (and ultimately, every 
other protocol which has a submission mechanism) have an embedded client for 
other protocols.  Otherwise, SUBMIT is useless for attachments.

I know what you're going to say: we're just putting in a CATENATE and SUBMIT 
command into IMAP to make it easy for cell phones to forward messages, and we 
don't care about attachments.

But think about how this looks to the larger community: a great deal of 
existing IMAP server infrastructure will be broken, and a large additional 
mandate added to IMAP, to put in a SUBMIT command that is useless for 
attachments!

This is why you are getting such strong push-back against push from the IMAP 
server community.

>> pull.
> I disagree. Embedded URI is something that can be done from either the IMAP 
> server or the submission server.

You miss the point.

In order to do Embedded URI the agent which resolves these URIs has to 
have clients which are capable of resolving those various URIs.  At a 
minimum, the necessary protocols are IMAP, NNTP, POP3, HTTP, and FTP.

In push, this must be done in *every* protocol that has submit.  In pull, 
this is done in only *one* protocol.

This is why Embedded URI renders pull superior.

> Therefore it makes no distinction at all 
> between using one of those mechanisms.

The distinction comes out when submission is needed outside of IMAP.  
Either all that work has to be done all over again, or it's already done.

> In fact, your draft says that the 
> advantages of embedded URI are:

These are the advantages of Embedded URI from the client standpoint.  In 
other respects, Embedded URI is a requirement as opposed to an advantage.  

For example, Embedded URI is the only way to address the requirement that 
an fcc not be the same as the message received by the recipient.  This is 
an absolute requirement for people who send attachments.

> discussion should be going on in this document in the first place.

I disagree.  People are easily overwhelmed by descriptions of mechanisms 
that lack a statement as to *why*.  In the case of pull, there are 
multiple directions with tradeoffs, and those tradeoffs have to be 
considered.

> (And on that score: This document does not give a detailed description of 
> embedded URI. It describes possible mechanisms, like "some 
> easily-identifiable form, perhaps as an added parameter to the [MIME] 
> Content-Type header", but doesn't actually make a proposal. If we are 
> actually going to be comparing mechanisms, I'd like to see the mechanism.)

Ahem.  You've done the same thing.  When it was pointed out that CATENATE 
was draft-unfriendly, you handwaved that something like Embedded URI could 
be done to solve that.  But you offered no specifics.

The basic notion of Embedded URI is clear: it has to be something comes 
out as the result of an IMAP MIME parse, and preferably from existing 
servers.  This suggests a new well-known parameter on Content-Type, which 
will show up on any BODYSTRUCTURE fetch.  The means by which it may 
interact with URLFETCH and CATENATE needs fleshing out, but there are some 
obvious directions.

If the Lemonade WG would like me to present a detailed proposal for 
Embedded URI, I will take on producing one.  However, I am *NOT* going to 
go to all that work if it is going to be shouted down with a "we won't 
even consider it."

> The present text 
> attributes advantages to one strategy without noting that they apply equally 
> well to the other strategy.

As I have shown, that is incorrect.  From the introduction, we have:

   Pull has the distinct advantage of maintaining one submission protocol,
   and thus avoids the risk of having multiple parallel and possible
   divergent mechanisms for submission.  Furthermore, by keeping the
   details of message submission in the SUBMIT server, the pull
   strategies are prepared to work with other message retrieval protocols
   such as POP, NNTP, or whatever else may be designed in the future.

With that in mind, and *in that context*, push is completely disadvantaged 
compared to pull on the issues raised later in the document.

> Can you detail what you mean by "a form of CATENATE that is savvy about 
> Embedded URIs"? What would end up on the server after you use such a 
> CATENATE?

It all depends upon what is being CATENATEd.

The first question that has to be answered is if, given Embedded URI, does 
CATENATE's syntax need to be anything other than a form of APPEND?

If CATENATE were to become a type of APPEND that resolves Embedded URIs, 
then it is no longer really a CATEATE; it is just an assembly command.  
However, the draft and fcc problems require that it distinguish between an 
Embedded URI that needs to be resolved now, vs. one that needs to be 
resolved later.

The easy answer is to leave CATENATE as-is, and have it ignore any 
Embedded URIs.  The problem is that as the client moves from drafts to fcc 
to submission, the desired form of the message will change.  This shifts 
the burden on the client to change the Embedded URIs to CATENATE 
arguments, which is precisely what we want to avoid.

A way around this may be to have the Embedded URIs tagged by when they 
should be resolved (draft, fcc, submit, recipient), and then to have this 
resolution type as an argument to the upload/assembly command (CATENATE or 
fancy APPEND or whatever).  This leaves open the question whether CATENATE 
should continue to take the arguments that it does, or if everything 
should be Embedded URIs.

Note that I listed four resolution points.  Those names are actually a 
minimum level of resolution, as opposed to a resolution level:
 . draft is "always resolve"
 . fcc is "don't resolve if saving a draft"
 . submit is "don't resolve if saving a draft or writing an fcc"
 . recipient is "don't resolve if saving a draft, writing an fcc, or
    submitting the message."

Perhaps we won't use recipient, because message/external-body arguably 
fufills that role.

-- Mark --

---

From: Pete Resnick <[email-masked]>
Date: Sat, 7 Feb 2004 15:48:53 -0600

On 2/7/04 at 10:59 AM -0800, Mark Crispin wrote:

>>store or pulled from the IMAP store.
>
>There is more to it than that.  There is also the question of 
>external content, and whether it is pushed to the MSA or does the 
>MSA pull it.

There is *not* more to "how the terms push and pull are being used" 
than that. Of course, there is an open issue about *whether* to do 
something about external content, but we haven't even gotten to the 
question of whether external content is to be pushed or pulled since 
we haven't answered the question of whether we're going to do address 
in the first place.

>This is a critical question.  It has enormous implications for 
>existing service facilities and their overall architecture.  Push 
>has the effect of declaring a great many existing facilities 
>"broken", and of closing a great many doors in how a service 
>facility is designed.

Which existing facilities are you talking about, and which of those 
would be "declared 'broken'" by a push architecture?

>>Though I don't disagree that external content (i.e., from outside 
>>of the user's IMAP store) will always be pulled, our conversation 
>>in this group to date hasn't made the distinction on that level.
>
>Which is probably why there is still a discussion on the push/pull 
>question at all.  Once you consider these details, it becomes clear 
>that push is an unmitigated diaster.

It is certainly not clear to me that push is anything near a disaster 
if we don't address the external content issue, nor is it clear to me 
why it would be if the external content was pushed from IMAP to MSA. 
Care to explain instead of just labeling things "unmitigated 
disasters"?

>>(See earlier suggestions that the "push" mechanism use a template 
>>message with references to other content.)
>
>Which is a concession by you that some form of Embedded URI is necessary.

No, if you read my response to Cyrus (who is one of the people who 
suggested it) on 21 Oct 2003, you'll see that I actually opposed 
doing embedded URI (what was being called "expand") and did not 
"concede" that it was "necessary". I don't think it is.

>  In fact, it was those suggestions of yours that made me realize that fact.

Perhaps you mistook my discussion of some sort of MIME-based markup 
of included parts (so that a client wouldn't have to re-download 
parts included in a draft) as something like embedded URI?

>I know what you're going to say: we're just putting in a CATENATE 
>and SUBMIT command into IMAP to make it easy for cell phones to 
>forward messages, and we don't care about attachments.

It's not that we don't care about attachments. It's that:

1. Attachments are too big a piece of work to address in LEMONADE.
2. The vast majority of attachments are either local storage (which 
are easier to send by current mechanisms) or publicly accessible 
(which are easier to send by reference), making assembly of other 
attachments for sending by e-mail of marginal use at best.

>But think about how this looks to the larger community: a great deal 
>of existing IMAP server infrastructure will be broken

What IMAP server infrastructure will be broken, and in what way? I 
don't understand what you mean.

>and a large additional mandate added to IMAP to put in a SUBMIT 
>command that is useless for attachments!

No question, it is an additional mandate to IMAP. But again, it is 
only useless for attachments which are not local to the client or 
publicly accessible by the recipient, which constitutes a small gain 
as far as I can tell.

>This is why you are getting such strong push-back against push from 
>the IMAP server community.

Again, stop characterizing others. We are certainly getting strong 
push-back from you. Others can judge for themselves the push-back 
we've seen from others on this list.

>In order to do Embedded URI the agent which resolves these URIs has 
>to have clients which are capable of resolving those various URIs. 
>At a minimum, the necessary protocols are IMAP, NNTP, POP3, HTTP, 
>and FTP.

I have seen no call (other than from you) for embedded URIs to NNTP 
or POP3. I don't see either one of them being put to serious use. 
IMAP is an issue if you use embedded URI for the inclusion of IMAP 
parts (required in pull, not so in push). That leaves  FTP and HTTP, 
of which again I think the majority of uses are publicly accessible.

>In push, this must be done in *every* protocol that has submit.

Which other protocols other than IMAP are you thinking of?

>In pull, this is done in only *one* protocol.
>

  It is superior because it only has to be done in one place as 
opposed to some-as-yet-unnamed-number-of other places? OK, I'll take 
that for what it's worth.

>In other respects, Embedded URI is a requirement as opposed to an 
>advantage. For example, Embedded URI is the only way to address the 
>requirement that an fcc not be the same as the message received by 
>the recipient.  This is an absolute requirement for people who send 
>attachments.

I'm so glad you're knowledge extends to all people who send 
attachments. So is this an absolute requirement for people who send 
attachments which are in their IMAP store? Is the reason *only* 
because they are charged double in storage if a copy of the 
attachment is made? Perhaps this is more of an implementation 
requirement than a requirement of embedded URI.

>People are easily overwhelmed by descriptions of mechanisms that 
>lack a statement as to *why*.  In the case of pull, there are 

Are you saying that there isn't sufficient discussion of those 
tradeoffs in draft-ietf-lemonade-submit-*? If so, how does that mean 
that such additional discussion doesn't belong in that document?

>>This document does not give a detailed description of embedded URI. 
>>It describes possible mechanisms, like "some easily-identifiable 
>>form, perhaps as an added parameter to the [MIME] Content-Type 
>>header", but doesn't actually make a proposal. If we are actually 
>>going to be comparing mechanisms, I'd like to see the mechanism.
>
>Ahem.  You've done the same thing.  When it was pointed out that 
>CATENATE was draft-unfriendly, you handwaved that something like 
>Embedded URI could be done to solve that.  But you offered no 
>specifics.

First of all, use of CATENATE does not require embedded URI to be 
useful. Surely draft-friendliness would be nice, and if it becomes a 
requirement of the WG, I will surely start discussing a specific 
mechanism. However, "BURL/Embedded URI Variant" is one of the called 
out mechanisms in your pull document. In that context, I think you 
need to flesh out the details.

Second of all, in the case of CATENATE, the markup described would be 
done *by the client* during the CATENATE *for the later use of the 
client*. It is not part of the protocol itself, but rather 
implementation advice for the client so that it doesn't have to 
re-download included content. I would be glad to contribute to the 
discussion of some implementation advice to put into the SUBMIT draft 
to make it more draft-friendly and will try to before the I-D 
deadline.

In any event, I think it's a far cry from "the same thing".

>The basic notion of Embedded URI is clear: it has to be something 
>comes out as the result of an IMAP MIME parse, and preferably from 
>existing servers.  This suggests a new well-known parameter on 
>Content-Type, which will show up on any BODYSTRUCTURE fetch.  The 
>means by which it may interact with URLFETCH and CATENATE needs 
>fleshing out, but there are some obvious directions.

I agree.

>Embedded URI, I will take on producing one.  However, I am *NOT* 
>going to go to all that work if it is going to be shouted down with 
>a "we won't even consider it."

I don't know where you get the idea that "we won't even consider it"; 
that seems like another characterization, this time on the 
willingness of push proponents to compromise. I've certainly heard 
nothing of the sort. But whether we eventually take on pull or push, 
I think having a proposal for embedded URI would be useful: It will 
give us something more serious to consider, and it will give at least 
one mechanism which we might be able to use in the push proposal for 
markup of parts to make it more draft-friendly.

>>The present text attributes advantages to one strategy without 
>>noting that they apply equally well to the other strategy.
>
>As I have shown, that is incorrect.

No, not with regard to embedded URI (which, if you look at my 
message, is the strategy that I was referring to). As I already 
pointed out, the only advantages attributed to embedded URI in the 
document are those having to do with the client which are not 
pull-specific.

>The first question that has to be answered is if, given Embedded 
>URI, does CATENATE's syntax need to be anything other than a form of 
>APPEND?
>
>If CATENATE were to become a type of APPEND that resolves Embedded 
>URIs, then it is no longer really a CATEATE; it is just an assembly 
>command.

Right. At that point, I wouldn't even call this CATENATE. It's just 
an "APPENDANDEXPAND" (or "fancy APPEND", as you say below) command.

>However, the draft and fcc problems require that it distinguish 
>between an Embedded URI that needs to be resolved now, vs. one that 
>needs to be resolved later.

Do you see draft and fcc essentially different beasts? What things 
would you expect to be different.

>Embedded URIs.

That's what I would do.

>The problem is that as the client moves from drafts to fcc to 
>submission, the desired form of the message will change.  This 
>shifts the burden on the client to change the Embedded URIs to 
>CATENATE arguments, which is precisely what we want to avoid.

Agreed.

>A way around this may be to have the Embedded URIs tagged by when 
>they should be resolved (draft, fcc, submit, recipient), and then to 
>have this resolution type as an argument to the upload/assembly 
>command (CATENATE or fancy APPEND or whatever).

Why would you want to do this at upload/assembly time instead of at 
submit time (either by a parameter to the IMAP SUBMIT command or to 
the BURL command)?

>This leaves open the question whether CATENATE should continue to 
>take the arguments that it does, or if everything should be Embedded 
>URIs.

Again, that makes it a fancy APPEND, not a CATENATE command.

>Note that I listed four resolution points.  Those names are actually 
>a minimum level of resolution, as opposed to a resolution level:
>Perhaps we won't use recipient, because message/external-body 
>arguably fufills that role.

Indeed, is there any reason not to use message/external-body with a 
Content-Type parameter as the embedded URI mechansim?

pr

---

From: Mark Crispin <[email-masked]>
Date: Sat, 7 Feb 2004 18:45:55 -0800 (PST)

On Sat, 7 Feb 2004, Pete Resnick wrote:
> There is *not* more to "how the terms push and pull are being used" than 
> that.

If external content has a bearing on whether or not push or pull is 
selected, then it is very relevant to the discussion at hand.

A discussion that excludes consideration of relevant and critical 
information (particularly at the behest of one side of the discussion) is 
unlikely to arrive at a correct conclusion.

> Which existing facilities are you talking about, and which of those would be 
> "declared 'broken'" by a push architecture?

There are large (5-6 digit user community) IMAP server facilities in 
production deployment today which have gone to great length to separate 
message retrieval from message submission, and which furthermore split the 
location of user data across multiple servers in the facility.

Having gone to great effort to split the location of user data and to 
separate the functions of retrieval and submission, push represents a 
threat -- a *MAJOR* threat -- to these facilities.

CATENATE can address split locations in push by allowing arbitrary URLs.  
That is, every IMAP server must have a built in IMAP, POP3, NNTP, HTTP, 
and FTP client.  However, this does not address separation of function.  
Nor does it address the requirement that a draft be a different form than 
an fcc, and that an fcc in turn be a different form that the submitted 
message.

Push's fatal failing is that it is simultaneously too simplistic, 
disallows what we are doing now, and mandates a *huge* burden upon every 
IMAP server.

> It is certainly not clear to me that push is anything near a disaster if we 
> don't address the external content issue, nor is it clear to me why it would 
> be if the external content was pushed from IMAP to MSA. Care to explain 
> instead of just labeling things "unmitigated disasters"?

Off the top of my head:

Disaster 1: every IMAP server must have built in IMAP, POP3, NNTP, HTTP, 
and FTP clients.

Disaster 2: every IMAP server must have built in submit client.

Disaster 3: every future message access mechanism must repeat disasters 1 
and 2.

Disaster 4: server facilities which separated their IMAP data across 
multiple servers must put them back on a single server.

Disaster 5: readonly IMAP servers must have writeable mailboxes for 
submit.

Disaster 6: server facilties which separated IMAP from submission to 
different machines (and sometimes different networks) must put them back 
on a single server.

Not all of these disasters happen at one.  Some of the disasters are the 
effect of ameliorating the other disasters.  But from the point of view of 
an IMAP server implementor, all of these disasters must be considered in 
the software.

> No, if you read my response to Cyrus (who is one of the people who suggested 
> it) on 21 Oct 2003, you'll see that I actually opposed doing embedded URI 
> (what was being called "expand") and did not "concede" that it was 
> "necessary". I don't think it is.

You are splitting hairs.  Embedded URI is simply a form of "reference to 
other content."

> Perhaps you mistook my discussion of some sort of MIME-based markup of 
> included parts (so that a client wouldn't have to re-download parts included 
> in a draft) as something like embedded URI?

Not at all.  Instead, I took your handwave, and from it built something 
with substance and use.

> 1. Attachments are too big a piece of work to address in LEMONADE.

Whoa!  I can just see this how this plays now: the Lemonade Working Group 
is removing attachments from something you can submit in email!

> 2. The vast majority of attachments are either local storage (which are 
> easier to send by current mechanisms) or publicly accessible (which are 
> easier to send by reference)

Wrong.  I need to send attachments which are neither local storage nor 
publicly accessible all the time.  I see no point to this work if it does 
not do something to make attachments less clanky.

> What IMAP server infrastructure will be broken, and in what way? I don't 
> understand what you mean.

If push is adopted, server facilities with tens of thousands of users will 
have to be re-architected and reconfigured.

> it is only 
> useless for attachments which are not local to the client or publicly 
> accessible by the recipient, which constitutes a small gain as far as I can 
> tell.

Are you saying that a fix to a problem that I deal with every day of my 
life is a "small gain"?

>> This is why you are getting such strong push-back against push from the 
>> IMAP server community.
> Again, stop characterizing others. We are certainly getting strong push-back 
> from you. Others can judge for themselves the push-back we've seen from 
> others on this list.

I count at least three other IMAP server implementors who have also pushed 
back.

> I have seen no call (other than from you) for embedded URIs to NNTP or POP3. 
> I don't see either one of them being put to serious use.

Do you seriously mean to say that you believe that nobody forwards mail 
from NNTP?

I respectfully suggest that you are very much out of the loop if you 
really believe that.

> That leaves  FTP and HTTP, of which again I think the majority 
> of uses are publicly accessible.

That's mainly because FTP is insecure.  We really need SCP as one of the 
mechanisms.

> Which other protocols other than IMAP are you thinking of?

POP3.  NNTP.  Any future access protocol -- surely nobody thinks that IMAP 
will be the last word in access protocols!

> I'm so glad you're knowledge extends to all people who send attachments. So 
> is this an absolute requirement for people who send attachments which are in 
> their IMAP store?

Yes, I have very extensive knowledge on the question of not including 
attachments in the fcc.  Our first version didn't have that capability.  
We had to add it pretty quickly.

> Is the reason *only* because they are charged double in 
> storage if a copy of the attachment is made?

I doubt that this is the only reason, since it isn't my reason.  But it 
probably is a reason for many people.

> Are you saying that there isn't sufficient discussion of those tradeoffs in 
> draft-ietf-lemonade-submit-*? If so, how does that mean that such additional 
> discussion doesn't belong in that document?

Yes, and some of the tradeoffs involve tradeoffs between pull variants 
which the submit document didn't consider.

> First of all, use of CATENATE does not require embedded URI to be useful. 
> Surely draft-friendliness would be nice, and if it becomes a requirement of 
> the WG, I will surely start discussing a specific mechanism.

It "would be nice" to be usable with drafts?

It "would be nice" to allow fccs to omit attachments?

I don't see those as "nice".  I see those as absolute requirements.

> However, 
> "BURL/Embedded URI Variant" is one of the called out mechanisms in your pull 
> document. In that context, I think you need to flesh out the details.

It would be much easier for me to flesh out Embedded URI than for you to 
flesh out your "template messages with references to external content", or 
how CATENATE can be made other than draft-hostile and separate-form-fcc 
hostile.

What needs to be determined first is if there is enough WG interest to see 
any of this fleshed out.

> Second of all, in the case of CATENATE, the markup described would be done 
> *by the client* during the CATENATE *for the later use of the client*.

So, now the client must do all the parsing?  Wasn't the whole idea of this 
exercise to make things easier for small clients?

> I don't know where you get the idea that "we won't even consider it"; that 
> seems like another characterization, this time on the willingness of push 
> proponents to compromise. I've certainly heard nothing of the sort.

In the spirit of compromise, CATENATE in some form is in the pull 
proposal.  Pull acknowledges a need to do some level of assembly in IMAP.

There does not seem to be a corresponding spirit of compromise within 
push.  If there is, it has been so muted as to be completely inaudible to 
me.

> Do you see draft and fcc essentially different beasts? What things would you 
> expect to be different.

Yes, they are different.

Drafts will almost always have pointers to external content rather than 
include the content itself.  The idea is to enable fast downloads of 
drafts.

Fccs will assemble some external content.  It's likely that fccs will 
include forwarded messages and/or replyed-to text.  It's also likely that 
fccs will exclude some, if not all, attachments.

Submissions will assembly most external content, excepting only that 
content that the recipient is supposed to fetch himself.

>> fancy APPEND or whatever).
> Why would you want to do this at upload/assembly time instead of at submit 
> time (either by a parameter to the IMAP SUBMIT command or to the BURL 
> command)?

That begs the question of what value is there to the CATENATE command.

> Content-Type parameter as the embedded URI mechansim?

As I recall, there were deficiencies identified in message/external-body 
which make it unsuitable for an embedded URI mechanism.  Chris would 
remember the details better than I would.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Mon, 9 Feb 2004 14:26:03 -0800

Setting fire to strawmen may produce heat, but it won't
give us much light.

I've made some comments below, but I encourage folks
who plan to contribute to the evaluation of the push vs.
pull documents to read the push and pull documents rather than
relying on this discussion.  The smoke is getting in my eyes,
personally, and I read them before this started.

At 6:45 PM -0800 02/07/2004, Mark Crispin wrote:
>>than that.
>information (particularly at the behest of one side of the 
>discussion) is unlikely to arrive at a correct conclusion.

If you are arguing that the group must decide whether to support external
attachments (not local to client, client's IMAP store, and not 
publicly available
to the recipients) before deciding on push vs. pull, I suggest you 
ask the working
group chairs to call for consensus on this point.  My reading of this text
from the charter:

>  Enhance the existing IMAP4 message retrieval and/or message
>submission (RFC 2476) protocols to satisfy the requirements for
>forwarding a message and/or its attachments without downloading
>the message to the client and subsequently uploading the message to a
>server.

is that is is limited to attachments already on the server, and that going
beyond that is well  outside the charter.  If we are going all the way to
an external composition protocol, using arbitrary protocols to collect
the pieces of the composed message, I personally believe neither SUBMIT
nor IMAP is well suited to the task.

To put it more strongly, I believe that the charter is clear, and that much
of the concern Mark expresses here is around functionality the working
group has no consensus to tackle.

>production deployment today which have gone to great length to 
>separate message retrieval from message submission, and which 
>furthermore split the location of user data across multiple servers 
>in the facility.
>
>Having gone to great effort to split the location of user data and 
>to separate the functions of retrieval and submission, push 
>represents a threat -- a *MAJOR* threat -- to these facilities.

I find it interesting that you see this in terms of a threat to the facilities.
Are you concerned about specific losses of functionality?  Are you
concerned about slow deployment because of costs?

I can think of several ways to use PUSH at the protocol level and still have
outbound queues on separate disk arrays, etc.  If these folks find this
to be a valuable protocol extension, they will no doubt do the same.
If they don't,  then presumably the use cases motivating this are not
compelling for them, and they wouldn't support push or pull for
forward without download.

To go on to Mark's disasters:

>Off the top of my head:
>
>Disaster 1: every IMAP server must have built in IMAP, POP3, NNTP, 
>HTTP, and FTP clients.

This is not true.  The chartered use does not create this requirement at all.

>Disaster 2: every IMAP server must have built in submit client.

Every IMAP server must be able to use the Submit facility, which is not
quite the same.  Explaining why this is a "disaster" and not a normal 
consequence
of the engineering choice would help transform this from a flat statement
of preference to useful input.

>Disaster 3: every future message access mechanism must repeat 
>disasters 1 and 2.

Not true.  One isn't true, two isn't proved to be a disaster, and there is no
requirement on other messaging systems to adopt this strategy.

>multiple servers must put them back on a single server.

Apparently presumes a specific implementation and assumes facts which 
have not been
presented to this working group.  There are lots of deployment scenarios where
this would not be the case.

>Disaster 5: readonly IMAP servers must have writeable mailboxes for submit.

How did you come to the conclusion that read only IMAP servers would offer
this facility?

>different machines (and sometimes different networks) must put them 
>back on a single server.

Again, apparently presumes a specific implementation and assumes facts
which have not been presented to the working group.

>Not all of these disasters happen at one.  Some of the disasters are 
>the effect of ameliorating the other disasters.  But from the point 
>of view of an IMAP server implementor, all of these disasters must 
>be considered in the software.

To say this gently, these "disasters" seem to arise out of a mistaken 
sense of the requirements
and mainly to require a calm application of software engineering and 
deployment.   No one
is asking anyone to rip up server farms and replant; no one is asking 
that IMAP grow the
kitchen garden in its sink.  This is a protocol enhancement to 
support a common use case,
and it will require work to implement and deploy whatever path is 
chosen.  We need
go forward with our decision understanding that reality and making 
the engineering choices
it implies, but without a sense of panic or disaster at chimera and 
without a nimby view
of change.

Speaking personally, as ever,
				regards,
					Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Mon, 9 Feb 2004 15:09:47 -0800 (Pacific Standard Time)

On Mon, 9 Feb 2004, Ted Hardie wrote:
> attachments (not local to client, client's IMAP store, and not publicly 
> available to the recipients) before deciding on push vs. pull

Now you're setting fire to a strawman.

Nowhere did I say that the group "must decide whether to support external 
attachments before deciding on push vs. pull."

It is, however, quite relevant to a discussion of push vs. pull that the 
current push proposal is hostile to external attachments, and that it is 
possible to build pull so that it is not hostile to external attachments.

It is relevant to the discussion because the impact of standarding a 
solution to any problem often goes far beyond the problem space.  This is 
particularly the case with harmful impact.

> If we are going all the way to

I do not disagree.

I believe that push (CATENATE+SUBMIT) will be treated as a general purpose 
composition protocol; that the lack of support for attachments, drafts, 
and fccs will be amended by means of extensions; and that there is nothing 
that the Lemonade WG can do (or say) that would prevent such an outcome.

I consider such an outcome to be extraordinarily harmful.

It is one thing to appeal to the charter to limit the scope of 
functionality that a WG works on.  It is quite another to appeal to the 
charter to close the WG's eyes to what may be done with its work.

> concerned about slow deployment because of costs?

No, I am concerned about the fact that push violates the architecture of a 
deployed facility.  I'm not talking about "separate disk arrays"; I'm 
talking about separate machines on separate networks.

I'm talking about readonly IMAP servers which contain shared (group) 
mailboxes.  It is impossible to CATENATE on these servers.  Push insists 
that all mailboxes be resident upon a readwrite IMAP server.

> This is not true.  The chartered use does not create this requirement at all.

What surety do you offer that the Lemonade charter will remain a permanent 
restriction upon message submission?

There is no surety.  We have to consider what will happen to this 
post-Lemonade.

> consequence of the engineering choice would help transform this from a 
> flat statement of preference to useful input.

In order for an IMAP server to have a submit facility, the users of that 
IMAP server must have the ability to upload (via CATENATE) to that IMAP 
server.  This declares our readonly group IMAP servers to be 
non-compliant.

In order for an IMAP server to submit, the IMAP server must be in the path 
for submission.  This declares our server architecture, in which IMAP 
servers are on a different network from the submit servers, to be 
non-compliant.

In order for an IMAP user to submit, the credentials for message 
submission must be equivalent to the credentials for message access.  This 
declares our userspace architecture, in which the two are independent 
credentials, to be non-compliant.

> have not been presented to this working group.  There are lots of 
> deployment scenarios where this would not be the case.

By design, UW has multiple independent servers.  We split user space and 
function space.  My personal mail is not on the same server as the support 
inboxes that I track.  Nor do authentication credentials for one 
necessarily coincide with credentials for the other.

We do not have a single monolithic IMAP server which has access to all 
mailbox data which a user may choose to forward in a message.

> How did you come to the conclusion that read only IMAP servers would offer

Of course they would not.  That's the problem.  How is this to work if the 
user forwards a message from a readonly IMAP server?

I read a message from an IMAP server called support.  The message went to 
the product support mailbox, but it turns out that the message really 
should be handled by user services and thus needs to be forwarded to them.  
The problem with push is, I can't CATENATE on "support" since "support" is 
a readonly server for me.  I can CATENATE on the IMAP server called 
"mrc.imap", but "mrc.imap" doesn't have access to the messages on 
"support".

This isn't a problem with pull.

>> different machines (and sometimes different networks) must put them back on 
>> a single server.

By design, UW has IMAP servers on different machines/subnets from submit 
servers, which in turn are different from incoming SMTP servers.  
Suddenly, Lemonade push decrees that we can't do that any more; the IMAP 
servers now much have a path to the submit servers, and submission now 
must use IMAP credentials instead of the separate submit credentials.

This isn't a problem with pull.

> sense of the requirements and mainly to require a calm application of 
> software engineering and deployment.  No one is asking anyone to rip up 
> server farms and replant; no one is asking that IMAP grow the kitchen 
> garden in its sink.

Wrong!

If Lemonade results in a declaration that certain server farms are 
incompatible with the standard that Lemonade has defined, then the 
management of those server farms will come under extreme pressure to 
comply with Lemonade.

Once the bookstore starts selling new handhelds and cell phones with 
Lemonade technology, the purchasers will be very distraught to find that 
these will not work with our facilties, and they will scream bloody 
murder.

For better or worse, Lemonade represents something that can not be ignored 
by existing server farms or IMAP server implementations.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Mon, 9 Feb 2004 16:28:23 -0800

At 3:09 PM -0800 02/09/2004, Mark Crispin wrote:
>>If you are arguing that the group must decide whether to support 
>>external attachments (not local to client, client's IMAP store, and 
>>not publicly available to the recipients) before deciding on push 
>>vs. pull
>
>Nowhere did I say that the group "must decide whether to support 
>external attachments before deciding on push vs. pull."
>
>It is, however, quite relevant to a discussion of push vs. pull that 
>the current push proposal is hostile to external attachments, and 
>that it is possible to build pull so that it is not hostile to 
>external attachments.

"hostile to external attachments" is not the term I would use, you 
will no doubt
be surprised to learn.  Its scope is limited by design, and it is not 
intended to
cover a complete all-uri-scheme inclusion mechanism.  That's a feature, in
my opinion.

>
>
>I believe that push (CATENATE+SUBMIT) will be treated as a general 
>purpose composition protocol; that the lack of support for 
>attachments, drafts, and fccs will be amended by means of 
>extensions; and that there is nothing that the Lemonade WG can do 
>(or say) that would prevent such an outcome.

And I disagree.  One, with your consistent use of "lack of support 
for attachments"
when the class of objects not included is very different from the common use of
the term.  Two, with your prediction that extensions will automatically expand
the very useful scope of the initial proposal to some general purpose 
composition
protocol.  Three, with the implicit assumption that Pull would not be similarly
twisted out of shape by later forces.

>functionality that a WG works on.  It is quite another to appeal to 
>the charter to close the WG's eyes to what may be done with its work.

If you wish to expand the scope of work the group will work on, you should
amend the charter.  As it stands, you seem to be arguing that the group
should build to meet the eventual development of a general purpose composition
protocol, without arguing that it should actually build such a general
purpose composition protocol.  From my perspective, if it is building
to meet that eventuality, the group would need to develop at least an
initial architecture for the eventual protocol.  I disagree, both with the
supposition and the scope creep, but it does seem to be the outcome
of your argument.  And that alone looks like it needs a charter amendment
to my eyes.

This is not meant to torch another strawman, as we have enough alight
as it stands.  I simply mean that if this is the working group's vision
of where this is going, it has to plan enough to get it right.

>No, I am concerned about the fact that push violates the 
>architecture of a deployed facility.  I'm not talking about 
>"separate disk arrays"; I'm talking about separate machines on 
>separate networks.
>
>mailboxes.  It is impossible to CATENATE on these servers.  Push 
>insists that all mailboxes be resident upon a readwrite IMAP server.

No, it does not.  It says that if you are going to take advantage of 
forward without
download, you need a readwrite IMAP server.  That's a real 
engineering trade off,
and it bears repeating.  But that doesn't mean that you need to re-architect
anything, as the current mechanism (download and upload to  the appropriate
server) is not destroyed by the introduction of this one.

>What surety do you offer that the Lemonade charter will remain a 
>permanent restriction upon message submission?
>

I can only say that as a member of this working group I would oppose 
it.  Further,
there is no surety that the IETF will not decide instead to deprecate this
message submission mechanism or IMAP as a part of the mail handling 
infrastructure.
After all, there is no surety in the future.

As it stands, though, we have a task at hand.  By imagining some future task
that is much larger without any reason to believe it would be our 
work to do, we
are hindering getting this work done at all.

>>Every IMAP server must be able to use the Submit facility, which is 
>>not quite the same.  Explaining why this is a "disaster" and not a 
>>normal consequence of the engineering choice would help transform 
>>this from a flat statement of preference to useful input.
>
>In order for an IMAP server to have a submit facility, the users of 
>that IMAP server must have the ability to upload (via CATENATE) to 
>that IMAP server.  This declares our readonly group IMAP servers to 
>be non-compliant.

No, it declares that they do not offer this facility in that configuration.

>submission must be equivalent to the credentials for message access. 
>This declares our userspace architecture, in which the two are 
>independent credentials, to be non-compliant.

Again, it doesn't have to.  It may have the affect that the users' 
credentials and
the servers credentials' are taken together to mean that a submission should be
accepted.  That doesn't mean your existing credentials would work as they do
now or are "non-compliant".

>>>Disaster 4: server facilities which separated their IMAP data 
>>>across multiple servers must put them back on a single server.
>>Apparently presumes a specific implementation and assumes facts 
>>which have not been presented to this working group.  There are 
>>lots of deployment scenarios where this would not be the case.
>
>By design, UW has multiple independent servers.  We split user space 
>and function space.  My personal mail is not on the same server as 
>the support inboxes that I track.  Nor do authentication credentials 
>for one necessarily coincide with credentials for the other.
>
>We do not have a single monolithic IMAP server which has access to 
>all mailbox data which a user may choose to forward in a message.

Nor is this required by a push architecture.  Nothing in the above is 
an argument
against PUSH-based forward without download.

>Of course they would not.  That's the problem.  How is this to work 
>if the user forwards a message from a readonly IMAP server?

By using exactly the same mechanism as is used today.

>
>>>Disaster 6: server facilties which separated IMAP from submission 
>>>to different machines (and sometimes different networks) must put 
>>>them back on a single server.
>By design, UW has IMAP servers on different machines/subnets from 
>submit servers, which in turn are different from incoming SMTP 
>servers.  Suddenly, Lemonade push decrees that we can't do that any 
>more; the IMAP servers now much have a path to the submit servers, 
>and submission now must use IMAP credentials instead of the separate 
>submit credentials.
>

Exactly the same "doesn't have a path" problem can arise with PULL.  Having
a submit server in the DMZ because it is also the outbound MTA is common; that
may not currently have any access to non-SMTP traffic inside the firewall.
That would have to change with PULL, since it would have to allow that
server to PULL data from any of the IMAP servers which might be referenced.

>>To say this gently, these "disasters" seem to arise out of a 
>>mistaken sense of the requirements and mainly to require a calm 
>>application of software engineering and deployment.  No one is 
>>asking anyone to rip up server farms and replant; no one is asking 
>>that IMAP grow the kitchen garden in its sink.
>
>Wrong!
>

There is a very big difference between declaring something incompatible
(which implies the old methods don't work) and adding a mechanism
to a protocol that leaves the old mechanisms intact.  The second is
being proposed here, not the first.

>Lemonade technology, the purchasers will be very distraught to find 
>that these will not work with our facilties, and they will scream 
>bloody murder.

And they will scream bloody murder if your SUBMIT servers have not
been upgraded to support PULL, too.

>For better or worse, Lemonade represents something that can not be 
>ignored by existing server farms or IMAP server implementations.

No one is proposing that the existing mechanisms be torn out, and both
proposed mechanisms require upgrades to existing facilities.

For better, I believe.  Your mileage may vary.

Again, speaking personally,
				regards,
					Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Mon, 9 Feb 2004 18:37:05 -0800 (Pacific Standard Time)

On Mon, 9 Feb 2004, Ted Hardie wrote:
> "hostile to external attachments" is not the term I would use, you will no 
> doubt be surprised to learn.  Its scope is limited by design, and it is not 
> intended to cover a complete all-uri-scheme inclusion mechanism.  That's a 
> feature, in my opinion.

The scope of IMAP (and earlier of POP) is limited by design, and is not 
intended to include message submission.

For IMAP, RFC 3501 says:
IMAP4rev1 does not specify a means of posting mail; this function is
handled by a mail transfer protocol such as RFC 2821.

Similar text appears in the older IMAP specifications, e.g. in RFC 1176:
Like POP, IMAP2 specifies a means of accessing stored mail and not of
posting mail; this function is handled by a mail transfer protocol
such as SMTP (RFC 821).

In the POP3 specification (RFC 1939), we find:
  When the user agent on a client host wishes to enter a message
  into the transport system, it establishes an SMTP connection to
  its relay host and sends all mail to it.  This relay host could
  be, but need not be, the POP3 server host for the client host.

In the POP2 specification (RFC 937), we find:
The intent of the Post Office Protocol Version 2 (POP2) is to allow a
user's workstation to access mail from a mailbox server.  It is
expected that mail will be posted from the workstation to the mailbox
server via the Simple Mail Transfer Protocol (SMTP).  For further
information see RFC-821 [1] and RFC-822 [2].

This is a feature, in my opinion.

The point is that this is all irrelevant.  It doesn't matter what my opinion 
is.  Nor does it matter that the specifications all say that access protocols 
do not post.  The IMAP specification does not have the force of veto over 
Lemonade's decision.  Nor do I.

We (meaning the entire Lemonade WG) can not take comfort that the scope of 
forward-without-download does not contain a complete inclusion mechanism. We 
must consider what may happen when a future effort builds upon what we do.

The differences between push and pull are negligible in terms of protocol over 
the wire.  Both can be restricted in scope to Lemonade's specific forward 
without download.  What is very different is what happens when a future effort 
overturns that restriction.

There are three possibilities of such a follow-on to push:
(1) The future effort decides that push (CATENATE+SUBMIT) is a dead end,
and builds a completely new submission facility which is likely to be
pull-based.
(2) The future effort eschews reinventing the wheel, and extends push.
(3) There will never be such a future effort.

I believe that when you dismiss my worries by pointing to the limited scope of 
Lemonade, you are in effect contending that (1) or (3) are more likely than 
(2).  [If this is not the case then I have missed your point.]

I believe that (3) is extremely unlikely.  The bad thing about (1) is that of 
annoyance: effort wasted in building push when it was known that pull was the 
correct long-term solution, and yet another protocol wart that will have to be 
supported for an indefinite time even though something better exists.

My real fear is (2).  You've implied that you don't consider (2) to be likely; 
you've even implied that you agree that (2) is highly undesirable.

I am less sanguine.

> And I disagree.  One, with your consistent use of "lack of support for 
> attachments" when the class of objects not included is very different from 
> the common use of the term.

I'm not sure what you mean by this.  I use attachments in multiple mail 
clients, and most commonly in Pine; and thus my use is in line with how Pine 
defines "attachments".

If you feel that Pine's use of "attachments" is not the "common use of the 
term" then I am bewildered at what that may be.

> Two, with your prediction that extensions will automatically expand the very 
> useful scope of the initial proposal to some general purpose composition 
> protocol.

As specified, CATENATE doesn't solve forward-without-download when the user is 
on an IMAP server that does not give the user write privileges. That *is* in 
the Lemonade charter.

Nor does it solve the problem that users of desktop or web based clients can 
not attach files from a shell server without having to download the file to the 
client first.  That may not be in the Lemonade charter, but it is a problem 
that users of mobile clients face now.  I encounter it every day.

The obvious fix to both problems is to extend CATENATE to accept any arbitrary 
URL.  That's my feared outcome (2).

> Three, with the implicit assumption that Pull would not be similarly twisted 
> out of shape by later forces.

On the contrary, I assume that pull *will* be twisted.  That is part of pull's 
design.

> amend the charter.

I think that you're torching a strawman here.

I do not wish to expand the scope of work the group will work on.  I wish that 
the group consider how that work may be expanded upon in the future.  The group 
must decide between two competing proposals which otherwise are largely 
equivalent, and whose differences would seem to be cosmetic to most observers.

> As it stands, you seem to be arguing that the group should build to meet the 
> eventual development of a general purpose composition protocol, without 
> arguing that it should actually build such a general purpose composition 
> protocol.

No, I argue that the group should build with the assumption that future efforts 
expand its work, as opposed to building with the assumption that its work will 
be a dead end.

> From my perspective, if it is building

For better or worse, forward-without-download is a revision to submit.  Either 
we expand the existing submit protocol to do pull, or we expand the existing 
access protocol (IMAP) to do push.

You seem to be arguing that:
1) push is an architectural dead end, and will surely not lead to the eventual 
protocol
2) pull is an initial architecutre for the eventual protocol
and that since a charter amendment is necessary to do the eventual protocol 
that push is preferable.  [Again, please correct me if I am misstating your 
position.]

I believe that whatever we decide -- push or pull -- will wind up being the 
initial architecture for the eventual protocol.

I do not believe that push is a dead-end.  Push can be made to work as the 
eventual protocol; the extension to CATENATE is obvious.  There will be 
pressure not to reinvent the wheel by creating yet another submit mechanism.

> of where this is going, it has to plan enough to get it right.

I am not opposed to amending the charter to take on the task of a general 
composition protocol, although I think that it is unnecessary if pull is 
selected.

If push is selected, I think that a charter amendment is necessary.

>> Push insists that all mailboxes be resident upon a readwrite IMAP server.
> No, it does not.  It says that if you are going to take advantage of forward 
> without download, you need a readwrite IMAP server.  That's a real 
> engineering trade off, and it bears repeating.

So, as a "real engineering tradeoff", we are seriously considering *not* 
solving a charter item for a current real-world situation?

> I can only say that as a member of this working group I would oppose it. 

I wish that I could take comfort in that.  I don't.

> that is much larger without any reason to believe it would be our work to do, 
> we are hindering getting this work done at all.

The difference is that I don't see it as a future task.

I am a mobile client user.  I use a laptop with a CDPD modem every day while 
I'm on the ferry going to/from work.  Most of that traffic is email. I use 
Pine, not just because I am a member of its development team, but also because 
it's the *only* email client which is tolerable with CDPD.

For my everyday mobile client use, forward-without-download has limited value. 
I've already read the silly message, and it's in my client's cache.  It may be 
a few more bytes to upload it, but that has to be weighed against the extra 
RTTs to do forward-without-download with either push or pull.  FWIW, push seems 
to have more RTTs than pull.

Now, if the message has attachments, that makes a difference.  I may not have 
downloaded those attachments to read the message, and I certainly don't want to 
upload them.

The problem is, I'm constantly needing to attach files which are not on my 
laptop but instead are on the UNIX system at work.  I need to do that more 
often than I need to forward messages.

>> server. This declares our readonly group IMAP servers to be non-compliant.

Unfortunately, history shows us that within a relatively short time after 
either push or pull is adopted by Lemonade, we will see the advent of clients 
which insist upon using the Lemonade mechanism (either push or pull) and will 
not have a capability to use the old-fashioned way via submit.  Such clients 
will issue an error message stating that the IMAP server is "deficient."

You can't say that this won't happen.

>> In order for an IMAP user to submit, the credentials for message submission 
>> must be equivalent to the credentials for message access.
> credentials and the servers credentials' are taken together to mean that a 
> submission should be accepted. 

You're missing the point, which is that the current push SUBMIT proposal for 
IMAP assumes that the credentials used to authenticate to the IMAP server in 
some way relate to submit credentials.

Put another way, the proposed SUBMIT command assumes that IMAP credentials are 
equivalent to submit credentials.  It may also assume trust between the IMAP 
server and MSA.

> Nor is this required by a push architecture.  Nothing in the above is an 
> argument against PUSH-based forward without download.

The problem is that you need the monolith to do push-based forward.

In a non-monolith world, either every IMAP server needs to allow every 
submit-privileged user to do CATENATE, or every IMAP server needs to have 
access to mailboxes on every other IMAP server.

>> How is this to work if the user forwards a message from a readonly IMAP 
>> server?

Are you supposing that every client will support both the old way and the new 
way forever?  If not, what do you mean?

> Exactly the same "doesn't have a path" problem can arise with PULL.  Having a 
> submit server in the DMZ because it is also the outbound MTA is common; that 
> That would have to change with PULL, since it would have to allow that server 
> to PULL data from any of the IMAP servers which might be referenced.

I will conceed that point.  My only answer is that we gave up having the 
submit server co-exist with the outbound MTA (much less the inbound MTA!) 
long ago.  They're all separate boxes.

> being proposed here, not the first.

True, but client authors have a way of doing the first even if it wasn't 
intended by the WG.  That has been the bane of my existance over the past 
several years.  My experience is not unique.

>> these will not work with our facilties, and they will scream bloody murder.

Indeed they will.

The difference is that pull just involves adding functionality.  Push 
involves revoking architectural decisions first.

-- Mark --