[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Cc: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: Patrik Fältström <paf@cisco.com>
Date: Sun, 29 Sep 2002 07:05:31 -0700
In-Reply-To: <200209271550.g8RFowCO014629@nic-naa.net>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: Some musings.

On Friday, September 27, 2002, at 08:50 AM, Eric Brunner-Williams in 
Portland Maine wrote:

> So, idiot that I am, I've talked (typed actually) my way into thinking
> that the issues that you could be thinking of would be solved if the 
> EPP
> over FOO transport binding (optionally) provides for the following:
>
> 	o a mechanism to provide a UID (or non-wrapped in reasonable time),
> 	o a mechanism to provide for non-repudiation of origin,
> and
> 	o a mechanism to provide for non-repudiation of receipt.
>
> I think that covers [lost,retransmission,ordering].

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)

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)

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

If we now generalize this to do "EPP over SOAP", I see a "simple" 
mapping like the one was proposed only fulfill the requirements EPP has 
on transport on some transport possibilities for SOAP. I.e. SOAP by 
itself doesn't have all of the properties I list above (yes, I think 
that is one of the _BIG_ issues with SOAP -- people have not been 
thinking enough, so SOAP is not as well defined as people might want it 
to be).

> I think "secure" could mean providing for the following:
>
> 	o encrypting data (optionally)
> 	o signing data (optionally)
>
> Naturally, the EPP over FOO transport binding might have something 
> useful
> to say about formats used too.

Yes.

    paf


Home | Date list | Subject list