Subject: RE: [lemonade] IMAP push/pull plan

From: "Glenn Parsons" <[email-masked]>
Date: Tue, 23 Dec 2003 12:42:42 -0500

Folks,

I'd like to thank Pete & Randy for their timely document submissions.

The end of year cheer has distracted me from keeping us on course.  Notably,
there was no call last week. 

So given the holidays and the current debate on the details of the new
documents, let me suggest a new discussion thread to lead us to a decision
to choose only one mechanism.

To recap, we have the following documents:

> IMAP push/pull comparison - author: Randy 
> draft-ietf-lemonade-submit-01 
>  - WG document for the chosen method and rationale 
>  - additional details may be included here or in separate documents 
> 
> IMAP CATENATE - author: Pete 
> draft-ietf-lemonade-catenate-01  (new)
	- WG document as it is needed for push and pull

> IMAP pull details 
>     IMAP urlauth - authors:  Chris & Mark 
>     draft-crispin-imap-urlauth-04 
> 
>     IMAP BURL  author:  Chris
>     draft-newman-lemonade-compose-00 
> 
> IMAP push details - author: Randy 
> draft-gellens-lemonade-imap-push-00   (new)
> 
I will re-ask the questions I posed in Minneapolis:

Do we now have sufficient technical documentation of the options to make a
choice?
I would suggest that we do.  Let me know if you agree.

Which mechanism (push or pull) do you think the WG should choose to advance?

I encourage discussion on the list on this topic.

If I do not see any convergence within a couple of weeks I will propose a
focused conf call debate... :-)

Cheers,
Glenn.

> ----------
> From: 	Parsons, Glenn [CAR:1A11:EXCH]
> Sent: 	Saturday, November 15, 2003 6:43 AM
> To: 	IETF LEMONADE (E-mail)
> Subject: 	[lemonade] IMAP push/pull plan
> 
> Folks, 
> 
> This summary is to confirm what we decided on Monday at IETF 58 and allow
> confirmation by the list. 
> 
> The consensus was that we want to choose one technical direction for the
> forward without download requirement of the charter.  However, the room
> was not comfortable making the decision without more details on the
> technical details of the push model.
> 
> I suggested giving authors until this Monday, but the room was more
> generous suggesting Dec 17th.  Of course, authors can have documents
> prepared early.  I encourage discussion on the list as soon as the
> documents are available.
> 
> On Dec 18th,  I propose to host a conference call to see if we have
> consensus on push or pull.  The outcome of this call will be summarized
> for the list so that we can reach a consensus direction before the end of
> the year.
> 
> So specifically, the documents are: 
> 
> IMAP push/pull comparison - author: Randy 
> draft-ietf-lemonade-submit-01 
>  - will be updated by Dec 17th 
>  - WG document for the chosen method and rationale 
>  - additional details may be included here or in separate documents 
> 
> IMAP COMPOSE - author: Pete 
> draft-ietf-lemonade-compose 
>  - will be created by Dec 17th 
>  - WG document since used by IMAP push or pull method 
> 
> IMAP pull details 
>     IMAP urlauth - authors:  Chris & Mark 
>     draft-crispin-imap-urlauth-04 
>     - will be updated by Dec 17th 
> 
>     IMAP BURL 
>     draft-newman-lemonade-compose-00 
>     - will be updated by Dec 17th 
> 
> IMAP push details - author: Randy 
> draft-gellens-lemonade-imap-push 
> - will be created by Dec 17th 
> 
> Cheers, 
> Glenn. 
> 
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 23 Dec 2003 11:29:12 -0800

At 12:42 PM -0500 12/23/2003, Glenn Parsons wrote

>Do we now have sufficient technical documentation of the options to make a choice?

Speaking personally, I believe we have sufficient technical documentation to
make the choice.

>Which mechanism (push or pull) do you think the WG should choose to advance?

Again, speaking personally, I believe the working group should advance
based on the "IMAP Push" choice.  I think Randy's work is a good start
for this; I'd encourage some simplifications, but I think it is a realistic
demonstration that this can be done.

>I encourage discussion on the list on this topic.

There are three key areas where I think the push model is a better fit
than the pull:  security, deployment complexity, and code complexity.

Mark and Chris have done an admirable job in developing the "pawn ticket"
authorization scheme, but it is very important to see how pawn tickets
fit into the larger architecture.  Though we call it "IMAP Pull", the reality
is that the pull model is actually "SMTP/submit server pull" in that it
is the SMTP or Submit server which must pull together the pieces to
send the email.  For the overall architecture to have both authentication
and authorization, the pull model must actually use some form of
submission in which the sender is authenticated to the SMTP/submit server. 
Though this is growing, individually authenticated submission is
still not the norm (IP-based allow lists seem to be) and those that
seem to be seen are of the pop-before-smtp type that limit deployment
in other ways.  While I can see the value of a split authentication/authorization
model, I am quite concerned about a model that will have no authentication
at all in the common case.

It is possible, of course, that we can make use of an authentication mechanism
in the submit server a basic requirement of this protocol.  This adds, however, to the
deployment hurdle we must overcome.  As it stands, the historical tendency
of IMAP development to put complexity into the client rather than the server
means that the newly capable "SMTP/Submit Pull" servers will have to implement
a fair amount of code to act as IMAP clients.  They will also have to implement
the code required to handle pawn tickets, as well as their own form of authentication.
That's a pretty major piece of work, and I don't think we can really expect to see it in
the everyday SMTP/Submit servers right away; it will be in specialty code for
some time to come.  That's probably going to keep less capable clients using
pre-configured SMTP/submit servers, rather than discovering and using the local servers
(unless, of course, we give up on authentication or a more global authentication
mechanism is available).

Some folks might well see the restriction to specific SMTP/submit servers as a
benefit; indeed, there are several proposals to publish specific servers as
permitted senders for specific domains with the strong implication that other
senders should not be permitted.  That kills several other capabilities in the
course of fighting joe-jobs, but it is getting to be a popular sentiment.  One
issue we have to face, though, is that those proposals and other spam-driven 
changes to the SMTP environment have not yet been standardized.  Making
the locus of change for our work the SMTP/submit servers means we are
either at the mercy of or constraining other work related to spam abatement,
internationalization, etc.  Without very careful coordination, we could end up
with a protocol that will see little or no deployment, and I don't think any of
us wants to waste our time.

For me, the IMAP push model is much simpler to work with.  The user is authenticated
to the IMAP server and authorized to work with the stored objects from the beginning;
adding the new template objects and concatenation capabilities seems relatively
straightforward.  The submit-capable IMAP server is not usually mobile, unlike some of
the clients, so it can more easily be configured with authentication tokens appropriate
for connecting to local SMTP servers; a co-resident SMTP server would also be
possible and relatively easily configured.  Mark and Chris have rightly pointed out the
danger of presuming that an SMTP server would be co-resident, but even in the case
where they are not, the addition of SMTP client functionality to an IMAP server
seems to me far easier than the addition of IMAP client functionality to an SMTP/Submit
server. 

Once again, speaking personally,
			regards,
				Ted Hardie

>If I do not see any convergence within a couple of weeks I will propose a focused conf call debate... :-)
>
>Cheers,
>Glenn.
>
>
>
>----------
>This summary is to confirm what we decided on Monday at IETF 58 and allow confirmation by the list.
>
>The consensus was that we want to choose one technical direction for the forward without download requirement of the charter.  However, the room was not comfortable making the decision without more details on the technical details of the push model.
>
>I suggested giving authors until this Monday, but the room was more generous suggesting Dec 17th.  Of course, authors can have documents prepared early.  I encourage discussion on the list as soon as the documents are available.
>
>On Dec 18th,  I propose to host a conference call to see if we have consensus on push or pull.  The outcome of this call will be summarized for the list so that we can reach a consensus direction before the end of the year.
>

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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 23 Dec 2003 16:10:23 -0800 (Pacific Standard Time)

It is premature to make a choice between push and pull.

The -05 version of the URLAUTH document has substantial updates, but I had
been waiting on Chris to review it before sending it to the ID repository.
This appears to have been a mistake, so I have just sent it.

I don't know where Chris is on updating the BURL document.

Finally, we are missing a document containing Pull details corresponding
to Randy Gellens' document about Push details.  The URLAUTH and BURL
documents describe mechanisms, but not how these mechanisms would actually
be used.

I guess that I should take on writing such a document.

-- Mark --

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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 23 Dec 2003 16:43:08 -0800 (Pacific Standard Time)

> than the pull:  security, deployment complexity, and code complexity.

Needless to say, I disagree on all three points.

The claim that "individually authenticated submission is not the norm" is
startling, given the widespread deployment of mandatory SMTP SASL
authentication systems at major service providers.

Similarly, the claim that the pull model "will have no authentication at
all in the common case" is patently untrue.  This perhaps indicates that
there needs to be a pull details document to correspond with Randy's push
details document.

Push has an "attractive nuisance" aspect in that it looks simple at first
glance, but actually holds substantial IMAP protocol and deployment
complexity in the form of the CATENATE [??Why is it a draft-ietf-lemonade
I-D instead of a author document like the others??] and SUBMIT commands.

Although a complex command by nature of its somewhat bizarre syntax,
CATENATE is limited to the selected mailbox, and its grammar precludes
extensibility.

SUBMIT implies considerable glue between IMAP and SMTP, which for all its
translation still winds up on the client.  For example, note the untagged
SUBMIT response that returns SMTP commands and responses.  It also lacks
support for SMTP service extensions (although it requires DSN), meaning
that if a service extension is needed the client is out of luck.

Both commands betray "do the minimum to address the task at hand" and "put
all the complexity in the IMAP server" thinking.

If Lemonade takes the deceptively easy path now, we are likely to end up
in a Lemonade Extensions working group to fix the inadequacies in CATENATE
and SUBMIT.

-- Mark --

---

From: Pete Resnick <[email-masked]>
Date: Tue, 23 Dec 2003 21:05:04 -0600

On 12/23/03 at 4:43 PM -0800, Mark Crispin wrote:

>CATENATE [??Why is it a draft-ietf-lemonade I-D instead of a author 
>document like the others??]

I was asked to do this draft as LEMONADE working group work in the 
context of a LEMONADE work item. It seemed logical to submit it as a 
draft-ietf-lemonade-* item. The more interesting question to me is, 
why aren't BURL and URLAUTH marked as working group drafts and 
appearing on the working group page. Glenn, you should really fix 
that. (Of course, the name of the draft is not meaningful, though 
there are probably some people out there who think that because 
something has a "draft-ietf-*" name means it is somehow "special". If 
that's a worry, when Glenn asks the secretariat to mark them as 
working group drafts, he could also update the name.)

>Although a complex command by nature of its somewhat bizarre syntax,

Thanks, Mark. I always appreciate your pleasant comments.

>CATENATE is limited to the selected mailbox, and its grammar 
>precludes extensibility.

Alexey has suggested that I change the syntax to use the IMAP URL 
syntax. That would open up the syntax for extensibility. You haven't 
commented on that thread (I've asked twice for other folks aside from 
Alexey to give feedback), but I take it from this comment that you 
concur with Alexey. Please do followup to confirm, but I plan to 
update the draft to reflect IMAP URL syntax, and will also follow up 
with Lyndon regarding updates to IMAP URL to include partials.

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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 23 Dec 2003 19:31:13 -0800 (Pacific Standard Time)

> Thanks, Mark. I always appreciate your pleasant comments.

The CATENATE syntax for a message body part *is* bizarre, although you may
not have intended it to be that way.  If you did intend "5[1.3]" as a
means of identifying message content, then I respectfully suggest that in
the name of saving a few bytes in a command, you have created a
syntactically ugly and non-extensible mess.

Better would be "5 BODY[1.3]" or some sort of tagged structure such as
"(FETCH 5 BODY[1.3])".  An example of why is RFC 3516.

> Alexey has suggested that I change the syntax to use the IMAP URL syntax. That
> would open up the syntax for extensibility. You haven't commented on that
> thread

There is little need to comment on an obvious need, especially as you had
already said you were going to do it.

-- Mark --

---

From: Pete Resnick <[email-masked]>
Date: Sun, 28 Dec 2003 15:51:42 -0600

On 12/23/03 at 7:31 PM -0800, Mark Crispin wrote:

>>syntax. That would open up the syntax for extensibility. You 
>>haven't commented on that thread
>
>There is little need to comment on an obvious need, especially as 
>you had already said you were going to do it.

Actually, I had solicited more input before changing it, but if I 
read you correctly, you think the IMAP URL syntax will be fine. 
(Please correct me if I'm wrong.)

Given that, which of the following should CATENATE specify?

1. [uidvalidity] iuid [isection] from RFC 2192, leaving all future 
extensibility to future extension documents.

2. The full imapurl syntax from RFC 2192 with a limitation in the 
text that says, "This document only talks about how to deal with 
messages in the currently selected mailbox and anything else should 
be expected to return NO".

3. The general URL syntax from RFC 2396 or 2196bis with a similar 
limitation in the text as above.

4. Some other set of limitations on one of the above.

pr

---

From: Mark Crispin <[email-masked]>
Date: Sun, 28 Dec 2003 18:37:55 -0800 (PST)

On Sun, 28 Dec 2003, Pete Resnick wrote:
> 2. The full imapurl syntax from RFC 2192 with a limitation in the text that
> says, "This document only talks about how to deal with messages in the
> currently selected mailbox and anything else should be expected to return NO".

Some form of this option, preferably paralleling what URLAUTH stipulates.

-- Mark --

---

From: Pete Resnick <[email-masked]>
Date: Sun, 28 Dec 2003 20:56:22 -0600

>Some form of this option, preferably paralleling what URLAUTH stipulates.

URLAUTH stipulates that (for example) the URLs given to URLFETCH are 
valid even for mailboxes which are not selected, or even if no 
mailbox is selected. Is your suggestion that CATENATE should also 
allow for this use case? (I know at least someone indicated to me 
offline that this would be objectionable to them, but I'm just trying 
to clarify what you mean.)

pr

---

From: Mark Crispin <[email-masked]>
Date: Sun, 28 Dec 2003 19:22:18 -0800 (PST)

On Sun, 28 Dec 2003, Pete Resnick wrote:
> URLAUTH stipulates that (for example) the URLs given to URLFETCH are valid
> even for mailboxes which are not selected, or even if no mailbox is selected.
> Is your suggestion that CATENATE should also allow for this use case? (I know
> at least someone indicated to me offline that this would be objectionable to
> them, but I'm just trying to clarify what you mean.)

I would consider CATENATE objectionable if it did not allow for this use
case.

CATENATE already has severe limitations that are intrinsic in its design.
But this isn't a design limitation that you're talking about; instead,
it's an additional restriction that serves no apparent purpose.  It may
make life easier for a server implementor, but it does not assist a client
implementor in any way.

The CATENATE specification should allow any type of URL, not just IMAP
URLs.  Whether a particular server chooses to accept a particular URL is a
matter for its implementation to decide.

This probably means that you need to define some response codes to
indicate server unwillingness to deal with particular URLs.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Dec 2003 15:06:51 -0800

Several aspects of Mark's message below make me agree that having
an explicit draft on the pull model (rather than the description in
Randy's draft) would be a good thing.  I am also concerned, though,
that the we make forward progress on this as soon as possible,
and I encourage Mark (who seems to have volunteered to write the
draft) and the chairs to set the date for that draft as early as possible.

Other comments in line.

>authentication systems at major service providers.

I am glad to hear that this is more common than I thought, and
I know I (and possibly the working group) would be happy to
have more data on the deployment.  In particular, what's your
sense of the penetration of these into enterprise systems?

>there needs to be a pull details document to correspond with Randy's push

Details on how it can are certainly welcome, and data indicating that
the authentication is likely to be used are also welcome.  We need
to be clear, of course, that these are two different pieces of information.

>I-D instead of a author document like the others??] and SUBMIT commands.

The key question for me isn't "is there protocol complexity" in IMAP push,
but whether the protocol complexity is appropriate to the added functionality
and, in particular, whether the functionality is being added in the right
place in the overall architecture.  I am not under the illusion that
IMAP Push will be simple; I am trying to understand where the protocol
functionality belongs.  We disagree about that, at this point, and it
sounds as if your upcoming draft will cover why you believe it belongs
in Submit/SMTP servers rather than IMAP servers. 

>translation still winds up on the client.

I'm not sure what you mean by "translation" here.  SUBMIT does imply
a connection between an IMAP server and an SMPT/Submit server, and
the annotation mechanism Randy has proposed does involve work by
the client (as do the simpler "template" mechanisms we've discussed in
the past).  I don't think there's much dispute about that.  From a
client's perspective, one key question is how similar this work is to
existing tasks, and I personally believe that they are or can be
close to typical MUA/IMAP client tasks (again, I believe that Randy's
draft could be a bit simpler, but that it demonstrates the fundamentals
of the approach).

>all the complexity in the IMAP server" thinking.

"put all the complexity in the IMAP server" seems to be a pretty dramatic
description.  Putting the functionality in the IMAP server for this task
would be closer to my personal view.

>in a Lemonade Extensions working group to fix the inadequacies in CATENATE

Help getting them correct now would be useful, then, as a way of avoiding that
later task, right?

And while we're talking about the dangers of the easy path, I'd like to point
out the danger in the Pull model:  that Pull-based composition at the SMTP/Submit
server seems likely to degenerate into Pulls from HTTP (or POP) document stores instead
of IMAP stores.  I can easily imagine folks deciding that they wanted to reuse
HTTP for this document retrieval task (possibly with the "pawn ticket" mechanism),
thus losing the end user the other advantages of working with IMAP.  

The dangers of this attractive nuisance vs. the dangers of adding functionality
to IMAP servers for this task are, of course, a matter for further discussion.
I look forward to reading the drafts in which the Pull model is clarified, and it
may be this danger will not seem so likely in its light.  But at the moment
it seems far more problematic to me.
				regards,
					Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Tue, 30 Dec 2003 00:33:29 -0800 (PST)

> thus losing the end user the other advantages of working with IMAP.

I don't see this as a danger, particularly not with "in addtion to" rather
than "instead of".

One danger I see with the push model is that sooner or later, people will
want to use the other stores and then will want commands to push to the
IMAP server requests that will have it pull from HTTP, POP, and NNTP
servers.  That way lies madness.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Tue, 30 Dec 2003 10:03:51 -0800 (PST)

On Tue, 30 Dec 2003, Rob Siemborski wrote:
> My personal largest fear about IMAP push is similar -- that once we extend
> IMAP to support submission, we will decide that there is a need to extend
> more and more protocols (POP, NNTP, HTTP being obvious ones) with slightly
> different mail submission mechanisms, as we discover needs to source
> messages from these stores (in the absence of an IMAP server).

I also agree with this; in fact, this is one of the two basic reasons for
opposing IMAP push that underlies all other reasons.

The other basic reason is the prospect of having to track all future
developments in SMTP in IMAP push.  I note that the current IMAP submit
document pays little heed to SMTP extensions, and apparently expects that
by doing so IMAP submit will never have to consider SMTP extensions.  I do
not believe that to be a viable position.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Tue, 30 Dec 2003 11:29:42 -0800

> > messages from these stores (in the absence of an IMAP server).

There is a critical distinction here--are we sourcing *messages* from these
stores or are we sourcing *content* to be included in messages from these stores? 

I think for the PUSH architecture, we're talking about messages, and I
think that makes it relatively easy to limit the desire to extend PUSH.  I
don't see much temptation to treat general purpose object stores as the
source of submits in that case, and I think it is relatively easy to explain why using
them as sources generates complexity for the overall architecture (especially
as regards checking message syntax).

I agree that there may be later work considered to extend an existing message storage
and retrieval protocol like POP along the same lines.  That's part of a general
problem in having two different protocols in the same space, and not
something we can fix by fiat.  We can, of course, try to make sure that the message
submission mechanisms developed for one can be aligned for those that
work for the other.  Since both need to be aligned with that for SMTP, there
is already a reason to make sure that happens.  I personally believe that this
work would be out of scope for the working group at this time, but it is
important to acknowledge it could happen.

One of my presumptions about PULL has been that what could be PULLed could
be content to include in messages (e.g. specific body parts for a mime multi-part or
attachments) rather than only complete messages.  I think that heading down
that road means that you are almost guaranteed to end up in the kind of
forest of extensions that loses interoperability.  It's too easy for specific
servers to support some access protocols and others to support others.
I can tell you from reading a lot of specs that saying  "any dereferencable URI
may be included here" is a great temptation, because I see people succumb
to that temptation a lot.  It doesn't work on ground, though, as there are too
many schemes that work only in certain environments and too many for which
the retrieval mechanisms are fundamentally at odds with the protocol characteristics
for the protocol that attempts to incorporate them by reference.

If we are working from the presumption that  only a complete message
could be PULLed (as Pete has suggested), this risk goes down, but you
still get the added complexity of validating that what the access protocol provided
is a valid message.

>not believe that to be a viable position.

I don't agree that it is "all future development in SMTP", but this is nonetheless
a very important concern.  One approach, which I believe Pete intended, is
to make the IMAP portion of this as slim as possible; this helps, but doesn't
eliminate the problem entirely. 

I note, though, that the same problem occurs for PULL; it can force SMTP development
to track salient developments in the access protocols for PULL, which would include
at least those in IMAP.  No matter which connection we make, we are talking about
entanglement here, and we need to go into that with our eyes open.

As ever, speaking personally,
			regards,
				Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Tue, 30 Dec 2003 12:27:27 -0800 (PST)

> stores or are we sourcing *content* to be included in messages from these stores?

The current push proposal sources content; review the CATENATE
specification carefully.  There is currently no proposal on the table that
does not source content.

Although CATENATE could be used in pull (indeed, one of the scenarios that
I intend to discuss in a pull architecture document would use CATENATE),
CATENATE is not necessary for pull.  CATENATE is crucial to push, or at
least to the current push proposal.

> something we can fix by fiat.

This is precisely the position of the proponents of pull.  They see push
as (at best) a sidetrack that is a waste of time and effort.  At worst,
they see push as ultimately harming the later work by creating an
entrenched base.

> attachments) rather than only complete messages.

As I noted above, push has the same presumption.

> still get the added complexity of validating that what the access protocol provided

It would be very strange for pull to have this limitation when push does
not!

> entanglement here, and we need to go into that with our eyes open.

Actually, no; pull does not have this danger.

Pull leverages on existing access mechanisms.  When it feels the need to
extend an access mechanism, it attempts to do so in a way that other
applications may be able to leverage on it.  Pull is also more of a
strategy rather than an explicit protocol.

Push, on the other hand, creates transmission mechanisms which are
specific to push and are unlikely to be useful for any other purpose.
Push is an explicit protocol to implement a strategy.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Tue, 30 Dec 2003 13:11:46 -0800

>specification carefully.  There is currently no proposal on the table that

It seems  what I wrote was not clear.  Take a look at Section 3 of the
new draft, at this text:

The CATENATE command concatenates all of the message parts and appends
them as a new message to the end of the specified mailbox.

So a *message* is created which is then passed via the submit mechanism
to the SMTP flow.  From the SUBMIT point of view, if you will, the unit
remains a message.   Pete's new draft is also very clear that Catenate works
only on messages or message parts on the current IMAP server:

Use of a URL that refers to anything other than a message or message part
from the currently selected mailbox on the current IMAP server is outside of
the scope of this document, would require an extension to this specification,
and a server implementing only this specification would return NO to such a request.

This is a very clear statement on the intended limits of this approach.

>they see push as ultimately harming the later work by creating an

I think you missed my larger point:  PUSH avoids the risk that SMTP/Submit
servers will have to act as clients for multiple access protocols with different,
incompatible authentication and authorization mechanisms.  It scopes the
problem such that it is limited to protocols already dealing with
message stores (rather than generalized object stores).  That means
IMAP in the current charter.  That it might be later applied to some
other message storage/retrieval protocol is due to the historical
reluctance of the real world to settle on a single protocol in this
space.  Fitting POP and IMAP to have congruent mechanisms for
talking to SUBMIT/SMTP servers seems to me a no larger task than
fitting SUBMIT/SMTP servers with the mechanisms needed to talk
to IMAP and POP.  That it seems far less likely to lead to mechanisms
for talking to HTTP, FTP, Samba, NFS, AFS, and the rest of the
crowd is my main point here.

>strategy rather than an explicit protocol.

"When it feels the need to extend an access mechanism, it attempts to
do so in a way that other applications may be able to leverage on it"
is exactly the same kind of entanglement.  If PULL is going to
use existing access mechanisms, it will have to track them just
as PUSH would have to track SMTP.   Unless you presume that
the access mechanisms for these protocols are permanently frozen,
there is simply no way around that.  Since your text assumes
that PULL may suggest extensions of its own, I'm guessing you're
not presuming they will be frozen.

I'm personally far from sanguine about getting interoperability
from strategies rather than protocols.  Protocols seem to do
that pretty well, since they can set out the MUST/MAY/SHOULDs
of interoperability.  If we go on PULL at all, I think we must
do it as a protocol, not a generalized strategy of "stuff in submissions
can get incorporated by reference".  That *would* be a "waste of
time and effort".

>Push is an explicit protocol to implement a strategy.

Or to put it another way, it creates a protocol mechanism that is
specifically scoped to a task. 

As usual, speaking personally,
				regards,
					Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Tue, 30 Dec 2003 13:32:51 -0800 (PST)

On Tue, 30 Dec 2003, Ted Hardie wrote:
>[snip]

It's a false dichotomy to use this to distinguish push from pull.  What
you are describing is a characteristic of how CATENATE is defined, not
anything specific to either push or pull.

If BURL were defined to only accept IMAP URLs from a single mailbox on a
single server, the result would be the same.

Also, CATENATE can be used with pull.

> incompatible authentication and authorization mechanisms.

Shouldn't that "risk" (if you see it as such) be something that the IAB
and/or the IESG should weigh in on?  Push does nothing to prevent that
outcome from happening, and pull does nothing to mandate that outcome.

> not presuming they will be frozen.

You've just stated the reason for using URLs, and not some access
mechanism specific to a single protocol (such as what push defines).  URLs
are the common naming scheme.

Pull naturally evolves as the protocols used by pull evolve, because pull
uses the same direction as these protocols.  Push has to be updated each
time, because it operates in reverse.  For better or worse, most of our
data access protocols are pull-type, with SMTP standing out as being the
most significant push-type.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Tue, 30 Dec 2003 14:21:45 -0800

>anything specific to either push or pull.

I think it is fundamental to the design approaches.  There are PULL
design approaches in which the limitations are strict enough that
only previously CATENATEd message from an IMAP mailbox could
be PULLed.  But you seem to be arguing that the strength of
the PULL approach is in removing that set of limitations and planning
for a very broad applicability to various access protocols.

>and/or the IESG should weigh in on? 

Huh?

Having a technical discussion in the working group on the merits of
the different design approaches seems to be how the IETF has traditionally
worked.  Or am I utterly missing your point here?

>Push does nothing to prevent that

PUSH doesn't have this risk at all, so am I at a loss to understand that
comment.  With PUSH SMTP/Submit servers don't act as clients to
access protocols at all.  If PULL is scoped narrowly, then it might
avoid that outcome, but the argument that it should be chosen because
it allows for this mode of extension greatly heightens my personal
sense of the likelihood of this outcome.

>are the common naming scheme.

And having a common naming scheme gets so little of the real work
done for this that it is barely an advantage.  If an SMTP/Submit server
supports IMAP/POP/HTTP/FTP/SMB as access protocols, using the
same syntax for the naming scheme is not much of the problem;
actually supporting the different access methods, error conditions,
and security mechanisms makes up the real work load.  For every one
of these access methods you add, you get the entanglement burden
we've discussed.

>uses the same direction as these protocols. 

Do you mean push vs. pull when you say direction in "pull uses the same
direction as the protocols", or do you simply mean that pull's access
mechanisms co-evolve with the access methods?  If the latter, that
certainly sounds like entanglement to me and one where the deployment
problems look icky. 

As previously mentioned, speaking personally,

			regards,
				Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Tue, 30 Dec 2003 15:36:10 -0800 (Pacific Standard Time)

On Tue, 30 Dec 2003, Ted Hardie wrote:
> There are PULL

You are correct in saying that pull, by its nature, is extensible; and
that this is a strength of pull.

What you are missing is that the current push proposal is non-extensible
by fiat, not by a technical limitation.  A similar fiat can be placed on
pull.

Similarly, the current push proposal could be made extensible by removing
the text that restricts it.  The result is somewhat more complex than the
pull case, but everything is still there.  The bad part is that the
extensibility must take place on the IMAP server rather than in the SUBMIT
server.

That's the distinguishing difference.  If pull is extensible, the
extensibility is on the SUBMIT server.  If push is extensible, the
extensibility is on the IMAP server and all other servers which are part
of the extended coverage of push.

It could be argued that since push makes extensibility harder, it is less
likely to happen.  To the extent that this may be desirable, this is a
benefit of push but *not* a demerit of pull.

> worked.

When we talk about "risks" of extensibility being used in ways beyond what
is envisioned at a working group (and for that matter is outside of the
charter of the working group), and in particular if we engineer something
so as to make these "risks" less likely, then I feel that we should seek a
wider audience for guidance about such "risks."

I don't think that these are "risks".  I think that it's a good thing to
leave open the possibility of future work in an area.  If the overall
Internet architecture does not go in that direction, then it will remain a
hook that never gets used.

It's different when we do something with the conscious intent of
precluding a particular future use.

> access protocols at all.

However, IMAP servers do.  The new version of CATENATE is been extended to
take IMAP URLs; a stroke of the pen and the limitations of what kind of
URLs are provided are gone.

> If PULL is scoped narrowly, then it might

I agree with this observation.  Unlike you, I think that this is
desirable; if it's likely to happen then it seems to me that there is an
unfufilled need for this capability.

> of these access methods you add, you get the entanglement burden

However, this is *not* a problem that is unique to message submission!
Other applications (e.g. web browsers) face the same problem.  Thus,
message submission can benefit by a common solution.

The need to solve this problem does not evaporate by selecting push.  Your
argument seems to be "if we adopt push, we will create enough of a barrier
to the use of other access protocols that anyone who tries will be obliged
to give up."

Consider this gedanken experiment: suppose that it turns out that the use
of other access protocols suddenly becomes necessary.  Maybe it's a
contact to Qualcomm to sell 50 million cell phones, but only if they can
use multiple access protocols.  Would you be in a better position with
pull, or with push?

I think that the answer is pull; and that I'd be in a world of hurt if I
only had push via an IMAP server.

> certainly sounds like entanglement to me and one where the deployment

Yes, the deployment problems *are* icky; but that's the case no matter
what solution you face.  Consider the testimony about the impact that push
would have on the architecture of some existing large IMAP server farms.

I do not feel that making deployment problems ickier is going to save us
from having to get icky.

Pull doesn't make matters any ickier as long as we don't go tromping into
the icky swamp.  But, if we do have to enter the swamp in the future, pull
offers some amount of help through.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Tue, 30 Dec 2003 16:37:52 -0800

>by fiat, not by a technical limitation.  A similar fiat can be placed on

There is difference between being fiat and design.  The PUSH approach
starts from the idea that a message or the elements of the message
are in an IMAP mailbox and need to be SUBMITted into the SMTP/Submit
system, possibly with some assembly of the elements.  Boiled down,
it starts from where the message *is* and moves it to *where it needs
to be*. 

The PULL approach starts from *where the message needs to be*
and uses an access protocol to bring it from *where it is*.  If you like,
it starts from the idea that the message will need to be injected
into the SMTP/Submit system and so this is a logical place to
do the protocol work.

For me, the kind of extensibility which is inherent in the two designs seems
different. The PULL approach's design favors the kind of extension in which
multiple access protocols would be used because the SMTP/Submit
server *must* use an access protocol to retrieve the message for
submission.  The PUSH approach's design doesn't have that same bias;
its bias would be toward  multiple submission mechanisms (SMTP on port 25,
Submission on 587, potentially submission to something like MMS in
some environments).

>extensibility must take place on the IMAP server rather than in the SUBMIT

And if someone were arguing that the IMAP server should use
access protocols to gather elements of a message prior to submission,
I would argue that this was a mistake.

>wider audience for guidance about such "risks."

A wider audience is certainly appropriate, and I can think of several working
groups or mailing lists to which a pointer to the drafts and discussion would
be valuable.  discuss@apps, imaa, smtp, seive, et al would be good, and in
that context cc:ing the IESG and IAB lists would be appropriate.  But doing
that, in my opinion, is asking those lists' recipients to participate in the working
group discussion, not changing the context of the discussion.

The meta-discussion on that point probably belongs someplace else; thanks
for clarifying your view.

>URLs are provided are gone.

See above for my view on the wisdom of such a move.  Note also that I think
it is less likely, since the fundamental design isn't based on the use of such
an access protocol.

>message submission can benefit by a common solution.

A common solution to what?

>to the use of other access protocols that anyone who tries will be obliged

No, "if we adopt PUSH, the fundamental design starts from an IMAP server
with CATENATEd messages, so there is no need to use an access protocol
external to the server" --instead we use a submission protocol to inject
the message into the usual SUBMIT/SMTP system. 

This isn't a "barrier" in the same sense you seem to be thinking; it's a design
strategy.

>use multiple access protocols.  Would you be in a better position with

Recitals:

1) I don't speak for Qualcomm
2) My job as a member of this working group is to think about what is
best for the Internet, not what is best for Qualcomm.

That said, it's not a very good gedanken experiment.  You're not starting
from "here's the problem, imagine the solution based on these two designs"
you're starting from "here's the money".  If you'd like to start from a
gedanken experiment that talks about an engineering problem, I'll be happy
to spend more time on it.

>would have on the architecture of some existing large IMAP server farms.

The strains on SMTP/Submit servers seem to me much higher, since they
are also in the middle of the spam arms race and a likely need to support
new internationalization mechanisms.  The good side of that is
that some servers are being watched and upgraded; the bad side may well
be the interaction between the needs of PULL and those needs.
 
As noted, I am speaking personally,
				regards,
					Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Tue, 30 Dec 2003 18:48:25 -0800 (Pacific Standard Time)

On Tue, 30 Dec 2003, Ted Hardie wrote:
> The PUSH approach
> system, possibly with some assembly of the elements.
> and uses an access protocol to bring it from *where it is*.

This is all correct, but what you've overlooked is the CATENATE command in
the actual push proposal.  Now that it has been extended to accept IMAP
URLs, it can easily be extended to accept other forms of URLs.

If the intent is to prohibt such extensibility, then adding IMAP URLs to
CATENATE is a mistake and needs to be revoked.  I disagree with that
intent (and thus the conclusion), but that's not the point.

The point is that it's really a wash in terms of extensibility.  It would
be cleaner to extend pull, but push does not effectively block the type of
extensibility that you seem to worry about.

> different.

If you think about it, I'm arguing against you by conceeding the point
about extensibility.  I *can* extend push to do everything that I might
want to do.

It's just a question of what the result looks like.

> I would argue that this was a mistake.

But that is where push leads us!  Do you think that people in the future
are going to care about whether or not you or I think it's a mistake?

We could have much shorter IETF meetings if the sensibilities of the past
were to determine the outcome of all thorny issues.

> >The new version of CATENATE is been extended to

I agree completely on the lack of wisdom of doing that.  Nevertheless,
I feel that it's less unwise to do that than it is to have multiple submit
protocols.

I also disagree with you about it being less likely to happen in a push
world.  Need finds the way of least resistance, no matter what artificial
barriers we might choose to erect.  If it were otherwise, the flat
prohibitions against submit in POP and IMAP would have been the final
word.

> A common solution to what?

A common solution to the problem of how to unify access mechanisms, error
conditions, and security methods within the framework of a URL-based
method to access data.

> the message into the usual SUBMIT/SMTP system.

That just moves the issue from SUBMIT to CATENATE.

It doesn't matter whether your or I feel that people should insert text
from other than the selected mailbox.  People are already doing it.

The question is, how will they do it in the world that we are creating?
Will they accept a limitation that messages in the selected mailbox are
fast and everything else is slow?

> you're starting from "here's the money".

Indeed.  But isn't "here's the money" the underlying motivation?  A purely
engineering position states that forward is a long-solved problem, and
we're just talking about efficiency hacks that will be overtaken by events
once we have terabit wireless nets and mobile devices with 100GHz
processors and terabytes of storage... :-)

I don't think that we can ignore "here's the money."  We differ in that
you believe that pull creates an incentive that push does not, whereas I
believe that the incentive as being there no matter what is decided.

Pull recognizes the attraction from the get-go and embraces it.  Push
attempts to make it less attractive, but the workaround is easy and
obvious.

All it takes is a simple little extension to CATENATE, ignoring that nasty
little "thou shalt not" paragraph.  I'd probably do it myself.

Perhaps it's just that I'm wierd, and nobody else feels the incentive, and
push will go through without anyone else making that simple little
extension.  Only time will tell.

> are also in the middle of the spam arms race

Not necessarily!

UW, like most other large organizations, has separate servers for submit
vs. incoming mail.  Not only are they separate boxes, but are on
completely different subnets.

> and a likely need to support
> new internationalization mechanisms.

All the more reason to have one (and only one) submit mechanism.

-- Mark --

---

From: Rob Siemborski <[email-masked]>
Date: Tue, 30 Dec 2003 10:00:40 -0500 (EST)

> I don't see this as a danger, particularly not with "in addtion to" rather

I agree that this seems to be a feature, not a bug -- don't force the user
to have to http-download a document and the re-upload it to their SMTP or
IMAP server to do a submission.

-Rob

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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 31 Dec 2003 08:50:36 -0800 (PST)

> messages from these stores (in the absence of an IMAP server).

Rob and I are definitely on the same wavelength.... ;-)

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Dec 2003 11:28:34 -0800

>extensibility that you seem to worry about.

And this seems to be a fundamental disagreement.  I agree that
it would be possible to extend both push and pull, but I don't
think it is a wash.  From my point of view, the designs are different
enough that the balance is clearly tipped in favor of PUSH.

>But that is where push leads us! 

Again, I disagree.  PUSH starts from a message store and doesn't require
an access protocol in the common case.  Using external bodies in
a message and having the recipient collect the external objects deals
with quite a few of the less common cases.  I agree that PUSH
could be extended by having CATENATE do this work instead of
external bodies, but I don't think this is where PUSH leads us.
I *do* think that is where PULL leads us.  That's why I don't see
this as a wash.

>Indeed.  But isn't "here's the money" the underlying motivation?

It's still not useful place to start the thought experiment if you want
the result to tell you which engineering choice to make.  Let's take
the thought experiment based on a problem: the pain in forwarding
messages from one message store to another over slow or lossy links.
The time cost of downloading, then re-transmitting them is a "here's
the money/problem" element of that.  There are several solutions:
improve the speed and eliminate the loss in the links; eliminate the
need to download & re-upload the data; or make the time cost of
downloading and re-uploading less painful through scheduling, rate
reductions, etc."

I'd say that both PUSH and PULL fall into the category of solutions based
on the aim "eliminate the need to download & re-upload the data".  I'd
even say both do this, and we're now talking about the engineering balance
of other consequences of the different approaches.

>completely different subnets.

You're quite right that SUBMIT servers are or can be separate from incoming
mail.  But the spam arms race includes those servers as well, as one of
the key ways folks fight spam is by ensuring that systems within their
administrative border aren't injecting it (either because of black hats or
"owned" boxes).  That can be reactive (driven by black-list servers) or
proactive, but it is still a front in the war, so there is still a strain here
on those systems.

>All the more reason to have one (and only one) submit mechanism.

The same entanglement applies to both PULL and PUSH here, but PULL
is in a worse spot.  The IMAP server is responsible in PUSH for ensuring
that the message is valid before injecting it into the SMTP/Submit
system; where the SMTP/Submit server must validate it as it is accessed
or assembled in the PULL view.  That's a burden on the SMTP/Submit
server, and, as I said before, I think they are already in the more fragile
place in the overall system.

I shall probably not contribute again before the New Year, so happy New
Year and regards,
				Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Wed, 31 Dec 2003 12:14:25 -0800 (PST)

> enough that the balance is clearly tipped in favor of PUSH.

I agree that we disagree.

> PUSH starts from a message store and doesn't require
> with quite a few of the less common cases.

So, you expect the *recipient* to use pull in the push model?  This means
that the recepient must be given access to the data store.  That creates
an even ickier security and access control problem.

MIME external bodies have not taken off for a reason.  URLs in messages
are far more common, but those also require anonymous access.

> I agree that PUSH

Here is another point of disagreement.  If push is selected, I will find
it extremely attractive to extend CATENATE in my implementation to accept
multiple types of URLs.  I have yet to hear anything that diminishes this
attraction.

> the result to tell you which engineering choice to make.

The engineering choice depends upon an underlying premise of the need.
The "money" in my thought experiment dictates the premise and not the
engineering.

You're insisting upon selecting a premise that leads to a different
engineering choice.  That's valid for supporting your arguments based upon
that premise.  But it does not debunk the argument based upon a different
premise.

Your premise excludes message composition using data sources from outside
the mailbox which is currently being accessed by the composing client.  I
am asking you to consider what happens if that premise is invalidated.
Otherwise this entire argument runs the risk of circulus in demonstrando.

> proactive, but it is still a front in the war, so there is still a strain here

How is an IMAP server supposed to be any more immune from this than a
submit server that requires authentication?

> place in the overall system.

How is an IMAP server any better equipped to do this than a submit server?

An IMAP server does not even have the simple tools to fufill the
requirements of 8BITMIME, much less any additional requirements brought
about by i18n.

A submit server, by definition, has to be capable of validating messages
and, if necessary, reforming it.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Dec 2003 12:41:46 -0800

>an even ickier security and access control problem.

No, I meant for the case where the access protocol was other than
IMAP (e.g. HTTP).  I did not mean to imply that the recipient would collect
message parts from the IMAP store.

>multiple types of URLs.  I have yet to hear anything that diminishes this

By "handling multiple types of URLs" are you presuming that you would
hand-off the actual protocol processing using existing systems, or do
you believe you will need an API  between IMAP and them to handle
errors and related feedback?

In the use case you foresee, are you presuming that there will be
an authentication step in those accesses, or are you presuming
anonymous access?

>Otherwise this entire argument runs the risk of circulus in demonstrando.

As I noted above, one of the key questions may be whether the data sources
require authentication and authorization or do not.  The inclusion of URIs
(whether as message-external or in the body) can handle the un-authenticated
case as well or better than an extension to CATENATE, since the recipient
can dereference them as well as the server.

Further reply will have to wait; sorry about the split, but I wanted to get the
clarification on the first point made as soon as possible.
				regards,
					Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Wed, 31 Dec 2003 13:26:44 -0800 (PST)

> message parts from the IMAP store.

IMAP is not the only access protocol which requires authentication.  I, as
the sender, am more likely to have access via the access protocol than my
recipient.  Instead of pull, which puts the burden on one place (the
submit server), you seem to be advocating a push that split the burden
with the IMAP server handling the currently selected mailbox (but no other
IMAP URLs) and the recipient handling all other access (including the IMAP
store using mailboxes other than the selected mailbox).

I don't see that as viable.  If it's going to be push, then the entire
burden goes onto the IMAP server via the CATENATE command.  I think that
this is a terrible idea (thus my choice of pull) but it is less terrible
than a split pull model.

> errors and related feedback?

I'll just have to add clients for all the other protocols into the IMAP
server.  IMAP will thus become the one single-source for all your access
needs.  And when clients start to take advantage of it, there'll be
pressure on all the other IMAP server implementors to do the same.

I don't like this idea, but that's where push leads me.  I doubt that I'm
alone.

> an authentication step in those accesses, or are you presuming

Of course there'll be authentication.  There'll just have to be some means
to work out how that will happen.

> can dereference them as well as the server.

If the URIs other than the selected mailbox do not require authentication,
then the argument against pull about authentication being "icky" does not
apply.

If the URIs do require authentication, then the split-push model requires
that the recipient possess the necessary authentication credentials.  The
pull model, and the MRC-push model using extended CATENATE, uses the
sender's credentials and does not make such requirements on the recipient.

IMHO, it is far "ickier" to send my email recipients a userid and password
to access a file than it is for me to instruct my submit mechanism
(whether it be pull or fixed-push) to use my authentication credentials to
access the data.  The submit mechanism refuses to talk to me without my
providing my authentication credentials, and I use an authentication
mechanism which confirms that the submit mechanism is indeed my submit
mechanism rather than an imposter.  In other words, it trusts me and I
trust it.

Even so, I needn't give the submit mechanism unlimited authentication
credentials to access just any data on the resource.  I just need to give
it sufficient credentials to do the job that I want to it do.  There are
many ways that this can be done.  Pass-through credentials are one way.
Limited credentials for one particular use, such as URLAUTH, are another.

What's neat about URLAUTH in the pull model is that not only can I limit
the submit mechanism's access to my mail store, but I can make it so that
the URLAUTH is useless to an imposter submit mechanism (assuming that I
was careless and failed to detect the imposter when I authenticated to
it).

I don't have quite the same level of protection with the fixed-push model,
but to the point that the extended CATENATE is a type of pull it will have
the protection.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Wed, 31 Dec 2003 13:43:25 -0800 (PST)

> this is a terrible idea (thus my choice of pull) but it is less terrible
               ^^^^
Correction: "split push".

Sorry for the typo.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Dec 2003 16:04:53 -0800

>burden goes onto the IMAP server via the CATENATE command.

Deciding that the entire burden goes onto the IMAP server is contrary
to existing practice, in that folks in many environments use external
pointers by including URLs in their messages.  External bodies may
not be common, but I believe that the expectation that a recipient can
choose to dereference included URLs (or not) is pretty well
established.  So it seems to me that the idea that that all of the internal
references in a message would be dereferenced in order to do PUSH is a strawman.

If you were to take a pure taxonomy, messages with included URLs are
push/pull; SMTP pushes the reference, and the access protocol for the URL
is invoked to pull some of the content. 

And while all of this is a very interesting, I think we have to go back
to the common use case, and ask ourselves whether "forward without
download", which is one of the immediately motivating cases here,
would require anything more than what an IMAP server can do
using the local mailboxes.  

And perhaps we ough to even ask the larger question "are we
optimizing for the right use case", since the client always has the
option of accessing and including content.  For cases where content
cannot be included from the local store or through a dereferencable URI
(for whatever access reason),  that fallback is always available.

>sender's credentials and does not make such requirements on the recipient.

So there are three cases:  URIs that do not require authentication or authorization;
URIs that do require authentication or authorization where the recipient
can be expected to possess the credentials; URIs that do require authentication
or authorization where the recipient cannot be expected to possess the
credentials.  The first we agree is not an issue for this (though it may
be one for performance or code complexity).  The second works fine
with a split push/pull and is one portion of the non-local assembly class
of uses of this protocol (and remember that I think the local assembly
class will be the lion's share).  The third can be worked by using the "pawn
ticket" authorization model.  "Pure" pull is at a disadvantage here, given
that there will be few or no elements in the second class.

As has been noted, I am speaking personally,
					regards,
						Ted Hardie