Re: [Off Topic] Need review for POP3 extension mechanism
Paul Hethmon <[email protected]>
| Newsgroups | gmane.ietf.pop3ext |
|---|---|
| Message-ID | <[email protected]> |
** Reply to note from Keith Moore <[email protected]> Wed, 08 Jul 1998 21:30:01 -0400 Here are my thoughts: > On May 18, a Last Call was issued on for document draft-gellens-pop3ext-05.txt , > for Proposed Standard status. Nobody has commented on the document. I am > reluctant to recommend that IESG approve this document without more evidence > of support. > > So I'm asking for more review... > > Should the document be adopted as is? Does it need more wordsmithing? A quick reading didn't leave me any questions about it. It seemed to be easily comprehended. > Are all of these capabilities needed? I can see use for it to a certain extent. I haven't had many requests from my customers for extensions and/or capabilities of this nature though I already support all of the 1939 optional commands. > Are all of the capabilities defined with sufficient precision? Yes. > Should the document be standards track or should it be Informational or > Experimental? If it's going to be anything, it should be standards track. With standard status, it's dead at the starting gate. I would likely implement it if it went Informational, not likely if Experimental. > Should the extension mechanism be separated from (and perhaps a different > status from) the extensions themselves? No. I'd leave them in. I see the extensions as not quite extensions to the protocol but more refinements. As the document said, it's not the intent to turn POP3 into IMAP. In this light, it would be better for implementors to have the gathered into one spot. TOP, USER, and UIDL are already in 1939, so no need to separate them out. SASL is in 2222 so it's documented. The other commands are more of an informational nature than operational. Defining them here seems a good thing in that we shouldn't expect many if any further extensions to POP3. > If the document is approved for Proposed, should all of the proposed extensions > be included? Or should some of the extensions be moved to a separate > Informational or Experimental? Which ones? I would keep them together and in the standards track. > In the absence of more community input, my recommendation would be to direct > the authors to remove all of the capabilities from this document, except those > which are already defined in standards-track documents. Additional capabilities > could be defined in a separate experimental or informational RFC. Paul ------------------------------------------------------------------------- Paul Hethmon [email protected] Inet.Mail Internet Mail Server http://www.hethmon.com ------------------------------------------------------------------------- Author "Illustrated Guide to HTTP" http://www.manning.com/Hethmon?882 ------------------------------------------------------------------------- Warpstock -- Tune In! & Warp Out! -- http://www.warpstock.org cc: Keith Moore <[email protected]>