Re: Some musings.

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

> Well, in my mind, SMTP have some properties which I feel is different 
> from TCP:
> 
>   - Messages are sent as frames, and not in a stream
>   - Messages can arrive in random order
>   - Messages can be delayed so much they can be classified as
>     lost (or even lost, but my experience is that we talk about
>     very-long-delays)

These are properties common to SMTP implemented over TCP, or UUCP, so
I'm guessing that while we started with a "like-UDP" characteristic,
we won't actually be concerned with 1122, pages 80 or 108, et. seq.

On to business.

Application-layer framing allows application-layer frame identifiers,
a feature actually awkward to extract from TCP's SND.{UNA,WND,NXT} and
SEG.ACK state variables.

Bug or feature? YMMV. RDMA over TCP is hampered by just these "strengths".
Is anyone provisioning over iSCSI or IB or ... ? Not hardly. Must everyone
use TCP? Some don't now.

Ordering of operations isn't explicit. I hadn't thought of it until now,
but I don't this minute know why a registry MUST NOT reorder or infer any
predictate command. For instance, a 2303 isn't required when a <delete>
is received by a registry, for which a <create> has yet to be received.

The idea that transport semantics are intermixed with application semantics
is one that has been proposed earlier, viz. the discussion of overloading a
bit in the TCP transport mapping to signal between two EPP endpoints.

It wouldn't be prudent of a registrar to embark upon a order-dependent
sequence of commands, and fail to ensure that the ordering information
was not evident except to the EPP state machine. The same applies for
checking the return values of the same sequence. Ironically, there are
equivalent sequences of operations which could be presented to an EPP
state machine which would have indistinguishable outcomes. The persistence
of transaction identifiers is an interesting nuance.

ops:check,create,delete,info,login,logout,poll,renew,status,transfer,update
 
Delay. We don't actually have a timeout. BigBadRegistry (BBR) could hold
ThreeLittleRegistrar's (LRR) expensive dial-up for some time, simply sending
TCP keepalives.

Still, I think this is the clearest issue -- the temporal boundaries of
GRRP and/or EPP use cases. One could claim that unlike the community of
interest at IETF-43, the community of interest at IETF-49 excluded those
use cases that were delay-tolerant, or delay-insensitive. I'm not going
to suggest otherwise -- I think I know the sweet-spots of a plurality of
the implementers in PROVREG.

Next.

> EPP need to have:
> 
>   - One open session
>   - Messages passed back and fourth between client and server
>   - An explicit close of the session
>   - Detection of sessions being broken (signaling from transport layer)
>   - Messages are not multiplied (by mistake)

I preferred the language of 06:

  EPP supports both session-less and session-oriented operating modes,

to that of 07:

  Removed description of session-less operating mode from section 2.5

If nothing else, I think my work on both active networks (see Joe Touch's
2140) and HTTP cookies has permanently weakened my notion of what the
word "session" might mean.

Passing messages appears to be covered.

An explicit close? Seems optional. YMMV.

Signaling from transport? 821 has that. Eventually ;-)

Messages not multiplied. We have idempotency, so that can't matter. We also
waived (I think) all of 1122, so this isn't about congestive collapse of
some link due to some unfortunate "optimization". This too appears to be
covered.

That seems to reduce to MUST NOT and only "session-less", with the rational
left as an exercise for the implementor clever than I.

> The mapping between EPP and SMTP have to implement the missing parts 
> between EPP and the protocol itself.

That's why I was so intrigued by Edmon Chung's note. There wasn't anything
there, which seemed slightly under-dressed.

> If we now generalize this to do "EPP over SOAP" ...

Mark Nottingham's xml-rpc suggestion at the London meeting was interesting.

Well, this is mooted in less than two days anyway.

Thanks for your note.

Eric