Re: how to exchange EPP content using SMTP transport

------- Blind-Carbon-Copy

To: Dave Crocker <[email protected]>
cc: Eric Brunner-Williams in Portland Maine <[email protected]>,
    [email protected], 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."
             <[email protected]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email protected]>
Date: Fri, 11 Oct 2002 16:35:32 -0400
From: Eric Brunner-Williams in Portland Maine <[email protected]>

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