Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11141 for ietf-pop3ext-bks; Mon, 27 Mar 2000 09:09:23 -0800 (PST) Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11136 for ; Mon, 27 Mar 2000 09:09:22 -0800 (PST) Received: from llundblade-laptop.qualcomm.com (llundblade-laptop.qualcomm.com [129.46.242.17]) by jittlov.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id JAA08762; Mon, 27 Mar 2000 09:11:30 -0800 (PST) Message-Id: <4.3.1.2.20000327090349.00afadb0@hotsun.qualcomm.com> X-Sender: lgl@hotsun.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 27 Mar 2000 09:11:15 -0800 To: Faheem Ahmed Khan , jgmyers@netscape.com From: Laurence Lundblade Subject: RE: A suggestion for RFC1939 Cc: ietf-pop3ext@imc.org In-Reply-To: <608E92548499D311A894000629383804F68515@TOMCAT> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: jgmyers@netscape.com [mailto:jgmyers@netscape.com] >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. Received: by ns.secondary.com (8.9.3/8.9.3) id HAA08866 for ietf-pop3ext-bks; Mon, 27 Mar 2000 07:55:18 -0800 (PST) Received: from tomcat.aditi.soft.net ([164.164.12.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08860 for ; Mon, 27 Mar 2000 07:55:15 -0800 (PST) Received: by TOMCAT with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 21:32:22 +0530 Message-ID: <608E92548499D311A894000629383804F68515@TOMCAT> From: Faheem Ahmed Khan To: jgmyers@netscape.com Cc: ietf-pop3ext@imc.org Subject: RE: A suggestion for RFC1939 Date: Mon, 27 Mar 2000 21:32:21 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: jgmyers@netscape.com [mailto:jgmyers@netscape.com] 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. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA23480 for ietf-pop3ext-bks; Sat, 25 Mar 2000 12:55:53 -0800 (PST) Received: from mystic.false.com (root@false.com [198.65.171.171]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23476 for ; Sat, 25 Mar 2000 12:55:52 -0800 (PST) Received: from false.com (root@false.com [198.65.171.171]) by mystic.false.com (8.9.3/8.9.3) with ESMTP id OAA31805; Sat, 25 Mar 2000 14:57:36 -0600 Received: (from solar@localhost) by false.com (8.8.5/8.8.5) id XAA15545; Sat, 25 Mar 2000 23:16:04 +0300 From: Solar Designer Message-Id: <200003252016.XAA15545@false.com> Subject: Re: A suggestion for RFC1939 In-Reply-To: from Paul Overell at "Mar 24, 0 10:19:06 am" To: paulo@turnpike.com (Paul Overell) Date: Sat, 25 Mar 2000 23:16:04 +0300 (MSK) Cc: ietf-pop3ext@imc.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > > 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA07102 for ietf-pop3ext-bks; Fri, 24 Mar 2000 08:42:47 -0800 (PST) Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07098 for ; Fri, 24 Mar 2000 08:42:46 -0800 (PST) Received: from llundblade-laptop.qualcomm.com (llundblade-laptop.qualcomm.com [129.46.242.17]) by jittlov.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id IAA14305; Fri, 24 Mar 2000 08:44:42 -0800 (PST) Message-Id: <4.3.1.2.20000324084045.00e46cc0@hotsun.qualcomm.com> X-Sender: lgl@hotsun.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 24 Mar 2000 08:43:42 -0800 To: "Faheem" , "IETF-POP3 Ext" From: Laurence Lundblade Subject: Re: A suggestion for RFC1939 In-Reply-To: <20000324070603.14467.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_79285824==_.ALT" Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_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: faheem@mail.com >Time Zone: GMT +05:30 --=====================_79285824==_.ALT Content-Type: text/html; charset="us-ascii" 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: faheem@mail.com
Time Zone: GMT +05:30
--=====================_79285824==_.ALT-- Received: by ns.secondary.com (8.9.3/8.9.3) id CAA24217 for ietf-pop3ext-bks; Fri, 24 Mar 2000 02:19:51 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA24213 for ; Fri, 24 Mar 2000 02:19:49 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id KAA10349; Fri, 24 Mar 2000 10:21:46 GMT Message-ID: Date: Fri, 24 Mar 2000 10:19:06 +0000 To: ietf-pop3ext@imc.org From: Paul Overell Subject: Re: A suggestion for RFC1939 References: <20000324070603.14467.qmail@hotmail.com> In-Reply-To: <20000324070603.14467.qmail@hotmail.com> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.00 beta 4 M Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In article <20000324070603.14467.qmail@hotmail.com>, Faheem 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA12956 for ietf-pop3ext-bks; Thu, 23 Mar 2000 23:04:33 -0800 (PST) Received: from hotmail.com (oe18.law4.hotmail.com [216.33.148.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA12949 for ; Thu, 23 Mar 2000 23:04:32 -0800 (PST) Received: (qmail 14468 invoked by uid 65534); 24 Mar 2000 07:06:03 -0000 Message-ID: <20000324070603.14467.qmail@hotmail.com> X-Originating-IP: [164.164.12.10] From: "Faheem" To: "IETF-POP3 Ext" Subject: A suggestion for RFC1939 Date: Fri, 24 Mar 2000 12:37:04 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01BF958D.A8FBE0F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: faheem@mail.com=20 Time Zone: GMT +05:30 ------=_NextPart_000_0022_01BF958D.A8FBE0F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
I don't understand why = RFC1939 restricts=20 to using message number with the DELE command. Using the messageID = (UIDL) with=20 the DELE command would be a lot more useful where the user agent = can be=20 sure of which message it is deleting.
 
In which case I'd = rather  go ahead=20 with the following sequence.
DELE=20 20000304062907.AAA.e0081efb  
DELE=20 20000304062908.AAA.e0081efb  
DELE ...........
..................
QUIT
 
So, can we please further our = discussion=20 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: faheem@mail.com
Time Zone: GMT=20 +05:30
------=_NextPart_000_0022_01BF958D.A8FBE0F0-- Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15391 for ietf-pop3ext-bks; Tue, 14 Mar 2000 11:35:52 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15382 for ; Tue, 14 Mar 2000 11:35:50 -0800 (PST) Message-Id: <4.3.2.20000314113237.00aa9d50@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 14 Mar 2000 11:32:44 -0800 To: ietf-pop3ext@imc.org From: Paul Hoffman / IMC Subject: Announcement of MailConnect 6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 . 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