To:
Dave Crocker <dhc2@dcrocker.net>
cc:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, ietf-provreg@cafax.se, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Fri, 11 Oct 2002 16:35:32 -0400
Content-ID:
<3510.1034368532.1@nic-naa.net>
In-Reply-To:
Your message of "Fri, 11 Oct 2002 12:14:48 PDT." <1991796746.20021011121448@dcrocker.net>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: how to exchange EPP content using SMTP transport
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