RE: Message Header Spec

[David Burdett <david.burdett@commerceone.com>]

Folks

I know this is coming very late, but I though it would be useful to respond
to Chris's points which we should definitely discuss during our meetings
this week.

David

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Thursday, April 27, 2000 2:13 PM
To: ebXML-Transport@lists.oasis-open.org
Subject: Re: Message Header Spec


All,

My comments on the 0.3 Message Header spec
below.

Cheers,

Chris

Sect 2.1 Header Parts

Message Routing Info - this is confusing.
"... or has been taken by a message..."
should be omitted. This is covered by
the Message Routing History. IMO, it 
should not be both.
<DavidB>
I know what you're getting at, but:
1. Before the message is sent we need to use the future tense
2. After it has been received (but not processed) we should use the past
tense as the Message Routing Info has not yet been put into the Message
Routing History (and might never be if no routing history is kept).

... or perhaps I'm trying to be to precised (or perhaps pedantic) ...
</DavidB>

Message Routing History - should be required
even if there is only one hop. IMO, the TR&P
message handling s/w should afix a "postmark"
whenever it processes a message, regardless
if it is to be forwarded on elsewhere. This
preserves the audit trail/traceability of a
message and provides a consistent handling
of messages.
<DavidB> This is something we need to discuss. The idea behind "levels" that
was in earlier documents was that you should be able to use the same
elements with the same semantics in either a basic way, or an alternative
way that offers greater functionality. I don't see audit trails as a "must
always have" since I don't think that all interactions between parties will
need to be traceable.
</DavidB>

Message Type Dependent Headers - should we
really have any of these? Why wouldn't/couldn't
we express status/error information in the 
payload? I'd much prefer that the header be
processed consistently, regardless of the
"type" of message. 
<DavidB>
I think there's trade off here. Having a standard header is a good idea. But
it's also a good idea to have standard ways of reporting errors or the
status of a process. If we put the errors and status information in the
payload then we might also need to have another document that reports an
error/status in an application specific way. As a result we might have two
documents in the payload where one might do. Let's discuss this tomorrow.
</DavidB>

Sect 2.1.1

It isn't clear that we need to have separate
header parts.

If we use XMLDSig to sign documents (header
or otherwise) then the requirement to have
separate header sections is eliminated
because a signature applies to a reproducable
c14n'ed XML fragment. We're going to have to
consider the organization of the header document
to make it easy to sign parts which would 
likely be signed together (eg. separate out
routing history to a top-level element, etc.)

<DavidB>
I agree with you and I think I've taken this into account by having separate
sections. In practice I see each of these sections being a separate element
with an ID attribute as children of a ebxmlheader element. 
</DavidB>

If we must support S/MIME or PGP/MIME, then
this may be a requirement. However, I would
like us to make every effort to have as
few separate parts as possible. One would
be ideal. <DavidB>I agree</DavidB>I could see as many as three being
the maximum partitioning before it gets
completely out of hand, making the header
processing more complex than it needs to be.
<DavidB>In the short term I think that you have a single element as
described above and then sign the whole element using S/MIME or PGP until
Dsig comes along.</DavidB>

Secure Timestamp - Again, using XMLDSig,
this is a no brainer IMO. We can explicitly sign
any element(s) of a given document.
<DavidB>Totally agree.</DavidB>

Sect 2.2 Message Header, Header Part

1. Message Header Version

I've been having a good discussion here regarding
use of a namespace to identify version. I would
propose that we not use a namespace to identify
a version, but rather an explicit version element
or attribute. eg.

<ebXMLMessageHeader 
  xmlns="http://www.ebxml.org/ns/MessageHeader"
  version="1.0">
...
</ebXMLMessageHeader>

or

<ebXMLMessageHeader 
  xmlns="http://www.ebxml.org/ns/MessageHeader">
	<Version>1.0</Version>
...
</ebXMLMessageHeader>

This way, we can support version specific
processing without having to parse a complicated
name which implies a version. See the XSLT
specification for how they handled versioning.
Ideally, we should be able to support the 
same sort of version specific processing
if necessary (and it will be!)
<DavidB>
I don't have strong views on this and think we should adopt whatever ebXML
as a whole agrees to
</DavidB>
2. Message Type

Again, I have significant reservations
for characterizing message types and encoding
these into the header.
<DavidB>
The short answer is that by encoding message types into the header, makes it
possible for middleware to handle all reliable messaging on behalf of the
application. Otherwise the application has to do it. We should discuss this.
</DavidB>

3. Service Type

"...be private to a company or organization..."
I would like to avoid this if at all possible.
It will only lead to a fragile environment
and it exposes internals unnecessarily. I could
agree that it would be allowed, but it should
be discouraged. It would be preferable if there
were only standardized service "names" which
had a specific meaning/understanding within
or across verticals.
<DavidB>
I agree with your sentiment, but not the reality. If we say to people that
you can only use ebXML if you are part of some industry consortia that is
setting standards, then we're just creating a barrier to adoption. On the
other hand, I think market forces will tend to make companies want to use
definitions that are in widespread use (i.e. so that they can interoperate)
rather than invent their own. Let''s discuss.
</DavidB>

5. Message Set Data

If all the data in this element is identical
for all messages in a message set, then why
include it in the header. Couldn't this
be externalized (such as encoded in a TPA)
and referenced? RosettaNet only identifies 
and references the PIP, it doesn't include 
the entire PIP in each message instance.
<DavidB>I don't think so since:
1. I don't think we can insist on negotiating a TPA in every instance before
you can use ebXML, and
2. By including it in the header and separately creating a digest of it that
you digitally sign you can assert that one message/document is part of a set
of related messages without having to make all the messages available to
everyone. We found this idea very useful in IOTP so that you could prove you
made a payment to a bank for a purchase without actually telling the bank
what you bought.
</DavidB>

In section 3, Service Type is equated to PIP
identifier. If that's the case, then what
need is there for Message Set Data other than
the unique ID which binds all of the related
messages together in a single process instance?
<DavidB>
You need to Message Sets to support services that are made up of other
services. You might have a simple service that can be used in many contexts,
for example payment. The Service and Intent might tell you that you're doing
a Payment, but unless you have some other identifier that shows the context
in which a Service is being used, then you might not get the full picture.
This is much easier to explain using a white board.
</DavidB>

9. Quality of Service

QoS means lots of things to many people.
I think that we need to think carefully
about this. Certainly, it could be externalized
into the TPA (or equivalent). It would certainly
need to be negotiated or it won't work.
You can't expect an ack from a handler which
cannot do acks.
<DavidB>
I don't think we can insist on negotiated TPAs. It is quite reasonable for a
service to simple state it's operating parameters on a "take it or leave it"
basis, or even, for a service to rely on a default if they don't even do
that. I honestly don't think that there is so much variability that making
TPA negotiation mandatory makes sense.
</DavidB>

10. Message Manifest

Again, I think that this should be required,
not optional. It should include a reference
to itself, or its container document part,
IMO.
<DavidB>
If, as previously discussed, you have a error/status data in the header,
then you can quite easily have a message that only consists of a header. In
this case I think that a manifest is redundant.
</DavidB>

Sect 2.3 Message Routing Information, Header Part

12. Part Message Data

I don't believe that the ebXML TR&P message
handling layer should be responsible for 
carving up and reassembling arbitrarily large
messages. This would seem to me to belong to
the transport protocol handler.
<DavidB>
In theory I agree, but some transport protocols don't do this *reliably*.
This means you need to layer reliable messaging on top of any transport
protocol. The other thing to consider is that there are hard limits on the
size of message you can send using some protocols. In this case it might
mean that you can't necessarily send a message unless the application knows
the transport protocol that will be used. I don't like the idea of the
application having to know the transport protocol that will be used before
sending a message.
</DavidB>

Sect 2.5 Message Type Dependent Header Parts

I think that we should try to avoid, at all costs,
having different forms of header dependent upon
the type of message. This will only complicate
message processing unnecessarily. I think
that we should try to keep transport processing
consistent for ALL messages. 

Again, what I think this points to is that
we haven't come to terms w/r/t the responsibilities
of TR&P in the overall model of ebXML.
<DavidB>I agree with this statement</DavidB>

Monitoring of message choreographies should be
(IMO) the domain of the Business Process layer
and should probably be optional. 
<DavidB>Why? It is quite possible for the ebXML layer to do this. In which
case it takes an unnecessary burden off the application. Why force the
application to do things it doesn't *have* to do? This doesn't mean we're
stopping the application from doing it. The application can still check
choreographies if that's what you want to do.</DavidB>

It is also not clear (to me, anyway) why the
status, error and ack information isn't 
(or rather c/shouldn't be) carried in the 
payload. 
<DavidB>This has been discussed earlier.</DavidB>

Again, what business is it of the transport
to handle an error? Error handling requires business
logic unless the error is specific to TR&P
processing and something which can be resolved
by the TR&P layer.
<DavidB>If the messaging layer is handling reliable messaging, then it needs
to know about all the errors otherwise it might resend a message because a
reply was not received when no reply will ever come because of the
error.</DavidB>

Maybe, the real question should be, does TR&P
now extend to TRP&C (transport routing, packaging
and choreography).
<DavidB>I would say yes, in so far as it is required to support reliable
messaging.</DavidB>

IMO, the C should be left to the "application".
The "application" could be:
	- a workflow engine
	- a mailbox/queue 
		(eg. ECXpert, MQSeries, JMQ, JMS,	
		etc.)
	- a topic for pub/sub
	- a direct mapping to an application API
	wrapper (JSP/Servlet, EJB, CGI, whatever)

I don't think that we can, nor should we,
suggest/dictate how these "applications" will
perform their role.
<DavidB>
I'm not suggesting we dictate how these things should work. On the other
hand, I don't think we should force everyone to develop their own way of
doing these things, when it is quite easy IMHO to develop solutions that are
generally applicable. How many different ways of doing pub/sub do we need,
for example?
</DavidB>

Sect 4.1 Message Types

I still have reservations regarding the 
explicit classification of message type
(request, response, exchange, cancel, error,
status, ack, oneway, whatever). I honestly 
don't see any value in this. 
<DavidB>I don't see how we can do reliable messaging, audit trails at the
ebXML layer without them. We would end up not meeting some of our
requirements.</DavidB>

I am also
concerned that this really belongs in the 
domain of the BP WG, if anywhere, to characterize
the messages involved in the execution of
a business process. It certainly isn't 
clear what the TR&P layer would do with
this information since it shouldn't be
concerned with choreography.
<DavidB>What we're really doing is developing building blocks from which the
BP layer can build applications knowing that they don't have to worry about
retries for reliable messaging purposes.</DavidB>

Sect 4.1.3.7 Cancel Message

Since this is clearly a business/application level 
message (because it is/must be processed by the 
"applicaton"), we have no business specifying 
it's schema or even suggesting its semantics. 
Let's leave this to the Core and/or BP WGs.
<DavidB>
I agree that it needs to be processed by the application layer. However the
messaging layer also needs to know about the cancel so that it does not need
to retry to send messages. We are not stopping a Cancel message from also
including a document in the payload that is application specific - we aren't
defining the application schema.
</DavidB>

Chris I appreciate your comment. Let's see if we can come to some agreement
this coming week.