Subject: how to exchange EPP content using SMTP transport

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 11 Oct 2002 13:13:47 -0400

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: Dave Crocker <[email-masked]>
Date: Fri, 11 Oct 2002 12:14:48 -0700

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: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 11 Oct 2002 16:35:32 -0400

Dave,

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

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.

> current specification.  Please clarify.

Personel taste. A weakness for taxonomy.

> what does "receiver message structures" mean?  are these the replies?

Yup.

> 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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Oct 2002 14:04:19 -0700

>Once I caught MIME, everything looked like a frenchman wearing thick makeup.

never seen one.  don't know what they look like.

>MetaFoo-over-ManyTP memo.

well, my primary point is that for most of the material, this is not "over 
SMTP".  Rather, it is "over MIME".  MIME is the bottom layer to worry about.

That said, there really ARE some SMTP issues that at least need to be 
cited, now that I think of it.

Addressing and reliability (as in, actual transmissions issues) come to 
mind.  Given that SMTP is not reliable on an end-to-end basis, what do we 
want to do if/when a message gets dropped?

>Personel taste. A weakness for taxonomy.

But I still don't know what purpose it serves for this document.  The other 
two protocols are not under consideration and are not mentioned elsewhere 
in the doc, are they?

>Thank. I like the oldies. I've a nit with the moderns I haven't got my head

pro forma requirement.  part of helping the adoption curve.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850