ietf-822
[Top] [All Lists]

Re: how to exchange EPP content using SMTP transport

2002-10-11 13:34:42

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

To: Dave Crocker <dhc2(_at_)dcrocker(_dot_)net>
cc: Eric Brunner-Williams in Portland Maine <brunner(_at_)nic-naa(_dot_)net>,
    ietf-provreg(_at_)cafax(_dot_)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(_dot_)20021011121448(_at_)dcrocker(_dot_)net> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3510(_dot_)1034368532(_dot_)1(_at_)nic-naa(_dot_)net>
Date: Fri, 11 Oct 2002 16:35:32 -0400
From: Eric Brunner-Williams in Portland Maine <brunner(_at_)nic-naa(_dot_)net>

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

<Prev in Thread] Current Thread [Next in Thread>