RE: Very Rough Draft of Header Specification

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

Prasad
 
Please see comments below. Let me know if you have any more queries.
 
David
PS i'm behind on my ebXML emails. Aim to catch up on the rest tomorrow.

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Thursday, March 16, 2000 4:53 PM
To: David Burdett; ebXML Transport (E-mail)
Subject: Re: Very Rough Draft of Header Specification


David, 

Please see some comments below: 


1.	I am curious why we plan to develop separate specifications for all
different topics listed in section 1.1 (e.g ebXML MIME Message Envelope
Specfication, ebXML XML Message Envelope Specfication etc.). By
specification I am assuming they would all be separate documents. Could they
have been subparts (sections) of the same documents? They are pretty closely
related after all.  

##I In principle, putting them all in one specification is fine. It's just
that you might find that someone might want to send the messages over other
formats, MQ Series, MSMQ etc and then we would. Then there's the issue of
would the same person write them all, as well as the need to have seperate
versioning for each protocol to save having to rev the software just because
the specification has changed.##

1.	I am not sure what exactly will be in the "Transport Envelope" that
ebXML needs to specify? If we have a MIME / XML packaged message could that
simply be shipped over HTTP or SMTP etc.? What is that ebXML needs to
specify? Do you mean things like MIME content type to be used with HTTP
POST?  

##Basically, yes. There would not be much, but it needs to be specified.## 

1.	If  "Message Routing Info" is something that is (potentially)
extended as each time the message passes through a new hop, shouldn't it
really be disjoint from the rest of the Message Header (that has headers
that are closely coupled with the business exchange)? That would also help
the case of a "relay" or a "hub" not having to look at the real business
message to be able to route.  

## Agreed. That's why the Message Routing Info is a separate part of the
Message Envelope (see section 2) ##

1.	Shouldn't the  "Signatures" be really part of the message Body
rather than Header?  ##There is no reason why you can't put signatures in
the body if you want to. However if signatures are put in a specific place
where the header can recognize them, then it means that it should be
possible for middleware software to check the signatures in some standard
way that would reduce the burden on the application programmer - as long as
the application programmer trusts the software ...## Or may be a separate
entity by itself (neither header nor Body)  ##This is a perfectly valid
option, since you could have, for example, Header Envelope; Signature(s);
Message Body. In that sequence. I think it's always a good idea to put
signatures neare the start. Thinking about it though, if we point to the
signatures from the Message Manifest, I'm not really sure it matters much
where you put the signature piece.##  It os not clear to me, how the
association between a signature and the part(s) of the message it signs
would be established?   ## In S/MIME it's done by physical association (I
think !) in XMLDSIG, you can point to the thing that is being singed using a
URI.##  I am thinking we need to have a structure that permits signing the
routing headers (potentially multiple times, as they get changed),
individual parts (on a per part basis) and the whole message (again multiple
times if needed).   ##I've always thought that you could have multiple
signatures (see the "s" on signatures in section 2). What we need to do is
work out an approach where the individual signatures and their purpose can
be quickly and easily determined.##

1.	I am curious why we are trying to provide services like RPC (level-1
headers) in ebXML? I mean other specifications like XML-RPC (and SOAP) are
already in place for that purpose?  ##True, but if we can get agreement on
the names to be used for the very low-level stuff then their might be some
chance of convergence ;)  I don't think we should go out-of-our-way to
support RPC, but really at the wrapper level I think there is some
overlap.##  

2.	Some of the items defined in "Routing Information" like "Required
Message Response Times" seem to really belong to "Quality Of Service".  ##I
agree they are quality of service related - in fact in an earlier version
John and I worked on, they were in the message header. I'm just thinking
that you might have a default transport protocol of HTTP which should
respond in 10s of seconds, but that if that failed, then you might send by
SMTP that would have a response time of hours. So really I think you might
need to vary the response time depending on the transport protocol used.## 

Thats is all I have. 

Thanks, Prasad 


David Burdett wrote: 


Folks 

I attach a very rough draft of the Header Specification. The roughest area 
is probably the Data Dictionary as I know there are inconsistencies in this 
section when compared with the Header Structures section - the latter is the

more accurate and over rules what is currently in the Data Dictionary - it's

just that I've run out of time and thought it better to get this to 
everyone a day earlier so that you can read it. 


The way the spec was developed was: 
1. Identify the data requirements from our requirements documet 
2. Do a quick review of the header classification work that John I did, to 
see if there were any gaps. 


What we absolutely must do (but haven't yet) is to do a rigorous comparison 
of this spec with other specs (BizTalk, AS1, AS2 etc) to make sure that we 
can map between them. This should then give a migration path from these 
standards to the approach we are developing. 


John Ibbotson is also planning to do a sample DTD so that we can see how 
this all fits together 


David 
PS If anyone wants a PDF version please let me know. 
 <<ebXML Message Header Specification v0-10.doc>> 


Advanced Technology, CommerceOne 
4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA 
Tel: +1 (925) 520 4422 or +1 (650) 623 2888; 
mailto:david.burdett@commerceone.com;
<mailto:david.burdett@commerceone.com;>  Web: http://www.commerceone.com
<http://www.commerceone.com>