RE: Draft Alternate Section 3.

Hi,

	Good ideas. I was really thinking of "protocol binding" but "protocol
conversion" does offer possibilities.

	Just on the subject, I see XMLP used in netServices not just webServices.
Even though SOAP/http might be the norm now, nothing should stop us using
XMLP over other mechanisms.

	IMHO, if an application (be it be in a net widget or a web browser or a
refrigerator which talks some device protocol like JINI or ..) understands
the syntax and semantics of XMLP, it should be able to converse through as
many underlying "protocols" as possible.

	cheers

|-----Original Message-----
|From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
|Behalf Of Jean-Jacques Moreau
|Sent: Monday, March 26, 2001 1:40 AM
|To: Krishna Sankar
|Cc: Williams Stuart; xml-dist-app@w3.org
|Subject: Re: Draft Alternate Section 3.
|
|
|Krishna Sankar wrote:
|
|>         9.      "This operation may be implemented over HTTP,
|HTTPS, SSL/TCP, TCP and
|> SMTP" : Why not RMI, COM+ et al ? The point is do we *need to*
|> assume/specify any protocol/transport ? Of course, we would have the
|> bindings and hopefully we could specify bindings to these as well.
|
|Using RMI or COM+ as an underlying transport protocol (ie, to
|transport XMLP enveloppes
|verbatim) seems a bit far-fetched (don't these protocols already
|include the machinery that
|XMLP is about to define?). On the other hand, I can see why you
|would map XMLP enveloppes to
|RMI/COM+ requests. But then, we are probably talking about
|"protocol conversion" rather than
|about "protocol binding".
|
|Jean-Jacques.
|
|
|

Received on Monday, 26 March 2001 11:45:04 UTC