Re: [AM] Comments on sample protocol bindings (5.1.4)

Hugo,

Thanks for your comments, I've incorporated your suggestions into a new
version of section 5.1 which I'll pass to Stuart for incorporation into the
next version of the AM document.

I've also interspersed answers to your questions in the text below.

Marc.

----- Original Message -----
From: "Hugo Haas" <hugo@w3.org>
To: <xml-dist-app@w3.org>
Sent: Saturday, March 24, 2001 2:26 AM
Subject: [AM] Comments on sample protocol bindings (5.1.4)


> HTTP
> ====
>
> The current HTTP sample mapping on the initiator side is:
>
>    Initiator
>    Binding Primitive Binding Action
>    OP.start-req
>                      Confirm address validity
>    OP.start-conf
>    MSG.req
>                      Send POST data
>                      Receive POST results
>    MSG.ind
>    OP.end-req
>                      Close connection
>    OP.end-conf
>
> 1) What does "Confirm address validity" mean?
>    Is that a syntax checking on the URI of the destination?
>
It was really just intended as a place holder to show that the binding might
do something here, in this case check that the server name in the URL could
be resolved.

> 2) There is a "Close connection" option but no "Open connection" which
>    looks assymetric to me.
>
Good catch, this was an oversight on my part, the open connection  should
have come before the "Send POST data".

> Moreover, I was wondering what the boundary between OP.start-req and
> MSG.req was. I see the following steps to do in order to do an XMLP
> request via HTTP:
> 1) establish a connection to the server or reuse an existing connection.
> 2) send the request line (e.g. "POST /my_xml_service HTTP/1.1").
> 3) send a few miscellaneous headers (Host, User-Agent headers, etc).
> 4) send some XMLP specific headers (in the spirit of SOAPAction).
> 5) send the message body (XMLP message = POST data).
> 6) receive the HTTP response.
> 7) close the connection or keep the connection alive.
>
> 1 requires the knowledge of a host name and a port number.
> 2 and 3 require knowledge of the URI of the request.
> 4 and 5 require knowledge of the message.
>
I think 3 also requires knowledge of the message (POST data) since you have
to specify the length of the data you are sending (this is from memory, I'm
away from my HTTP book at the moment, so I may well be wrong here).

> I think that step 1 is in OP.start-req, and steps 2, 3, 4 and 5 in
> MSG.req's scope, and step 7 in OP.end-req.
>
I'd agree with that, but I think it would also be possible for an
implementation to delay 1 until data was available to be sent.

> I would therefore, not including for now the address validity check
> which is obscure to me, do the following:
>
>    Initiator
>    Binding Primitive Binding Action
>    OP.start-req
>                      Open connection
>    OP.start-conf
>    MSG.req
>                      Send POST request
>                      Receive POST results
>    MSG.ind
>    OP.end-req
>                      Close connection
>    OP.end-conf
>
>                 Responder
>    Binding Primitive Binding Action
>                      Accept new connection
>                      Receive POST request
>    OP.start-ind
>    OP.start-resp
>    MSG.ind
>    MSG.req
>                      Send POST results
>                      Receive connection close
>    OP.end-ind
>    OP.end-resp
>
> I replaced "POST data" by "POST request" because in my model MSG.req
> is really an HTTP request, whereas "POST data" makes me think of the
> message body of the HTTP request.
>
I've updated the HTTP table in the document to match yours.

> SMTP
> ====
>
> Let's consider the SMTP binding now, comparing it to the HTTP one. It
> does not have this address validation step, that I am going to leave
> out.
>
> An SMTP request would be modelled that way:
> 1) open a connection to a server or reuse an open connection.
> 2) send a HELO command (not required if the connection is already
>    open, but let's keep it simple).
> 3) initiate message delivery (e.g. "MAIL FROM:<whatever@example.org>").
> 4) specify recipient (e.g. "RCPT TO:<my_xmlp_stuff@example.com>").
> 5) start data transder with DATA command.
> 6) send XMLP message.
> 7) finish transaction (with a ".").
> 8) disconnection (QUIT command) or keep the connection open.
>
> 1 requires a host name and a port number.
> 4 requires knowledge of the URI (a mailto: URI) of the destination.
> 6 requires knowledge of the XMLP message.
>
> I see the steps organized like this:
> OP.start-req: steps 1 and 2. (opening of the SMTP session)
As in the HTTP case, an implementation might choose to delay opening an SMTP
session until the MSG.req has been received but I agree that the above is
the most likely.

> MSG.req: steps 3 to 7.
> OP.end-req: step 8. (termination of the SMTP session)
>
> I would therefore use, for SMTP:
>
>               Initiator
>    Binding Primitive Binding Action
>    OP.start-req
>                      Open SMTP session
>    OP.start-conf
>    MSG.req
>                      Send message
>    OP.end-req
>                      Terminate SMTP session
>    OP.end-conf
>
>                Responder
>    Binding Primitive Binding Action
>                      Begin SMTP transaction
>                      Receive mail message
>                      End SMTP transaction
>    OP.start-ind
>    OP.start-resp
>    MSG.ind
>    OP.end-ind
>    OP.end-resp
>
I've updated the SMTP table in the document to match yours.

Thanks,
Marc.

Received on Monday, 26 March 2001 20:15:06 UTC