Subject: RE: A suggestion for RFC1939
From: Laurence Lundblade <[email-masked]>
To: Faheem Ahmed Khan <[email-masked]>, [email-masked]
Cc: [email-masked]
Date: Mon, 27 Mar 2000 09:11:15 -0800
List-Id: <ietf-pop3ext.imc.org>

At 09:32 PM 3/27/00 +0530, Faheem Ahmed  Khan wrote:
>I agree that the UIDL to the message number mapping doesn't change during
>one session, but it can change between consecutive sessions.
>
>For example:
>there are 100 mails in the mailbox.
>I have retreived 95 and my connection to the mail server is terminated
>abruptly. Though I have issued DELE after every RETR my messages still lie
>in the mail box, and in my next connection to the mail server I have to
>match the UIDL of the message already read by me with every message in the
>mailbox before retreiving new ones.

Yes, you do have to do this as things stand now.

>BUT, if I could use UIDL with the DELE
>command I wouldn't have had bothered about that and issued a batch delete
>for all the messages already retreived and still be sure that I have not
>deleted an unread message. Wouldn't that save me from comparing the
>MessageID of every message on the server with the ones already read?

It would save you comparing. BUT, your mail client would only be able to 
talk to new servers with this new feature. It will take five years or more 
before all the servers are upgraded to allows UIDL with DELE. This is not 
an exaggeration! People just don't upgrade software that fast. In the mean 
time your client software would be sort of useless.

There's actually many things like this in Internet protocols that could be 
redone much better now with hindsight (RFC-822 address syntax for example, 
or the chattiness of SMTP), but backwards compatibility stops us from 
changing things. The deployed base is huge. In your case of POP and UIDL 
the inconvenience to programmers like you and I is relatively small. All 
you have to do is build a UIDL to message number mapping table when you 
start your POP session. In other cases the messes are much bigger. 
Basically I don't think you're going to get very far pressing this.

LL

>-Faheem.
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: 27 March 2000 09:09
>To: Faheem Ahmed Khan
>Subject: Re: A suggestion for RFC1939
>
>
>
>
> > Faheem Ahmed Khan wrote:
> > I don't understand why RFC1939 restricts to using message number with
> > the DELE command. Using the messageID (UIDL) with the DELE command
> > would be a lot more useful where the user agent can be sure of which
> > message it is deleting.
>
>I don't see how it could be more useful, since the client needs to know
>the message numbers for the other commands, such as RETR.  The UIDL to
>message number mapping never changes during a session, so I don't see
>how the client could be "more sure."
>
>At the time UIDL was created, we were trying hard to limit the number
>and scope of changes to the protocol.  The fewer changes, the fewer
>things for implementations to get wrong.

From: Faheem Ahmed  Khan <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: A suggestion for RFC1939
Date: Mon, 27 Mar 2000 21:32:21 +0530
Sender: [email-masked]

I agree that the UIDL to the message number mapping doesn't change during
one session, but it can change between consecutive sessions.

For example:
there are 100 mails in the mailbox.
I have retreived 95 and my connection to the mail server is terminated
abruptly. Though I have issued DELE after every RETR my messages still lie
in the mail box, and in my next connection to the mail server I have to
match the UIDL of the message already read by me with every message in the
mailbox before retreiving new ones. BUT, if I could use UIDL with the DELE
command I wouldn't have had bothered about that and issued a batch delete
for all the messages already retreived and still be sure that I have not
deleted an unread message. Wouldn't that save me from comparing the
MessageID of every message on the server with the ones already read?

-Faheem.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 27 March 2000 09:09
To: Faheem Ahmed Khan
Subject: Re: A suggestion for RFC1939

> Faheem Ahmed Khan wrote:
> I don't understand why RFC1939 restricts to using message number with
> the DELE command. Using the messageID (UIDL) with the DELE command
> would be a lot more useful where the user agent can be sure of which
> message it is deleting.

I don't see how it could be more useful, since the client needs to know
the message numbers for the other commands, such as RETR.  The UIDL to
message number mapping never changes during a session, so I don't see
how the client could be "more sure."

At the time UIDL was created, we were trying hard to limit the number
and scope of changes to the protocol.  The fewer changes, the fewer
things for implementations to get wrong.

From: Solar Designer <[email-masked]>
Subject: Re: A suggestion for RFC1939
To: [email-masked] (Paul Overell)
Date: Sat, 25 Mar 2000 23:16:04 +0300 (MSK)
Cc: [email-masked]
Sender: [email-masked]

> >
> >    In which case I'd rather go ahead with the following sequence.
> >    DELE 20000304062907.AAA.e0081efb
> >    DELE 20000304062908.AAA.e0081efb
> >    DELE ...........
> >    ..................
> >    QUIT
> 
> This syntax is ambiguous, UIDs can be simple numbers and so confused
> with message-numbers.

Multiple instances of the same message can also have the same UID,
so with an approach like this it would be ambiguous which instance
gets deleted.

Signed,
Solar Designer

Date: Fri, 24 Mar 2000 08:43:42 -0800
To: "Faheem" <[email-masked]>, "IETF-POP3 Ext" <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: A suggestion for RFC1939
Sender: [email-masked]

--=====================_79285824==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

I very much agree with Paul. While this is a nice idea and how I would have 
chosen to do it at the start, there's so many POP clients out there that 
now that any implementation will have to support both forever. Adding a new 
way wouldn't save any body any work. It would just add. We'd never get away 
from having to do it the old way. Also note that UIDL is optional in the 
standard.

A similar annoyance is that TOP takes an argument in lines and LIST returns 
a value in bytes.

Both of these are because UIDL and TOP were late additions to the POP 
standard I believe.

LL

At 12:37 PM 3/24/00 +0530, Faheem wrote:
>Hi All,
>
>I don't understand why RFC1939 restricts to using message number with the 
>DELE command. Using the messageID (UIDL) with the DELE command would be a 
>lot more useful where the user agent can be sure of which message it is 
>deleting.
>
>In which case I'd rather  go ahead with the following sequence.
>DELE 20000304062907.AAA.e0081efb
>DELE 20000304062908.AAA.e0081efb
>DELE ...........
>..................
>QUIT
>
>So, can we please further our discussion on this if it seems to be helpful 
>to most user agents?
>
>Regards -Faheem
>
>Day Phone: +91+80+3312966
>Night Phone: +91+80+5546449
>Email: <mailto:[email-masked]>[email-masked]
>Time Zone: GMT +05:30

--=====================_79285824==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
I very much agree with Paul. While this is a nice idea and how I would
have chosen to do it at the start, there's so many POP clients out there
that now that any implementation will have to support both forever.
Adding a new way wouldn't save any body any work. It would just add. We'd
never get away from having to do it the old way. Also note that UIDL is
optional in the standard.<br>
<br>
A similar annoyance is that TOP takes an argument in lines and LIST
returns a value in bytes.<br>
<br>
Both of these are because UIDL and TOP were late additions to the POP
standard I believe.<br>
<br>
LL<br>
<br>
At 12:37 PM 3/24/00 +0530, Faheem wrote:<br>
<blockquote type=cite cite><font face="Comic Sans MS" size=2>Hi 
All,<br>
&nbsp;<br>
I don't understand why RFC1939 restricts to using message number with the
DELE command. Using the messageID (UIDL) with the DELE command would be a
lot more useful where the user agent can be sure of which message it is
deleting. <br>
&nbsp;<br>
In which case I'd rather&nbsp; go ahead with the following 
sequence.<br>
DELE 20000304062907.AAA.e0081efb&nbsp;&nbsp; <br>
DELE 20000304062908.AAA.e0081efb&nbsp;&nbsp; <br>
DELE ...........<br>
..................<br>
QUIT<br>
&nbsp;<br>
So, can we please further our discussion on this if it seems to be
helpful to most user agents? <br>
&nbsp;<br>
Regards -Faheem<br>
&nbsp;<br>
Day Phone: +91+80+3312966<br>
Night Phone: +91+80+5546449<br>
Email: <a href="mailto:[email-masked]">[email-masked]</a> <br>
Time Zone: GMT +05:30</font></blockquote></html>

--=====================_79285824==_.ALT--

Date: Fri, 24 Mar 2000 10:19:06 +0000
To: [email-masked]
From: Paul Overell <[email-masked]>
Subject: Re: A suggestion for RFC1939
Sender: [email-masked]

In article <[email-masked]>, Faheem
<[email-masked]> writes
>    Hi All,
>    
>    I don't understand why RFC1939 restricts to using message number 
>    with the DELE command. Using the messageID (UIDL) with the DELE 
>    command would be a lot more useful where the user agent can be sure 
>    of which message it is deleting. 
>

A user agent can be absolutely sure which message gets deleted.  During
a POP3 session the mapping between message-numbers and UIDs is fixed,
there is no uncertainty.

>
>    In which case I'd rather go ahead with the following sequence.
>    DELE 20000304062907.AAA.e0081efb
>    DELE 20000304062908.AAA.e0081efb
>    DELE ...........
>    ..................
>    QUIT
>

This syntax is ambiguous, UIDs can be simple numbers and so confused
with message-numbers.

If this extension is required then a new command should be used for it.

>
>    So, can we please further our discussion on this if it seems to be 
>    helpful to most user agents? 
>

Even with this extension clients will still have to cope with un-
extended servers and continue to use DELE message-number with them.

Had this command been included in the original POP3 specification then I
would have no problem with it, but I'm afraid I can't see any point in
adding it now.

Regards

-- 
Paul Overell                                             T U R N P I K E

From: "Faheem" <[email-masked]>
To: "IETF-POP3 Ext" <[email-masked]>
Subject: A suggestion for RFC1939
Date: Fri, 24 Mar 2000 12:37:04 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01BF958D.A8FBE0F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,

I don't understand why RFC1939 restricts to using message number with =
the DELE command. Using the messageID (UIDL) with the DELE command would =
be a lot more useful where the user agent can be sure of which message =
it is deleting.=20

In which case I'd rather  go ahead with the following sequence.
DELE 20000304062907.AAA.e0081efb  =20
DELE 20000304062908.AAA.e0081efb  =20
DELE ...........
..................
QUIT

So, can we please further our discussion on this if it seems to be =
helpful to most user agents?=20

Regards -Faheem
=20
Day Phone: +91+80+3312966
Night Phone: +91+80+5546449
Email: [email-masked]=20
Time Zone: GMT +05:30

------=_NextPart_000_0022_01BF958D.A8FBE0F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Hi All,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>I don't understand why =
RFC1939 restricts=20
to using message number with the DELE command. Using the messageID =
(UIDL) with=20
the&nbsp;DELE command would be a lot more useful where the user agent =
can be=20
sure of which message it is deleting. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>In which case I'd =
rather&nbsp; go ahead=20
with the following sequence.</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>DELE=20
20000304062907.AAA.e0081efb&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>DELE=20
20000304062908.AAA.e0081efb&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>DELE ...........</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" =
size=3D2>..................</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>QUIT</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>So, can we please further our =
discussion=20
on this if it seems to be helpful to most user agents? </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Regards -</FONT><FONT=20
face=3D"Comic Sans MS" size=3D2>Faheem</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Day Phone: =
+91+80+3312966</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Night Phone: =
+91+80+5546449</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Email: </FONT><A=20
href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
<DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Time Zone: GMT=20
+05:30</FONT></DIV></DIV></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0022_01BF958D.A8FBE0F0--

Date: Tue, 14 Mar 2000 11:32:44 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Announcement of MailConnect 6
Sender: [email-masked]

Greetings again. IMC is pleased to announce our next testing event, 
MailConnect 6. The event will focus on IMAP4, POP3, and SMTP, and will be 
held May 31 and June 1 in San Jose, CA. Full details are available at 
<http://www.imc.org/imc-mailconnect/>.

The two days of MailConnect 6 will focus on IMAP4. IMAP4 is a 
well-established specification with new facilities promising substantial 
improvement for mobile and client/server mail environments. IMAP4 
implementations have fully emerged, although the large number of new of 
IMAP extensions have not been subjected to wide inter-vendor testing. 
MailConnect 6 will provide an opportunity for intense interoperability 
testing and repair of IMAP4 implementations.

During the previous MailConnect events, it has become clear that client 
developers need to pay more attention to the disconnected mode of IMAP. 
MailConnect is an excellent place for client and server vendors to test 
interoperability in this area. Further, IMAP is a dynamic protocol, and 
many valuable extensions have been proposed in the past year. Developers 
will want to meet with other developers at MailConnect to test their early 
implementations of these extensions.

Because most IMAP vendors also have POP3 and SMTP implementations, 
MailConnect 6 will be a good place to test them as well. A new round of 
extensions to POP have come out in the past year, and client vendors have 
expressed strong interest in testing these. Also in the past year, many 
extensions to SMTP have been standardized and deployed; these new features 
will be the focus of the SMTP testing at MailConnect 6. Specifically, 
message submission, SMTP over TLS, and SMTP authorization are likely 
candidates for participant testing.

--Paul Hoffman, Director
--Internet Mail Consortium