From owner-ietf-ediint@mail.imc.org Fri Oct 11 13:41: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 NAA29963 for ; Fri, 11 Oct 2002 13:41:17 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9BHCwD11026 for ietf-ediint-bks; Fri, 11 Oct 2002 10:12:58 -0700 (PDT) Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9BHCuv11019; Fri, 11 Oct 2002 10:12:56 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g9BHDlpt002645; Fri, 11 Oct 2002 13:13:47 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200210111713.g9BHDlpt002645@nic-naa.net> To: ietf-provreg@cafax.se, ietf-822@imc.org, ietf-ediint@imc.org cc: brunner@nic-naa.net Subject: how to exchange EPP content using SMTP transport MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2643.1034356427.1@nic-naa.net> Date: Fri, 11 Oct 2002 13:13:47 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Appologies for the cross-posting. As Jon Crowcroft wrote to the ed2end list Monday, this is somewhat 1/2 baked, but comments are welcome. Available via ftp from [216.220.241.233] user=anonymous pswd=guest (or whatever) file=pub/draft-brunner-epp-smtp-00.txt,html Comments to me please, I like writing acknowledgements. Eric From owner-ietf-ediint@mail.imc.org Fri Oct 11 15:30:51 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 PAA03245 for ; Fri, 11 Oct 2002 15:30:51 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9BJEvk17042 for ietf-ediint-bks; Fri, 11 Oct 2002 12:14:57 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9BJEuv17038; Fri, 11 Oct 2002 12:14:56 -0700 (PDT) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA10150; Fri, 11 Oct 2002 12:14:58 -0700 Date: Fri, 11 Oct 2002 12:14:48 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.61) UNREG / CD5BF9353B3B7091 Reply-To: Dave Crocker Organization: TribalWise X-Priority: 3 (Normal) Message-ID: <1991796746.20021011121448@dcrocker.net> To: owner-ietf-ediint@mail.imc.org, Eric Brunner-Williams in Portland Maine CC: ietf-provreg@cafax.se Subject: Re: how to exchange EPP content using SMTP transport In-Reply-To: <200210111713.g9BHDlpt002645@nic-naa.net> References: <200210111713.g9BHDlpt002645@nic-naa.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Eric, (ediint and 822 bcc'd to target discussion on the host list, provreg.) MANY thanks for doing this. Comments inline. Friday, October 11, 2002, 10:13:47 AM, you wrote: EBWiPM> This memo defines mechanisms to secure (sign or encrypt or sign and EBWiPM> encrypt) one or more EPP messages in any SMTP message. This memo EBWiPM> does not define mechanism to secure (sign or encrypt or sign and EBWiPM> encrypt) individual XML elements within an EPP message. Are there any requirements for epp/smtp security that are distinctive? My guess is that the requirements for epp/smtp are the same as for any MIME object needing the same security services. That is, if we say that these objects may need privacy, authentication and signed receipt, then it should the security-related work of this specification should be done... as long as we can cite an external reference that defines the common way(s) to achieve those services. From work in IMPP I've come to believe that we need a MIMEsec specification that is common to all MIME objects, for these common services. (Well, ok, signed receipt is not yet common.) Such a document should, essentially, take existing text from various special efforts, like ediint and impp, as you have noted. Would this be reasonable? If yes, then the current specification should be able to cite a MIMEsec document, for security basic security issues. Given that it is a transaction service, perhaps it needs to mention something about man-in-the-middle and DOS attacks? Otherwise, the normative (specification) portion could then focus on definition of the MIME type and, perhaps, profile the bulk carriage details. Having all those examples is really excellent. EBWiPM> 2. Background Summary EBWiPM> EBWiPM> Some language about these three registry protocols, and the EBWiPM> applicability of SMTP as a transport protocol. TBD. EBWiPM> EBWiPM> This table compares the salient characteristics of EPP, RRP and SRS. The table is interesting, but I am not clear what purpose it servces in the current specification. Please clarify. EBWiPM> EBWiPM> 13. Receiver Message Structures EBWiPM> EBWiPM> This section is intentionally blank, pending implementation. what does "receiver message structures" mean? are these the replies? EBWiPM> [3] Crocker, D., "Simple Mail Transfer Protocol", RFC 822, STD 11, EBWiPM> August 1982. "Standard for the Format of ARPA Internet Text Messages" probably should also cite rfc2822, resnick, "Internet Message Format" and rfc2821, klensin, "Simple Mail Transfer Protocol". d/ From owner-ietf-ediint@mail.imc.org Fri Oct 11 16:51: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 QAA04927 for ; Fri, 11 Oct 2002 16:51:47 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9BKbdN19959 for ietf-ediint-bks; Fri, 11 Oct 2002 13:37:39 -0700 (PDT) Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9BKYfv19907; Fri, 11 Oct 2002 13:34:41 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g9BKZWpw003512; Fri, 11 Oct 2002 16:35:33 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200210112035.g9BKZWpw003512@nic-naa.net> Date: Fri, 11 Oct 2002 16:35:32 -0400 From: Eric Brunner-Williams in Portland Maine Subject: Re: how to exchange EPP content using SMTP transport Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------- Blind-Carbon-Copy To: Dave Crocker cc: Eric Brunner-Williams in Portland Maine , ietf-provreg@cafax.se, brunner Subject: Re: how to exchange EPP content using SMTP transport In-Reply-To: Your message of "Fri, 11 Oct 2002 12:14:48 PDT." <1991796746.20021011121448@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3510.1034368532.1@nic-naa.net> Date: Fri, 11 Oct 2002 16:35:32 -0400 From: Eric Brunner-Williams in Portland Maine Dave, (ediint and 822 bcc'd to target discussion on the host list, provreg.) This started as "Applicability Statement for EPP over Transport other than TCP", with the comment: The original motivation for this memo is a casual figure contained in a presentation made by James Seng to the PROVREG WG face-to-face meeting at IETF-51. This figure purported to show a loop-free store- and-forward transport topology, which unfortunately contained loops. I then slogged grimly through the rainy grey ruins of connection and HOL blocking, session semantics, authentication mechanism scaling, state, and the semantics of EPP session/read/write commands and responses to find no real case for transport-over-TCP, no there there, at least outside of the ICANN sandbox, and even there, the real use case seems to be minimum-delay exact match write races -- a QoS guarantee not actually specified in the TCP mapping. I next gamboled blithly over the sunny meadows of {SMTP,NEWS}/{TCP,UUCP}, and HTTP/TCP and concluded that: > ... the requirements for epp/smtp are the same as for any MIME > object needing the same security services. Once I caught MIME, everything looked like a frenchman wearing thick makeup. I decided that it was more useful to write a Foo-over-OneTP memo than a MetaFoo-over-ManyTP memo. > Having all those examples is really excellent. Thanks. Laborious. Error-certain. > The table is interesting, but I am not clear what purpose it servces in the > current specification. Please clarify. Personel taste. A weakness for taxonomy. > what does "receiver message structures" mean? are these the replies? Yup. > "Standard for the Format of ARPA Internet Text Messages" > > probably should also cite rfc2822, resnick, "Internet Message Format" and > rfc2821, klensin, "Simple Mail Transfer Protocol". Thank. I like the oldies. I've a nit with the moderns I haven't got my head around. Eric ------- End of Blind-Carbon-Copy