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

[christopher ferris <chris.ferris@east.sun.com>]

Prasad,

Thanks for the thorough feedback.

Some comments in response below.

Cheers,

Chris

Prasad Yendluri wrote:
> 
> 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.

There is a section in the spec which deals specifically with this
(identifying
what goes with what).

> 
> 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?

No Manifest == no payload in a message. I believe that the spec itself
contains this info for the types of messages you describe.

> 
> 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.

Good point. I thought I had modified that...

> 
> 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?

We do, it just isn't in there yet (since I'm still working on the
Security section, specifically XMLDSIG).

> 
> 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?

I think that this is fully discussed in the spec.

> 
> 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.

I'll fix this. mustUnderstand is intended to be used on any extension...

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

Thanks, I'll fix that.

> 
> 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
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard