Within the ebMS MessageHeader, the REQUIRED From and To elements include a PartyId element which identifies the sending or receiving party for the message. The PartyId element value is defined by the PartyId type attribute. Commonly used types are the Uniform Resource Identifier (URI) and the Uniform Resource Name (URN), however a generic string type is also allowed providing that it is understood by both parties. STAR recommends the use of the following PartyId types:

Examples:

The CPAId element is a REQUIRED ebXML element. It is a string that identifies the parameters governing the exchange of messages between the parties. The recipient of a message MUST be able to resolve the CPAId to an individual set of parameters, taking into account the sender of the message. This does NOT mean that a formal CPA conforming to the ebXML CPA specification must be in place for ebXML messaging to be used. If no formal CPA exists, the CPAId is simply the location of party specific information such as IP addresses and dealer Ids. This is a temporary format until party id formats can be established in a future versions of this publication.

For STAR, the CPAId element shall have the following format:

        <CPAId>fromPartyId-ToPartyId-cpa</CPAId>

The CPAId may also optionally contain a version number:

        <CPAId>fromPartyId-ToPartyId-cpa-x.x</CPAId>

Examples:

The REQUIRED ConversationId element is a string identifying the set of related messages that make up a conversation between two Parties. It MUST be unique within the From and To party pair. The Party initiating a conversation determines the value of the ConversationId element that SHALL be reflected in all messages pertaining to that conversation. The value for ConversationId in the STAR XML Infrastructure environment SHOULD be datestamp + timestamp + a unique host identifier; UTC format is used for datestamp. For example, if two salespeople at the same dealership submit an inquiry at the same time (obviously from separate terminals), then the algorithm to generate the ConversationId should be such that this situation would generate two separate ConversationIds.

The ConversationId enables the recipient of a message to identify the instance of an application or process that generated or handled earlier messages within a conversation. It remains constant for all messages within a conversation.

The REQUIRED Service and Action elements identify the service that acts on the message.

For STAR XML Infrastructure, the value of the type attribute of the Service element for messages that contain a STAR BOD payload MUST be “STARBOD” and the value of the Service element MUST be the STAR BOD Noun. The value of the Action element MUST be the STAR BOD Verb.

Exceptions to this include ebMS standalone error messages and asynchronous acknowledgments, whose Service Action values are defined by ebMS version 2.0.

An example of the Service and Action elements for an STAR BOD payload follows:

The REQUIRED MessageData element provides a means of uniquely identifying an ebMS message.

MessageId element

Message IDs MUST be Globally unique and conformant to ebMS specifications which require that the value is conformant to RFC2392.

STAR requires three (3) data elements within the Message ID:

The Service Name should be concatenated with a period (.) followed by the GUID, followed by an at sign (@) followed by the company name in domain name format.

Example:

Timestamp element

The REQUIRED Timestamp is a value representing the creation time of the message header and MUST be in UTC format (Universal Time Code as defined by ISO 8601).

A STAR ebMS Message can be digitally signed to provide security countermeasures. Application of Digital Signature is a Recommendation, in other words, conformant implementations should be capable of processing messages with Digital Signature, but individual implementations may choose not to use Digital Signature features.

The Manifest is a composite element that summarizes message payloads. A Manifest element MUST be present if one or more Payloads exist, and all Payloads MUST be referenced in the Manifest. The purpose of the Manifest is:

The structure and content of the Manifest element MUST conform to the ebMS version 2.0 specifications.

The Acknowledgment element is used by the To Party that received a message, to let the From Party that sent the message know the message was received. The RefToMessageId in a message containing an Acknowledgment element identifies the message for which the receipt is being generated. The RefToMessageId is the MessageId of the original message.