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

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

See comments below.

David

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Thursday, December 21, 2000 3:36 AM
To: ebxml-transport@lists.ebxml.org
Subject: Re: Please use this revised draft of Message Services spec for
comments


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.

<db>To answer points 1 and 2 we should use top level schema definitions to
limit use of what combinations are allowed.</db>

> 
> 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.
<db> The rationale is that you acknowledge an earlier message and also
return a payload in the same message </db>
> 
> 6. Section 8.7 (line 716-740) needs updated to use the
MessageStatusRequest, MessageStatusResponse stuff.
<db>This section is correct earlier references to MessageStatusRequest and
MessageStatusResponse were from an earlier version and need to be
updated.</db>
> It is not clear when one would want to use this mechanism versus the Acks
(reliable messaging) as
> described in section 10.
<db>Perhaps true but we could use this if reliable message was not being
used.</db>
> 
> 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?).
<db>It is the former - the requester is unauthorized.</db>
> 
> 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?
> 
<db>There was much debate about this in the early days of TRP and the
decision was to keep the ebXML document as a single document. Hence the need
to repackage each time.</db>
> 11. What is the real purpose of the trace in the routing header?
<db>So that a recipient of a message can trace how it was delivered after
the event. This can be important in measuring perfomance levels of
systems.</db>
> 
> 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.
> 
<db>We do see lines 589-591</db>
> 13. Line 526 Description elements not listed in the lines 466-474 
<db>Correct. This needs fixing.</db>
and also not present in the schema. Not
> clear if this is in or out?
> 
<db>This is in. The schema definition of description is at the end in the
"common" section</db>
> 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