RE: Draft Alternate Section 3.

Hi,

	Overall looks excellent. I have a few preliminary observations. May be they
are already discussed.

	1.	"Conceptually and from the point-of-view of message correlation, each
XMLP_UnitData operation causes the transmission of a different message even
if the message has the same value as a previous message. "

		If so, how would we handle reliable messaging, retries et al. Are we
leaving it to the protocol layer ?

	2.	What about sequencing ? Why not add the Correlation.MsgSequence now
itself while we can do it ? From my practical experience, this would help a
lot of B2B issues.

	3.	Was there any logic behind leaving faults out of status ? faults could
be a good source of more information, especially for a status of .failure.
(You had (faults) in many of your messages).

	4.	On a related note, why isn't .failure a status disposition ?

	5.	I couldn't make out, if in your mind, correlation could be a unique id
for the message and possibly a GUID or UUID. (I do agree that the mechanism
would not be specified by the AM but at the binding level.)

	6.	I assume we define a Message = (Message.Headers, [Faults],
Message.Bodies, [Message.Attachments])

	7.	Why can't status contain a Message as well ? That way the sender can get
more information as needed

	8.	Because the status doesn't have the [Correlation], do we assume a
request/response pattern ? i.e. a send waits for a status and on time out
assumes an error.

	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.

cheers



|-----Original Message-----
|From: Williams, Stuart [mailto:skw@hplb.hpl.hp.com]
|Sent: Sunday, March 25, 2001 12:50 PM
|To: Henrik Frystyk Nielsen (E-mail); Jean-Jacques Moreau (E-mail); John
|Ibbotson (E-mail); Krishna Sankar (E-mail); Lynne Thompson (E-mail);
|Marc Hadley (E-mail); Mark A. Jones (E-mail); Martin Gudgin (E-mail);
|Nick Smilonich (E-mail); Oisin Hurley (E-mail); Scott Isaacson (E-mail);
|Yves Lafon (E-mail)
|Cc: 'xml-dist-app@w3.org'
|Subject: AMG: Draft Alternate Section 3.
|
|
|Folks,
|
|I have taken a go at redrafting section 3 inline with the thoughts on
|Causality I posted on Friday [1]. In response to suggestions [2,3,4] I've
|called the parameter Correlation.
|
|I have also removed the OrigPath and ActualPath parameters, but
|retained the
|(optional) ImmediateDestination parameter which I think is more in
|line with
|current thoughts on how messages get routed between intermediaries.
|
|I'd appreciate feedback asap.
|
|Many thanks,
|
|Stuart
|[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0216.html
|[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0219.html
|[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0220.html
|[4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0222.html
|
|