RE: [Off Topic] Need review for POP3 extension mechanism
"Mike Gahrns (Exchange)" <mikega@exchange.microsoft.com> Wed, 22 July 1998 04:32 UTC
Delivery-Date: Wed, 22 Jul 1998 00:32:02 -0400
Return-Path: owner-ietf-smtp@imc.org
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA12424 for <ietf-archive@ietf.org>; Wed, 22 Jul 1998 00:32:01 -0400 (EDT)
Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA03231; Wed, 22 Jul 1998 00:31:53 -0400 (EDT)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA11183 for ietf-smtp-bks; Tue, 21 Jul 1998 21:17:59 -0700 (PDT)
Received: from yuri.exchange.microsoft.com (yuri.exchange.microsoft.com [131.107.88.54]) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA11171; Tue, 21 Jul 1998 21:17:49 -0700 (PDT)
Received: by yuri.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <PMFFLV67>; Tue, 21 Jul 1998 21:18:24 -0700
Message-ID: <2FBF98FC7852CF11912A0000000000010B37E591@DINO>
From: "Mike Gahrns (Exchange)" <mikega@exchange.microsoft.com>
To: "'ietf-pop3ext@imc.org'" <ietf-pop3ext@imc.org>, drums@cs.utk.edu, ietf-smtp@imc.org
Subject: RE: [Off Topic] Need review for POP3 extension mechanism
Date: Tue, 21 Jul 1998 21:18:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDB527.C46A0970"
Sender: owner-ietf-smtp@imc.org
Precedence: bulk
I apologize for such a late response, but i have been out of the office for the last few weeks. I agree with the others who view this as being a useful draft, and second the motion that it should go as proposed instead of informational or experimental. Although the list has not had a lot of dicussion on it, I know Randy has been discussing this with various people at venues like the ietf, so it has been getting review. My biggest concern was the former LMOS setting allowed for expiration settings to be based on the command used to acccess the msg, which Randy has addressed with the new EXPIRE setting. I do have one minor concern regarding the current wording of the EXPIRE setting. The draft states: "If the expiration policy might differ per user (that is, the EXPIRE argument might change after authentication), the server MUST announce in the AUTHENTICATION state the smallest value which might be used. The server should announce the more accurate value in the TRANSACTION state. It is unclear to me whether the intent of this is to force the server to keep track of the smallest setting a user currently has set, or if it is for the server to annouce the smallest value that an administrator could conceivably set for a particular user. If the intent is the former, than this will be problematic for servers that are not tightly coupled with their directory, as it effectively forces the server to scan a list of all user settings at each log on time. I'll talk to Randy to get clarification, and perhaps come up with some clarification wording in regards to this. Another minor nit is the wording: "If the authentication step negotiates an integrity protection layer, the client SHOULD reissue the CAPA command after authenticating to check for active down-negotiation attacks." I'd like to see the wording changed to something like: "The client SHOULD reissue the CAPA command after authenticating to check for active down-negotiation attacks and to get any per user capability settings." -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Wednesday, July 08, 1998 6:30 PM To: drums@cs.utk.edu; ietf-smtp@imc.org Cc: moore@cs.utk.edu; ietf-pop3ext@imc.org Subject: [Off Topic] Need review for POP3 extension mechanism I apologize for an off-topic posting. Please send replies to ietf-pop3ext@imc.org, not to the drums or ietf-smtp lists. 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? Are all of these capabilities needed? Are all of the capabilities defined with sufficient precision? Should the document be standards track or should it be Informational or Experimental? Should the extension mechanism be separated from (and perhaps a different status from) the extensions themselves? 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? 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. thanks! Keith Moore APPS co-AD
- RE: [Off Topic] Need review for POP3 extension me… Mike Gahrns (Exchange)
- RE: [Off Topic] Need review for POP3 extension me… Randall Gellens
- Re: [Off Topic] Need review for POP3 extension me… Mike Gahrns