From owner-ietf-msgtrk@mail.imc.org Wed Aug 21 05:31:48 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04888 for ; Wed, 21 Aug 2002 05:31:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7L9T5T26186 for ietf-msgtrk-bks; Wed, 21 Aug 2002 02:29:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7L9T4226182 for ; Wed, 21 Aug 2002 02:29:04 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KLJAKSTD4W0001B1@mauve.mrochek.com> for ietf-msgtrk@imc.org; Wed, 21 Aug 2002 02:29:03 -0700 (PDT) Date: Wed, 21 Aug 2002 02:07:52 -0700 (PDT) From: ned.freed@mrochek.com Subject: AD review of msgtrk documents To: ietf-msgtrk@imc.org, tony@att.com, eric@sendmail.com Cc: ned.freed@mrochek.com, paf@cisco.com Message-id: <01KLJKQFSLGK0001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Overall these look good. Almost all of the changes are purely editorial in nature. smtpext-03: This document doesn't have the required RFC 2026 copyright boilerplate. Section 3, item (3) talks about parameters and then switches to options. I suggest changing this to read "Future documents may extend this specification by specifying parameters to this keyword value." Section 3, item (4). I'm a bit concerned that this calls for piecemeal support of the DSN extension. I guess the intent here is not to require support for the notification aspescts of DSN. However, I think it needs to be clearly stated that all of the semantics associated with ENVID and ORCPT given in 1891 have to be supported as part of this extension. Section 4.3, second paragraph. Probably should note that the MTRK= parameter is modified to the extent that the timeout is decremented. Section 5 title. Stupid as it sounds, this section needs to be called "Security Considerations". I know we'll get pushback if it isn't. This document needs an IANA considerations section. All it needs to say is that IANA is to register the SMTP extension defined in section 3. The RFC editor now has a policy that references need to be separated into normative and informative groups. This document needs to follow that convention. trkstat-03 This document doesn't have the required RFC 2026 copyright boilerplate. The title of this document seems off. "The Message/Tracking-Status MIME Extension" implies that this document extends MIME. In fact it does nothing of the sort; this document defines a format for a specific sort of message using MIME constructs. Since it closely resembles RFC 1894, how about "An Extensible Message Format for Message Tracking Responses"? Section 4 title. Same stupid thing; needs to be called "Security considerations". There needs to be an IANA considerations section that says the message/tracking-status media type defined in section 3.1 is to be registered. References need to be split into normative and informative. mqtp-08 The copyright date is 1999. This seems wrong... Section 2.4. Should say something about client timeouts and how long it is appropriate to wait for a server. Section 4. It seems appropriate to have two qualified error responses to TRACK: (1) An indication that TLS must be negotiated before this message can be tracked and (2) An indication that the search succeeded but found no result. The URL registration in section 9 doesn't seem to meet the requirements set forth in RFC 2717. In particular, the URL registration template needs to be included. Section 10. The IANA considerations should mention that this document registers the MQTP URL scheme. References need to be split into normative and informative. model-06 Another 1999 copyright. Document needs a security considerations section. It should summarize the security considerations raised in the protocol documents. That's it! Ned From owner-ietf-msgtrk@mail.imc.org Wed Aug 21 16:42:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25094 for ; Wed, 21 Aug 2002 16:42:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7LKdXu08642 for ietf-msgtrk-bks; Wed, 21 Aug 2002 13:39:33 -0700 (PDT) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7LKdU208638 for ; Wed, 21 Aug 2002 13:39:31 -0700 (PDT) Received: from maillennium.att.com ([135.25.114.99]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g7LKdOSX002924 for ; Wed, 21 Aug 2002 16:39:24 -0400 (EDT) Received: from att.com (tony-ob.mt.att.com[135.91.110.94]) by maillennium.att.com (mailgw1) with SMTP id <20020821203923gw100fmdspe> (Authid: tony); Wed, 21 Aug 2002 20:39:23 +0000 Message-ID: <3D63F935.6050206@att.com> Date: Wed, 21 Aug 2002 16:33:57 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-msgtrk@imc.org Subject: Re: AD review of msgtrk documents References: <01KLJKQFSLGK0001B1@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thank you Ned. I have a few comments below, plus some questions for the group. Tony ned.freed@mrochek.com wrote: > Overall these look good. Almost all of the changes are purely editorial in > nature. > ... > > mqtp-08 > > The copyright date is 1999. This seems wrong... Obviously the documents have been in the hopper for too long. :-) > Section 2.4. Should say something about client timeouts and how > long it is appropriate to wait for a server. I'd like to propose the following additions: * In section 2.5 "Firewall Considerations", where it talks about the server doing chaining operations, add the following: If a server chooses to perform a chaining operation itself, it MUST provide a response within 2 minutes, and SHOULD return a "no further information is available" response if it cannot provide an answer at the end of that time limit. * In section 2.4 Optional Timers, add: An MTQP client MAY have an inactivity autologout timer while waiting for a response from the server. Since an MTQP server may be a firewall, and may be chaining information from other servers, such a timer MUST be at least 2 minutes in duration. * I arbitrarily chose 2 minutes. If there's a better time limit, feel free to suggest one. * I also plan on swapping sections 2.4 and 2.5, since Optional Timers now refers to firewall support. > Section 4. It seems appropriate to have two qualified error > responses to TRACK: (1) An indication that TLS must be > negotiated before this message can be tracked and (2) An indication > that the search succeeded but found no result. I'd like to propose the following additions to section 4: A negative response to the TRACK command may include these reason codes: "/" "tls-required" "/" "admin" "/" "unavailable" The reason code "/tls-required" SHOULD be used when the server has decided to require TLS. The reason code "/admin" SHOULD be used when the server has become unavailable, due to administrative reasons, since the connection was initialized. The reason code "/unavailable" SHOULD be used when the server has become unavailable, for other reasons, since the connection was initialized. > The URL registration in section 9 doesn't seem to meet the > requirements set forth in RFC 2717. In particular, the > URL registration template needs to be included. I'll review this. > Section 10. The IANA considerations should mention that this > document registers the MQTP URL scheme. yup > References need to be split into normative and informative. I moved these to informative and left the rest in normative: [RFC-SHA1] RFC 3184, "US Secure Hash Standard 1 (SHA1)" [RFC-KEYWORDS] RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels" [RFC-SMTP-TLS] RFC2487, "SMTP Service Extension for Secure SMTP over TLS" > model-06 > > Another 1999 copyright. oops > Document needs a security considerations section. It should > summarize the security considerations raised in the protocol > documents. will do. > That's it! Excellent! From owner-ietf-msgtrk@mail.imc.org Wed Aug 21 16:51:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25478 for ; Wed, 21 Aug 2002 16:51:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7LKooa09007 for ietf-msgtrk-bks; Wed, 21 Aug 2002 13:50:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7LKom209003 for ; Wed, 21 Aug 2002 13:50:48 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KLK7K1RTWW0001B1@mauve.mrochek.com> for ietf-msgtrk@imc.org; Wed, 21 Aug 2002 13:50:50 -0700 (PDT) Date: Wed, 21 Aug 2002 13:47:56 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: AD review of msgtrk documents In-reply-to: "Your message dated Wed, 21 Aug 2002 16:33:57 -0400" <3D63F935.6050206@att.com> To: Tony Hansen Cc: ietf-msgtrk@imc.org Message-id: <01KLK8JQPYQ00001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <01KLJKQFSLGK0001B1@mauve.mrochek.com> <3D63F935.6050206@att.com> Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Thank you Ned. I have a few comments below, plus some questions for the > group. > Tony > ned.freed@mrochek.com wrote: > > Overall these look good. Almost all of the changes are purely editorial in > > nature. > > ... > > > > mqtp-08 > > > > The copyright date is 1999. This seems wrong... > Obviously the documents have been in the hopper for too long. :-) > > Section 2.4. Should say something about client timeouts and how > > long it is appropriate to wait for a server. > I'd like to propose the following additions: > * In section 2.5 "Firewall Considerations", where it talks about the > server doing chaining operations, add the following: > If a server chooses to perform a chaining operation itself, it MUST > provide a response within 2 minutes, and SHOULD return a "no further > information is available" response if it cannot provide an answer at the > end of that time limit. That may be tough to guarantee, but I'm willing to give it a try. > * In section 2.4 Optional Timers, add: > An MTQP client MAY have an inactivity autologout timer while waiting for > a response from the server. Since an MTQP server may be a firewall, and > may be chaining information from other servers, such a timer MUST be at > least 2 minutes in duration. > * I arbitrarily chose 2 minutes. If there's a better time limit, feel > free to suggest one. > * I also plan on swapping sections 2.4 and 2.5, since Optional Timers > now refers to firewall support. Sounds fine. > > Section 4. It seems appropriate to have two qualified error > > responses to TRACK: (1) An indication that TLS must be > > negotiated before this message can be tracked and (2) An indication > > that the search succeeded but found no result. > I'd like to propose the following additions to section 4: > A negative response to the TRACK command may include these reason codes: > "/" "tls-required" > "/" "admin" > "/" "unavailable" > The reason code "/tls-required" SHOULD be used when the server has > decided to require TLS. The reason code "/admin" SHOULD be used when the > server has become unavailable, due to administrative reasons, since the > connection was initialized. The reason code "/unavailable" SHOULD be > used when the server has become unavailable, for other reasons, since > the connection was initialized. OK as far as it goes, but what happens when no information about the message is found? Does this come back as an empty reponse or does it get a negative response? > > The URL registration in section 9 doesn't seem to meet the > > requirements set forth in RFC 2717. In particular, the > > URL registration template needs to be included. > I'll review this. > > Section 10. The IANA considerations should mention that this > > document registers the MQTP URL scheme. > yup > > References need to be split into normative and informative. > I moved these to informative and left the rest in normative: > [RFC-SHA1] RFC 3184, "US Secure Hash Standard 1 (SHA1)" > [RFC-KEYWORDS] RFC 2119, "Key words for use in RFCs to Indicate > Requirement Levels" > [RFC-SMTP-TLS] RFC2487, "SMTP Service Extension for Secure SMTP over TLS" Sounds right to me. > > model-06 > > > > Another 1999 copyright. > oops > > Document needs a security considerations section. It should > > summarize the security considerations raised in the protocol > > documents. > will do. > > That's it! > Excellent! From owner-ietf-msgtrk@mail.imc.org Tue Aug 27 20:00:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17762 for ; Tue, 27 Aug 2002 20:00:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7RNvAd06531 for ietf-msgtrk-bks; Tue, 27 Aug 2002 16:57:10 -0700 (PDT) Received: from [165.227.249.18] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RNcH205470; Tue, 27 Aug 2002 16:38:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 27 Aug 2002 16:38:17 -0700 To: (many IETF mailing lists) From: Paul Hoffman / IMC Subject: Nomcom call for volunteers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Forwarded for Phil Roberts : The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. From subs-reminder@imc.org Sat Aug 31 18:10:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13968 for ; Sat, 31 Aug 2002 18:10:18 -0400 (EDT) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g7VMBkj20549; Sat, 31 Aug 2002 15:11:46 -0700 (PDT) Date: Sat, 31 Aug 2002 15:11:46 -0700 (PDT) Message-Id: <200208312211.g7VMBkj20549@above.proper.com> To: msgtrk-archive@ietf.org Subject: [[321237592]] Subscription to ietf-msgtrk for msgtrk-archive@lists.ietf.org Greetings. This message is a periodic reminder that msgtrk-archive@lists.ietf.org is subscribed to the ietf-msgtrk mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-msgtrk mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-msgtrk-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "msgtrk-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator