Subject: epp via smtp

From: Edward Lewis <[email-masked]>
Date: Tue, 3 Sep 2002 17:45:38 -0400

While I'm at it...

We are behind on the current milestone:
JUL 02       First draft of EPP over SMTP

There have been some rumors of interest and even a volunteer for this 
document, but we've seen nothing.  Unless someone takes an active 
step towards producing this document in the next week or two, Jaap 
and I will ask our AD to let us drop the milestone from the 
charter...(right, Jaap? ;) )

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 03 Sep 2002 21:07:40 -0400

...
> document ...

Remind me. Who volunteered?

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Sep 2002 21:09:41 -0700

>Remind me. Who volunteered?

'twas me.  unfortunately the task keeps getting crammed farther down the 
stack by other priorities.

d/

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 4 Sep 2002 08:29:41 -0400

Jordyn... http://www.cafax.se/ietf-provreg/maillist/2002-05/msg00011.html

---

From: Edward Lewis <[email-masked]>
Date: Wed, 4 Sep 2002 08:33:36 -0400

Perhaps we have multiple volunteers...;)

At 9:09 PM -0700 9/3/02, Dave Crocker wrote:
>'twas me.  unfortunately the task keeps getting crammed farther down 
>the stack by other priorities.
>
>d/
>
>
>----------

---

From: "Edmon Chung" <[email-masked]>
Date: Fri, 6 Sep 2002 12:44:17 -0400

So is anyone actually working on the document?
If not, I could take a crack at it since we are developing the functionality
anyway.
Edmon

----- Original Message -----
From: "Edward Lewis" <[email-masked]>
To: "Dave Crocker" <[email-masked]>; "Eric Brunner-Williams in Portland
Maine" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, September 04, 2002 8:33 AM
Subject: Re: epp via smtp

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 06 Sep 2002 17:28:29 -0400

Howdy Edmon,

A few questions about your development work ...

Is a single EPP message is contained within a single SMTP message?

Does a single SMTP message contain only one EPP message?

What are the defined values for the Content-Type header field?

What are the defined values for the Content-Transfer-Encoding header field?

What are the defined values for the Mime-Version header field?

Is the mechanism defined in ESMTP used and if so, what are the one
(or more) extensions to the SMTP service?

Is SMTP over TLS defined?

Are other mechanism(s) defined for adding authentication and privacy to
messages?

Are the Message-ID and In-Reply-To headers used?

How are the "From:", "To:", "Cc:", etc headers used? 

Are you 2821-strict or 821-tolerant w.r.t. these?

Is any of the cannonical boiler-plate disturbed? IANA? Security? I18N?

London was fun.

Eric

---

From: "Edmon Chung" <[email-masked]>
Date: Fri, 6 Sep 2002 18:18:54 -0400

It is honestly, fairly simple.  Reason being ease of implementation for the
registry as well as the registrar.  Your questions indicate that a more
comprehensive approach, or perhaps I should say a more "customized" approach
designed for EPP.  We could start with a very simple definition and add to
it.  In terms of practicality, we must ask what makes the most sense to a
registry and a registrar.  In terms of an elegant solution, we could utilize
the headers and MIME much better, or even specify a new ESMTP extension to
be used.

What are the thoughts from the group in general?

Anyway, in terms of our very simple implementation, it is really just using
the SMTP as a transport mechanism and then parse out the body portion and
dump it back into the regular EPP gateway.  ie.  the XML messages are
encoded "as is" in the body of the email.  Therefore, to answer your
questions:

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
> Does a single SMTP message contain only one EPP message?

One SMTP message may contain multiple EPP messages.  Transaction IDs are
used.

> What are the defined values for the Content-Type header field?

The headers are not used as identifiers within the EPP context except that
the subject identifies that it is an EPP message.

> What are the defined values for the Content-Transfer-Encoding header
field?

8bit

> What are the defined values for the Mime-Version header field?

None

> (or more) extensions to the SMTP service?

No.

> Are other mechanism(s) defined for adding authentication and privacy to

Only PGP is used.

> How are the "From:", "To:", "Cc:", etc headers used?

All headers are used as Email message headers are today.

> Is any of the cannonical boiler-plate disturbed? IANA? Security? I18N?

When i18n is introduced, the EPP messages will contain 8bit data and use
UTF8 as the encoding.

Again, I must stress that our approach had simplicity in mind.

Edmon

> London was fun.

Europe is generally more fun than the US ;-)

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 06 Sep 2002 21:11:52 -0400

> registry as well as the registrar. ...

Good.

> ... SMTP as a transport mechanism and then parse out the body portion and
> dump it back into the regular EPP gateway ...

Fine.

> One SMTP message may contain multiple EPP messages.  Transaction IDs are

OK.

>> Content-Type

> ... headers are not used as identifiers ...

How about text/xml; charset=utf-8?

>> Content-Transfer-Encoding

> 8bit

How about base64?

> None

Mime-version: 1.0

> Only PGP is used.

OK.

Now an implementation question or two.

What bits are you using?

What email address(es) I can send the following (with a useful test fqdn):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <command>
    <check>
      <domain:check
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
       domain-1.0.xsd">
        <domain:name>example1.tld</domain:name>
        <domain:name>example2.tld</domain:name>
        <domain:name>example3.tld</domain:name>
      </domain:check>
    </check>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

What should I expect in return?

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 07 Sep 2002 09:04:39 -0400

Edmon,

Would it be accurate to say that yours is not an independent SMTP transport?

That you've implemented a "bridge", mapping (a subset of) requests/replies
to/from streams to queued files?

What it really does is convert SMTP sessions (optionally containing EPP
messages) to/from (optionally) EPP messages?

I woke up this morning asking myself how I could distinguish between one
cron-driven sequence of shell commands shuffleing a set of *.xml files from
a test directory to a server's i/o interface (file-as-a-pseudo-socket), and
an event-driven sequence of sendmail processing (shuffleing over a set of
spool files), with both employing the common server core and backend or
diagnostic stubs.

If (in my mind) I don't hang some of the semantics on 821 et seq, I end up
playing solitare with a bunch of files, with no transport dependency at all.

Well, that's this morning's coffee.

Eric

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Sep 2002 09:43:19 -0700

>Would it be accurate to say that yours is not an independent SMTP transport?

Eric, I do not understand your question.  Perhaps the easiest way to 
resolve my failure is for you to define what an "independent SMTP 
transport" for EPP would be, and how it differs from what you are calling a 
"bridge".

>messages) to/from (optionally) EPP messages?

convert SMTP sessions???

d/

----------

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 07 Sep 2002 13:05:39 -0400

> convert SMTP sessions???

That set of (stateful) transactions starting with HELO (or EHLO) and ending
with QUIT.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Sep 2002 10:01:10 -0700

> > dump it back into the regular EPP gateway ...

yup.

> > One SMTP message may contain multiple EPP messages.  Transaction IDs are

good.

>How about text/xml; charset=utf-8?

The set of valid content-types and valid content-transfer-encodings need to 
be defined.

>OK.

For text on security using an application over email, probably the best 
current template is in the Fax working group documents.  For example, it 
dodges the choice between PGP and S/MIME.

>Now an implementation question or two.

Eric, I don't understand your question.

>What email address(es) I can send the following

This question is essential, but the answer is not obvious.

If the service is supposed to "interact" with regular email users, then 
obviously all email addresses need to be valid.

If the service is using email simply to connect a client to a server -- and 
I think it is -- then we need the equivalent of a well-defined port 
number.  For email, that means a special mailbox string.

>What should I expect in return?

an EPP response, no?

d/

----------

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 07 Sep 2002 13:32:05 -0400

> the operative part of the question was the word "convert".

I can't help you on matters of faith.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Sep 2002 10:26:12 -0700

d/

----------

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 07 Sep 2002 13:33:19 -0400

> Eric, I don't understand your question.

Assume that Neteka is using some mlm other than /bin/mail, and some
mlm-to-epp mechanism other than mv, what?

As I said, and implementation question, and as he isn't using headers ...

Well, this has gone on long enough.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Sep 2002 13:38:11 -0700

>I can't help you on matters of faith.

Then it's a good thing this was about your clarifying what you meant, 
rather than any sort of matter of faith, on the theory that you used the 
word "convert" to refer to something technical.

>messages) to/from (optionally) EPP messages?

So the question is what you mean by "covert smtp session"?  What does it 
mean to convert an smtp session to/from an application message?

d/

----------

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 08 Sep 2002 22:15:33 -0400

[Caveat: POSIX, or rather XPG is assumed, not because it is the sole standard,
 but because it (XPG) is something I'm familiar with, and fond of. Like one
 of my kids.

 What follows assumes some set of files contain something of interest, e.g.,
 domain_create.xml, some 935 bytes of XML.
]

Dave,

Example: % mailx [email-masked] < domain_create.xml

The send-side mail spooling system performs read() of 935 bytes (from the
domain_create.xml file) and performs a write() of 936 bytes (trailing null)
to a temporary file. It proceeds to call gettimeofday() to prepend some 25
bytes of cruft before handing it off via fork()/exec() to another process,
the MTA, sendmail in this case, and unlink() the temporary file.

The receive-side mail spooling system performs similarly, with the spooled
instance of the message copied to some MUA-specific location, then unlinked.
I'll look at Vixie/Avolio and the source RSN to make sure my memory of XPG,
now POSIX, isn't a happy personal fiction.

While the <converted, or a term of your choosing> 935 bytes (plus cruft)
are managed by the two (or more) communicating MTAs, and the original is
optionally deleted at unlink()-time from the originating host (see also
the -r (remove) and the -s (symlink) options to lpr(1), similar semantics),
and not yet writen-and-sync'd into the portion of the filesystem managed
by the receiving or final MTA's spooler, one or more things may occur:

	o normal delivery (hooray!)
	o crash of either endpoint, or the relay(s) (boo!)
	o error of name to adderess resolution (hiss!)
	o network partition (ouch!)
	o sunspots and/or summer vacation (hooray!)

While unlikely, and possibly having only transient effect (that is, having
some temporal semantics such as spooled store-and-forward), these are all
quite different from, to quote my comment to Edmond, 

	[a] cron-driven sequence of shell commands shuffleing a set of
	*.xml files from a test directory to a server's i/o interface

Other than pilot-error, my cron-driven scripts lack the latency properties
and most of these potential, and frequently actual, failure conditions, of
SMTP transport sequences having some similar property of end-point delivery.

What I ment by "convert" was the temporal, and persistence, properties of
delivery of 935 bytes, from those of a file, to those of a message. I'll
pass on the serialization and on-the-wire stuff, other than those three
conditions I've mentioned.

Is it clear that if two processes are functionally indistinguishable,
but temporally distinguishable, or are non-functionally distinct, the
two processes are not identical? It is to me, but there are a lot of
folks a whole lot smarter than me, such as yourself, so I could be off
(comfortably) in a field of my own.

Have I answered your question? I seem to have deleted your last note,
which is sort of my point. Mail's permanence in the hands of a MUA is less
than that of files grazed only by open()/read() sequences of operations
by benevolent filesystems.

Eric