OASIS ebXML Messaging Services TC

Hi I resent the meetings, with the correct meeting information. The old invites required me to login for the meeting to start. Now the meeting can be started by anyone of you logging in. I also have the host key in there in case one of you needs to share documents in my absence. I'll update the calendar in the TC page too. Thanks Makesh

Hi Makesh and all, One of our customer reported one issue which is about the Reception Awareness Receipt (not non-repudiation receipt). The problem is with standard non-repudiation receipts. Here we seem to have a  conflict between the ebMS core and AS4 standards . The ebMS 3.0 header schema has the following:                < xsd:complexType  name =" Receipt ">                          < xsd:sequence >                                      < xsd:any  namespace =" ##other "  processContents =" lax "  maxOccurs =" unbounded "/>                          </ xsd:sequence >              </ xsd:complexType >   Meaning it can be any element as long as it isn’t in the same namespace as the target namespace:   ##other Elements from any namespace that is not the target namespace of the parent element containing this element can be present.   The AS4 standard (5.1.8) states: When a Receipt is to be used solely for reception awareness, the sender of the Receipt MUST contain a copy of the eb:UserMessage structure of the received AS4 message.   If this is followed it causes a problem because the namespace in the request for this element is the same as for Receipt i.e.  http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/   Also in AppendixB of the AS4 standard there is a stylesheet to generate a Receipt from a Request. This generates a Receipt for a non-signed Request that has the UserMessage copied under Receipt with the  same namespace , failing the schema check.   So is it already a known issue? What's your thoughts about this? As the DGI AS4 interop test is going on now I'm sure this will be an issue. Thanks, Rong  

Hi Rong There is a Jira open for this : EBXMLMSG-3. We discussed this two weeks ago and there are some updates to the Jira by Dale. Thanks Makesh From: Rong Xing < rxing@tibco.com > Date: Tuesday, May 14, 2013 12:17 AM To: Makesh Rao < marao@cisco.com >, " ebxml-msg@lists.oasis-open.org " < ebxml-msg@lists.oasis-open.org > Subject: [ebxml-msg] Conflicts in Reception Awareness Receipt Hi Makesh and all, One of our customer reported one issue which is about the Reception Awareness Receipt (not non-repudiation receipt). The problem is with standard non-repudiation receipts. Here we seem to have a  conflict between the ebMS core and AS4 standards . The ebMS 3.0 header schema has the following:                < xsd:complexType  name =" Receipt ">                          < xsd:sequence >                                      < xsd:any  namespace =" ##other "  processContents =" lax "  maxOccurs =" unbounded "/>                          </ xsd:sequence >              </ xsd:complexType >   Meaning it can be any element as long as it isn’t in the same namespace as the target namespace:   ##other Elements from any namespace that is not the target namespace of the parent element containing this element can be present.   The AS4 standard (5.1.8) states: When a Receipt is to be used solely for reception awareness, the sender of the Receipt MUST contain a copy of the eb:UserMessage structure of the received AS4 message.   If this is followed it causes a problem because the namespace in the request for this element is the same as for Receipt i.e.  http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/   Also in AppendixB of the AS4 standard there is a stylesheet to generate a Receipt from a Request. This generates a Receipt for a non-signed Request that has the UserMessage copied under Receipt with the  same namespace , failing the schema check.   So is it already a known issue? What's your thoughts about this? As the DGI AS4 interop test is going on now I'm sure this will be an issue. Thanks, Rong  

Makesh,   Thanks for the clarification. The committee might need to reach a conclusion soon, otherwise people would face this problem in the inter-op test.   Thanks, Rong   From: Makesh Rao (marao) [mailto:marao@cisco.com] Sent: Tuesday, May 14, 2013 12:35 AM To: Rong Xing; ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Conflicts in Reception Awareness Receipt   Hi Rong   There is a Jira open for this : EBXMLMSG-3. We discussed this two weeks ago and there are some updates to the Jira by Dale.   Thanks Makesh   From: Rong Xing < rxing@tibco.com > Date: Tuesday, May 14, 2013 12:17 AM To: Makesh Rao < marao@cisco.com >, " ebxml-msg@lists.oasis-open.org " < ebxml-msg@lists.oasis-open.org > Subject: [ebxml-msg] Conflicts in Reception Awareness Receipt   Hi Makesh and all,   One of our customer reported one issue which is about the Reception Awareness Receipt (not non-repudiation receipt).   The problem is with standard non-repudiation receipts. Here we seem to have a  conflict between the ebMS core and AS4 standards . The ebMS 3.0 header schema has the following:                < xsd:complexType  name =" Receipt ">                          < xsd:sequence >                                      < xsd:any  namespace =" ##other "  processContents =" lax "  maxOccurs =" unbounded "/>                          </ xsd:sequence >              </ xsd:complexType >   Meaning it can be any element as long as it isn’t in the same namespace as the target namespace:   ##other Elements from any namespace that is not the target namespace of the parent element containing this element can be present.   The AS4 standard (5.1.8) states: When a Receipt is to be used solely for reception awareness, the sender of the Receipt MUST contain a copy of the eb:UserMessage structure of the received AS4 message.   If this is followed it causes a problem because the namespace in the request for this element is the same as for Receipt i.e.  http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/   Also in AppendixB of the AS4 standard there is a stylesheet to generate a Receipt from a Request. This generates a Receipt for a non-signed Request that has the UserMessage copied under Receipt with the  same namespace , failing the schema check.   So is it already a known issue? What's your thoughts about this? As the DGI AS4 interop test is going on now I'm sure this will be an issue.   Thanks, Rong