Extending To/From, *URI for improved identification
advertisement
… 493 8.4.1 From and To elements 494 The From element identifies the Party that originated the message. The From element consists 495 of one or more PartyId 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 one or more PartyId 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, 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]. 503 Otherwise the receiving MSH MUST report an error (see section 8.8) with errorCode set to Inconsistent and severity set to 504 Error. 505 The following fragment demonstrates usage of the From and To elements. The first illustrates a 506 pair of user-defined numbering schemes; the second, a single URN. 507 508 <From> 509 <PartyId type="DUNS">006998397</PartyId> <PartyId type="SCAC">RDWY</PartyId> 510 </From> 511 <To> 512 <PartyId>urn:dnb.com:duns:321098765-4321</PartyId> 513 </To> … 662 8.4.10 Header sample … 667 668 669 670 671 672 <From> <PartyId>...</PartyId> </From> <To> <PartyId>...</PartyId> </To> … 691 8.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 Sender 699 Receiver 700 ErrorLocation Timestamp SequenceNumber #wildcard 8.5.1.1 Sender 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 URL of the message's Sender Messaging Service Handler. The 706 recipient of the message, unless there is another URL more specifically identified within the CPA, 707 uses the URL 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. 711 8.5.1.2 Receiver 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 712 element contains the URL of the Receiver’s Messaging Service Handler URL. It is the URL to 713 which the Sender sends the message. 714 8.5.1.3 ErrorLocation element 715 This URL, if present, identifies the URL 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 Sender 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.) … 701 702 703 704 734 8.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 <Sender><Location>http://PartyA.com/PartyAMsh</Location> <PartyId>urn:myscheme.com:id:PartyA-id</PartyId></Sender> 754 <Receiver><Location>http://PartyB.com/PartyBMsh</Location> <PartyId>urn:myscheme.com:id:PartyB-id</PartyId></Receiver> … 760 <From><PartyId>urn:myscheme.com:id:PartyB-id</PartyId></From> 761 <To><PartyId>urn:myscheme.com:id:PartyA-id</PartyId></To> … 773 <Sender><Location>http://PartyB.com/PartyBMsh</Location> <PartyId>urn:myscheme.com:id:PartyB-id</PartyId></Sender> 774 <Receiver><Location>http://PartyA.com/PartyAMsh</Location> <PartyId>urn:myscheme.com:id:PartyA-id</PartyId></Receiver> … 778 8.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 <Sender><Location>http://PartyA.com/PartyAMsh</Location> <PartyId>urn:myscheme.com:id:PartyA-id</PartyId></Sender> 799 <Receiver><Location>http://PartyB.com/PartyBMsh</Location> <PartyId>urn:myscheme.com:id:PartyB-id</PartyId></Receiver> … 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>http://PartyA.com/PartyAMsh</Location> <PartyId>urn:myscheme.com:id:PartyA-id</PartyId></Sender> 818 <ReceiverURI><Location>http://PartyB.com/PartyBMsh</Location> <PartyId>urn:myscheme.com:id:PartyB-id</PartyId></Receiver> … 822 <Sender><Location>http://PartyB.com/PartyAMsh</Location> <PartyId>urn:myscheme.com:id:PartyB-id</PartyId></Sender> 823 <Receiver><Location>http://PartyC.com/PartyBMsh</Location> <PartyId>urn:myscheme.com:id:PartyC-id</PartyId></Receiver> … 852 8.7 StatusData Element … 861 a Forward element. This MUST only be present if messageStatus is set to 862 Forwarded. If present it indicates the Receiver to which the message was 863 forwarded. This element has the same composition as the Sender and Receiver elements. … 979 8.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. … … … 1037 9.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 1050 Receiver from that message. All PartyId elements present in the Receiver element SHOULD be included in this To element. … 1194 10.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 … 1208 10.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 … 1311 10.2.2.1 Multi-hop Reliable Messaging without Intermediate Acknowledgments … 1334 b) a RoutingHeader element that contains a Sender 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 1336 for Party B and location of their MSH) … 1343 b) add a RoutingHeader element to the RoutingHeaderList that contains a Sender 1344 describing 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) … 1352 10.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 elements from the last RoutingHeader in the 1384 message that has just been received 1385 iii) The To element contains the Sender’s PartyId elements from 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) … 1631 11.4 Identifying the Error Reporting Location … by value, for example by using the ErrorLocation contained within the RoutingHeader element. If a message contains an ErrorLocation, the ErrorLocation MUST be used. If an ErrorLocation is not used then the ErrorLocation implied by the CPA identified by the CpaId on the 1640 message SHOULD be used. If no ErrorLocation is implied by the CPA, then the Sender MUST be 1641 used. … 1636 1637 1638 1639 2034 A.1 Schema Definition … 2104 <xsd:element name="From" type="PartyList"/> 2105 <xsd:element name="To" type="PartyList"/> … 2121 2122 2123 2124 2125 2126 2127 2128 2129 … 2189 2190 2191 … 2214 2215 2216 <xsd:element name="To"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="type" type="xsd:string"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> <xsd:element name="Sender" type="PartyAndLocation"/> <xsd:element name="Receiver" type="PartyAndLocation"/> <xsd:element ref="ErrorLocation" minOccurs="0" maxOccurs="1"/> … 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: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 2306 2307 2308 2309 2310 2311 2312 2313 … <xsd:element name="PartyIdFrom"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="type" type="xsd:string"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>
