Next in thread → Next in month →

RE: [ebxml-msg] Comments on Working Draft 06

From
Jacques Durand <>
Date
2005-11-16T00:46:36+00:00
ID
Thread
RE: [ebxml-msg] Comments on Working Draft 06
Ric:

 

-----Original Message-----

From: Ric Emery [mailto:] 

Sent: Tuesday, November 15, 2005 1:39 PM

To: 

Subject: [ebxml-msg] Comments on Working Draft 06

 

Here are a few minor editorial comments on Working Draft 06

 

701-702: 'In particular, this specification requires that header  

blocks supporting message reliability and security be understood
by  

an MSH.'

      I am a bit uncomfortable with the word
'requires'. It gives me the  

feeling that it is required that an MSH implementation must
support  

multiple Reliability Module specifications.

 

<JD> agree: I think we need to work
in parallel on a comprehensive Conformance section that would spell out what is
required and what is not. So the main body of the spec should not have to make
such meta-statements. Even keywords like MUST, SHOULD, MAY should only be used where
we are sure they will not conflict with possible conformance profiles.

 

 

844 - ' ebXML Messaging 3.0 does not define any extension
elements  

for a SOAP Body'

      Is this necessary to say? If extension
elements were defined we  

should point that out. Why point out the absence of defined extensions?

 

<JD> I guess that was to underline
the contrast with ebMS2... But just the title of this small section is
confusing. Maybe we can remove 4.1.3.6 and put back this sentence in previous
section?

 

1201-1202 - 'If a CPA is referred to by the eb:AgreementRef, the  

number of conversations related to this CPA must comply with CPA  

requirements. The value of eb:ConversationID MUST uniquely identify
a  

conversation within the context of this CPA'.

      Good information, but i am not sure it
belongs here. Seems to me  

that since CPAs are not required the CPA related implementation  

details may not belong. Though I could be convinced otherwise.

 

<JD> Right. It is more a matter of
compliance of an implementation to this referred CPA than to ebMS spec. Agre to
remove.

 

1266 - 'of the purpose or intent of the message'

      Should the word 'message' be modified to
'payload'?

 

<JD> yes.

 

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  You may a link to this group and all your
TCs in OASIS

at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Next in thread → Next in month →