Re: [ebxml-mktg-sc] For Friday: Revised Messaging Assessment WP attached

[Alan Kotok <akotok@disa.org>]

David, et al.

Do we want to discuss the RosettaNet Implementation Framework in the 
paper?  While ostensibly a single-industry standard, the RosettaNet people 
are strongly promoting it to other industries, and UCC has paid for 
Drummond Group interop tests like those done with ebXML. Following is the 
section I wrote up about RNIF for my latest book project.

For e-mail/SMTP, there is an AS1 spec comparable to AS2 for HTTP, although 
with much less traction than AS2 (no Wal-Mart to give it a boost).  But it 
may be worth a mention, just so no says you missed it.

Alan Kotok
Editor, < E-Business*Standards*Today />
http://www.disa.org/dailywire/
Data Interchange Standards Association
akotok@disa.org
+1 703-518-4174

=========================

C6.06[2]        RosettaNet Implementation Framework

An early XML vocabulary that combined business process analysis with supply 
chain integration is RosettaNet.  This consortium, centered on the computer 
technology industry, has become a model for other industries and as a 
result its influence is felt well beyond its industry boundaries.

RosettaNet, begun in 1998, has some 400 members in the information 
technology industry, broadly defined to include computer manufacturers, 
chip and circuit manufacturers, software developers, and distributors of 
products in the industry.  The consortium seeks to develop a common 
language, thus taking its name from the Rosetta Stone written in 196 BC and 
discovered in Egypt in 1799 that helped comprehend for the first time the 
hieroglyphics of ancient Egypt.

In April 1999, less than a year after its founding, RosettaNet released its 
first Partner Interface Processes or PIPs, which are specifications for 
business process alignment.  RosettaNet carried out extensive process 
modeling to find out how companies in the supply chain interacted with each 
other to carry out their normal business activities.

RosettaNet builds its specifications around the PIPs, which define the 
business processes, identify the trading partners involved in the 
processes, and the messages that flow among the trading partners to support 
those processes.  The RosettaNet Implementation Framework or RNIF provides 
the infrastructure for moving the messages in support of the PIPs, as well 
as providing acknowledgements for the messages, security, and a basic 
trading partner agreement.  This chapter discusses the business process 
aspects of RosettaNet later.

RNIF, now in version 2.0, defines two types of messages - (1) action 
messages that carry the business documents and (2) signal messages that 
indicate success or failure of message delivery.  RosettaNet messages 
contain headers and payload, wrapped in a MIME envelope.  The headers 
contain administrative information for transport routing, while the payload 
contains the service content with either the business data of interest to 
the trading partners (in an action message) or the signal message with the 
acknowledgement.  The action message payload may also include attachments.

Action message payloads may contain data defined according to the 
RosettaNet specifications or a third-party message.  However, third-party 
content must be sanctioned in advanced by RosettaNet and agreed upon in the 
trading partner agreement.

RosettaNet messages have three types of headers:  Preamble, Delivery, and 
Service.  Preamble headers identify the RosettaNet specifications used, 
including the version. The Delivery Header identifies the sender and 
receiver of the message (using a DUNS number or other global business ID), 
and provides a date-time stamp, and tracking identifier.  RosettaNet 
designed the Delivery Header for use with trading exchanges and other 
hub-intermediaries that provide third-party messaging services for smaller 
companies.

The Service Header offers process control data giving basic information 
about the contents of the message.  The Service Header indicates if the 
message is a test or production (with real data) message, identifies the 
PIPs supported, offers a description of the contents, and indicates if the 
message includes attachments.  The Service Header can also indicate if the 
receiving party is known or unknown to the sender.  Known parties have 
active trading partner agreements in place.  The Service Header in version 
2.0 has a placeholder for quality of service elements, which RosettaNet has 
not yet implemented.

RNIF includes security specifications, in the form of Secure MIME (S/MIME) 
envelopes that provide encryption for confidentiality and digital 
signatures for message integrity, authentication, and non-repudiation.  The 
packaging specifications in RNIF allow for encrypting parts of the message, 
such as the payload only, leaving the headers sent in the clear.

As noted above, RosettaNet messages can also send signals indicating the 
extent of receipt and acceptance of the message by the trading partner.  A 
Receipt Acknowledgement indicates the message is structurally and 
syntactically valid, according to RosettaNet specifications, while 
Exceptions return an error message to the sender.  The Receipt 
Acknowledgement can include a Non-Repudiation element providing the 
equivalent of a signed receipt.

RNIF goes one step beyond acknowledgements however, with Process Control 
messages that notify the trading partners on the extent of execution of the 
message.  Version 2.0 of the RNIF defines one such signal message, 
Notification of Failure.  The specifications provide guidance for various 
scenarios of failures and retries, for both asynchronous (one-way) and 
synchronous (request-and-response) message interactions.


At 01:37 PM 4/30/03 -0400, David RR Webber - XML ebusiness wrote:
>Team,
>
>Attached the latest and greatest - 0430 version.
>
>I'd hope to get this out before todays call.  Oh well!
>
>Consequently today's call was short and brief.
>We discussed some mechanics for Monday's opening
>of the ebXML conference in London.
>
>Anyway - onward and upward.
>
>I now believe I've covered off the gripes people had with
>the first incarnation.
>
>I'd like to move forward on getting this published to our
>website Friday, and have it available next week for the
>London show to reference it.
>
>Obviously we can always do better - but I'm hoping this
>is good enough for a V1.0 release - and that we can
>pass it on to willing hands to enhance and improve
>in due course.
>
>Opinions?  Nits?  Last minute edits/omissions ?
>
>Thoughts?
>
>If we can close this out by Friday mid-day EST, then I
>can pass along the release copy to Carol and Dee then,
>
>Thanks, DW.