Re: Please use this revised draft of Message Services spec for comments

[Prasad Yendluri <pyendluri@webmethods.com>]

David/Chris,

Great Work. Here are a few things I noticed, on a quick read.

1. Per the schema, all top level elements except Header have a minOccurs=0. So, we know that Header must
always be present but, what elements may be present (or not) based on the presence of the other elements
is not clear. This needs to be captured somewhere. For example it does not make sense to have all of
MessageStatusRequest, MessageStatusResponse, ErrorList and Acknowledgment elements in the same message. I
would think it would be invalid to have more than one of these in the message? We need to capture this
(and all such) in the schema and not make it a semantic level interpretation thing.

2. Some of the elements render the message a "status"/"ack"/"error"  message and it seems don't need (may
should not have) any payload. For example (again) for the MessageStatusRequest, MessageStatusResponse and
Acknowledgment messages, shouldn't  the payload should be null? How do we capture this information?

3. For the ApplicationHeaders, the description and the examples show MustUnderstand attribute is at the
ApplicationHeaders (top) level.  This would would make it all or nothing for all application headers.
That is, when set to to "true" you must understand them all or you fail. I think it is better if we could
move it inside but, that could be tricky to specify with "any" elements! BTW, the schema does not show
this attribute at all. It has an attribute called "id" that is not described in the specification.

4. For non-repudiation purposes, the hash (of the relevant part) of the received message is included in
the acknowledgment (and signed). We don't accommodate that. Is that by design?

5. Line 386 states An Acknowledgment element may be present on any message. Is this true? When/why do we
want to include acks with other messages?

6. Section 8.7 (line 716-740) needs updated to use the MessageStatusRequest, MessageStatusResponse stuff.
It is not clear when one would want to use this mechanism versus the Acks (reliable messaging) as
described in section 10.

7. The "UnAuthorized" code in MessageStatusResponse (in the schema) for the original message or is it an
indication that the requester does not have authorization to query on the particular message (may be not
the one they sent originally?).

8. Do we really need both ApplicationHeaders and the #wildcard (in the Header)? I understand the
difference but, I am not sure we need. Additionally this does not have "MustUnderstand" attribute (at
least not described in the spec). BTW, this is not in the schema.

9. There is an "AnyAttribute" for the ebXMLHeader element in the schema. That has not made it into the
spec.

10. Routing header element is shown to get modify along the path (for multi-hop). This requires
re-write/re-assmbling of the ebXMLHeader and hence the repackaging (MIME) of the message at each hop. Is
this acceptable?

11. What is the real purpose of the trace in the routing header?

12. I guess the order of the new entries added along the way , in the routing header is important. That
is, always add at the end. If so, we need to state that. Since the receiver depends on the SenderURI on
the "last" entry.

13. Line 526 Description elements not listed in the lines 466-474 and also not present in the schema. Not
clear if this is in or out?

14. Line 1678, the "type" attribute does not match the multipart/signed type.

That is all I have.

Thanks, Prasad

"Burdett, David" wrote:

> Folks
>
> Here's a PDF version of the word file that Chris Sent out. The changes are:
> 1. All revision marks have been removed
> 2. I've included a corrected Schema file - Status Data was incorrect.
> ... and that's all.
>
> Please reference the line numbers in this version when making comments. I
> also think it will be helpful if we focus initially on substantive comments
> - the typos will be fixed anyway.
>
> Finally I apologise for the weird bullet marks that my version of Adobe
> Acrobat seems to be generating. This will be fixed once I understand what
> the problem is
>
> Thanks
>
> David
> PS I've also included the schema in Appendix A as a text file
>
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Wednesday, December 20, 2000 2:35 PM
> To: ebxml-transport@lists.ebxml.org
> Subject: revised draft of Message Services spec for comments
>
> All,
>
> David and I have been working on a revision draft of the spec
> that:
>         - incorporates the changes we have agreed upon:
>                 - Doug's charset changes
>                 - Content-Length
>                 - section numbering/headings
>         - incorporates some of the things that have not yet been
>         formally agreed upon, but places proposed updates in context
>         where they might more readily be appreciated:
>                 - Chris's manifest proposal
>                 - extension mechanism proposal (Chris & Robert)
>                 - flattening of CPAInfo
>
> Additionally, it includes a new section on Security which is still
> a work in progress.
>
> Finally, David has incorporated the discussion and conclusions
> of the Tokyo f2f regardiung reliable messaging into a revised section
> on RM. He has also added a section on MSH Services (Status and PING)
> which we collaborated on together.
>
> The appendicies have been removed since they would only confuse things
> at this stage. I have attached a revised XSD, but I think that it still
> has a few flaws, especially as regards StatusData. I just don't have
> the right tools to analyze it more carefully, and it is getting late;-)
>
> There may be other changes I haven't listed but just don't recall.
> A few grammatical modifications and some style modifications were
> made along the way. David, if I've omitted anything, please fill
> in the blanks in my memory.
>
> Anyway, we wanted to get this out there for review and comment. We
> hope to have this serve as something we can work with now until
> the London f2f next year. We recognize that it is still a bit rough
> in places, but we felt it better to get something written now than to
> have
> to cram it all in in less than a week in London.
>
> For now, PLEASE don't edit this. Turn line numbering on and report
> comments by line number and version (0.9 for starters). Or, you can
> edit it and send in a small section with the suggested edits, preferably
> with change tracking enabled.
>
> So, let the flames begin!
>
> Cheers,
>
> Chris
>
>   ------------------------------------------------------------------------
>                                                    Name: ebXML Message Service Schema version 0.9.xsd
>    ebXML Message Service Schema version 0.9.xsd    Type: unspecified type (application/octet-stream)
>                                                Encoding: QUOTED-PRINTABLE
>
>                                                  Name: ebXML Message Service Spec Version 0.9.pdf
>    ebXML Message Service Spec Version 0.9.pdf    Type: Portable Document Format (application/pdf)
>                                              Encoding: BASE64