------- Blind-Carbon-Copy
To: Dave Crocker <dhc2@xxxxxxxxxxxx>
cc: Eric Brunner-Williams in Portland Maine <brunner@xxxxxxxxxxx>,
ietf-provreg@xxxxxxxx, 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@xxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3510.1034368532.1@xxxxxxxxxxx>
Date: Fri, 11 Oct 2002 16:35:32 -0400
From: Eric Brunner-Williams in Portland Maine <brunner@xxxxxxxxxxx>
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
|
