…

4938.4.1 From and To elements

494 The From element identifies the Party that originated the message. The From element consists

495 of aone or morePartyId elements.

496 The To element identifies the intended recipient of the message. As with From, it is a logical

497 identifier that is comprised of aone or morePartyId elements.

If either the From or To elements contain multiple PartyId elements, all members of the list must identify the same organisation. Unless that type value refers to multiple identification systems, a type attribute value must not appear more than once in a single list of PartyId elements.

This mechanism is particularly useful when transport of a message between the parties may involve multiple intermediaries (see Sections 8.5.3, Multi-hop Routing Header Sample and 10.2, ebXML Reliable Messaging Protocol). More generally, the From party should provide identification in all domains it knows in support of intermediaries and destinations that may give preference to particular identification systems.

8.4.1.1 PartyId element

498 The PartyId element has a single attribute: type and a string value.

499 If the type attribute is present, then it indicates that the parties that are sending and receiving the

500 message know, by some other means, how to interpret the content of the PartyId

501 element. The two parties MAY use the value of the type attribute to assist in the interpretation. Values taken from the EDIRA (ISO 6523), EDIFACT ISO 9735 or ANSI ASC X12 I05 registries are recommended.

502 If the type attribute is not present, the content of the PartyId element MUST be a URI [RFC 2396].

503oOtherwise the receiving MSH MUST report an error (see section 08.8) with errorCode set to Inconsistent and severity set to

504eError.

505 The following fragment demonstrates usage of the From and To elements. The first illustrates a

506pair of user-defined numbering schemes,;and the second, a single URN.

507

508<From>

509<PartyId type="MyNumberingSchemeDUNS">1234567890123006998397</PartyId>

<PartyId type="SCAC">RDWY</PartyId>

510</From>

511<To>

512<PartyId">urn:dnb.com:duns:321098765-4321</PartyId>

513</To>

…

6628.4.10 Header sample

…

667<From>

668<PartyId type="uri">...</PartyId>

669</From>

670<To>

671<PartyId type="userType">...</PartyId>

672</To>

…

6918.5.1 Routing Header Element

692 The RoutingHeader element contains information about a single transmission of a message

693 between two Parties. If a message traverses multiple hops by passing through some type of

694 intermediate system between the From Party and the To Party, then each transmission over each

695 hop results in the addition of a new Routing Header element.

696 The RoutingHeader element is a composite element comprised of the following subordinate

697 elements:

698SenderURI

699ReceiverURI

700ErrorLocationURI

701Timestamp

702SequenceNumber

703#wildcard

7048.5.1.1 SenderURI element

The Sender element is a composite element comprised of the following subordinate elements:

  • PartyId
  • Location

As with the From and To elements, multiple PartyId elements may be listed in the Sender element. This allows receiving systems to resolve those identifiers to organisations using a preferred identification scheme without prior agreement among all parties to a single scheme.

8.5.1.1.1 PartyId element

This element has the syntax and semantics described in Section 8.4.1.1, PartyId element. In this case, the identified party is the sender of the message. This element may be used in a later message addressed to this party by including it in the To element of that message.

8.5.1.1.2 Location element

705 This element contains the URLI of the message's Sender Messaging Service Handler. The

706 recipient of the message, unless there is another URLI more specifically identified within the CPA,

707 uses the URLI to send a message, when required that:

708responds to an earlier message

709acknowledges an earlier message

710reports an error in an earlier message.

7118.5.1.2 ReceiverURI element

As with Sender, the Receiver element is a logical identifier comprised of the location where the message was sent and the party controlling that location. In this case, the subordinate Location

712This element contains the URLI of the Receiver’s Messaging Service Handler URLI. It is the URLI to

713 which the Sender sends the message.

7148.5.1.3 ErrorLocationURI element

715 This URLI, if present, identifies the URLI that is used for reporting errors. If it is not present then

716 errors are reported by sending a message to the Location provided in the SenderURI element. This location must also be under the control of the organisation identified by the PartyId elements listed in the Sender element. (The location specified in the ErrorLocation element must be able to receive ebXML messages containing a To element identifying the Sender party.)

…

7348.5.2 Single Hop Routing Header Sample

…

741<From<PartyId>urn:myscheme.com:id:PartyA-id</PartyId</From>

742<To<PartyId>urn:myscheme.com:id:PartyB-id</PartyId</To>

…

753<SenderURI<Location>httpurl://PartyA.com/PartyAMsh</Location>

<PartyId>urn:myscheme.com:id:PartyA-id</PartyId</SenderURI

754<ReceiverURI<Location>httpurl://PartyB.com/PartyBMsh</Location>

<PartyId>urn:myscheme.com:id:PartyB-id</PartyId</ReceiverURI

…

760<From<PartyId>urn:myscheme.com:id:PartyB-id</PartyId</From>

761<To<PartyId>urn:myscheme.com:id:PartyA-id</PartyId</To>

…

773<SenderURI<Location>

<PartyId>urn:myscheme.com:id:PartyB-id</PartyId</SenderURI

774<ReceiverURI<Location>

<PartyId>urn:myscheme.com:id:PartyA-id</PartyId</ReceiverURI

…

7788.5.3 Multi-hop Routing Header Sample

…

786<From<PartyId>urn:myscheme.com:id:PartyA-id</PartyId</From>

787<To<PartyId>urn:myscheme.com:id:PartyC-id</PartyId</From>

…

798<SenderURI<Location>

<PartyId>urn:myscheme.com:id:PartyA-id</PartyId</SenderURI

799<ReceiverURI<Location>

<PartyId>urn:myscheme.com:id:PartyB-id</PartyId</ReceiverURI

…

805<From<PartyId>urn:myscheme.com:id:PartyA-id</PartyId</From>

806<To<PartyId>urn:myscheme.com:id:PartyC-id</PartyId</From>

…

817<SenderURI<Location>

<PartyId>urn:myscheme.com:id:PartyA-id</PartyId</SenderURI

818<ReceiverURI<Location>

<PartyId>urn:myscheme.com:id:PartyB-id</PartyId</ReceiverURI

…

822<SenderURI<Location>

<PartyId>urn:myscheme.com:id:PartyB-id</PartyId</SenderURI

823<ReceiverURI<Location>

<PartyId>urn:myscheme.com:id:PartyC-id</PartyId</ReceiverURI

…

8528.7 StatusData Element

…

861a ForwardURIelement. This MUST only be present if messageStatus is set to

862Forwarded. If present it indicates the URI of theReceiverURIto which the message was

863 forwarded. This element has the same composition as the Sender and Receiver elements.

…

9798.9 Acknowledgment Element

I removed all mention of a From element from this element. That addition provides no value unless the Routing Header element is left out. Even in that case, it’s confusing. We should probably just disallow that case.

…

992 a From element

…

999 8.9.2 From element

1000 This is the same element as the From element within Header element (see section 8.4.1).

1001 However, when used in the context of an Acknowledgment Element, it contains the identifier of

1002 the Party that is generating the acknowledgment message.

1003 If the From element is omitted then the Party that is sending the element is identified by the From

1004 element in the Header element.

…

10379.1.1 Message Status Request Message

My apologies. I accidentally turned off change tracking while performing the rest of the modifications. Instead, new text is marked in blue. The old text is just no more.

…

1048a To element that identifies a Party that should receive the message. If a RoutingHeader

1049 was present on the message whose status is being checked then this MUST be the

1050Receiver from that message. All PartyId elements present in the Receiver element SHOULD be included in this To element.

…

119410.2.1.1 Sending Message Behavior

…

1199 b) a RoutingHeader element that identifies the sender and the receiver as described in Section 8.5.1, Routing Header Element

…

120810.2.1.2 Receiving Message Behavior

…

1230 i) Create a RoutingHeader element that identifies the sender and the receiver as described in Section 8.5.1, Routing Header Element

…

131110.2.2.1 Multi-hop Reliable Messaging without Intermediate Acknowledgments

…

1334 b) a RoutingHeader element that contains aSender describing the message sender (e.g. the identifiers for

1335 Party A and location of their MSH) and the Receiver of the next recipient of the message (e.g. the identifiers

1336for Party B and location of their MSH)

…

1343 b) add a RoutingHeader element to the RoutingHeaderList that contains a Sender

1344describing the message sender (e.g. the identifiers for Party C or Party D and location of their MSH)

1345 and the Receiver of the next recipient of the message (e.g. the identifiers for Party B or Party C and location of their MSH)

…

135210.2.2.2 Multi-hop Reliable Messaging with Intermediate Acknowledgments

…

1378 a) If the MSH can identify itself as the Receiver in the RoutingHeader for the hop, and

…

1383 ii) The From element contains the Receiver’s PartyId elementsfrom the last RoutingHeader in the

1384 message that has just been received

1385 iii) The To element contains the Sender’s PartyId elementsfrom the last RoutingHeader in the

1386 message that has just been received

…

1392 vii) a RoutingHeader element that contains the Sender describing the message sender (e.g. the identifiers

1393 for Party C or Party B and location of their MSH) and the Receiver of the next recipient of the

1394 message (e.g. the identifiers for Party B or Party C and location of their MSH)

…

163111.4 Identifying the Error Reporting Location

…

1636by value, for example by using the ErrorLocationcontained within the RoutingHeader

1637 element.

1638 If a message contains an ErrorLocation, the ErrorLocationMUST be used.

1639 If an ErrorLocationis not used then the ErrorLocationimplied by the CPA identified by the CpaIdDon the

1640 message SHOULD be used. If no ErrorLocationis implied by the CPA, then the Sender MUST be

1641 used.

…

2034A.1 Schema Definition

…

2104<xsd:element nameref="From" type="PartyList"/>

2105<xsd:element nameref="To" type="PartyList"/>

…

2121<xsd:element name="To">

2122<xsd:complexType>

2123<xsd:simpleContent>

2124<xsd:extension base="xsd:string">

2125<xsd:attribute name="type" type="xsd:string"/>

2126</xsd:extension>

2127</xsd:simpleContent>

2128</xsd:complexType>

2129</xsd:element>

…

2189<xsd:element nameref="Sender" type="PartyAndLocation"/>

2190<xsd:element nameref="Receiver" type="PartyAndLocation"/>

2191<xsd:element ref="ErrorLocation" minOccurs="0" maxOccurs="1"/>

…

2214<xsd:element name="Sender" type="xsd:uriReference"/>

2215

2216<xsd:element name="Receiver" type="xsd:uriReference"/>

…

2220<xsd:element name="ErrorLocation" type="xsd:uriReference" minOccurs="0" maxOccurs="1"/>

…

2290<xsd:element name="Forward" type="PartyAndLocation" minOccurs="0" maxOccurs="1"/>

…

2236<xsd:element ref="From" minOccurs="0" maxOccurs="1"/>

…

<xsd:complexType name="PartyList">

<xsd:sequence>

<xsd:element ref="PartyId" minOccurs="1" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="PartyAndLocation">

<xsd:complexContent>

<xsd:extension base="PartyList">

<xsd:sequence>

<xsd:element name="Location" type="xsd:uriReference"/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

2305<xsd:element name="PartyIdFrom">

2306 <xsd:complexType>

2307 <xsd:simpleContent>

2308 <xsd:extension base="xsd:string">

2309 <xsd:attribute name="type" type="xsd:string"/>

2310 </xsd:extension>

2311 </xsd:simpleContent>

2312 </xsd:complexType>

2313</xsd:element>

…