Subject: XML Messaging Draft Charter

From: "Marchewka, Andrew" <[email-masked]>
Date: Fri, 25 Jun 1999 09:09:00 -0400

Dave,
     
        Attached is some info about another use of XML ... for smart card 
     application development...
     
     Andrew Marchewka
     
     CIBC
     
     ======================================
     
     Dear DML subscribers
     
     To stimulate your smart card neurons, I thought I'd open a discussion 
     thread on today's press release on SmartX Framework 
     (http://biz.yahoo.com/bw/990621/ca_gemplus_1.html).  I've heard good 
     things about it and based on the comments of IBM, Sun and Microsoft, 
     they seem to agree.  Its my understanding that this technology allows 
     developers to work on the business/application issues and use XML 
     libraries for the card specific details (MPCOS, ME2000, JavaCard, 
     Smart Card for Windows, TB100, etc.).
     
     I believe application developers, especially those entering the 
     industry from the personal computer industry, will embrace this 
     technology as it allows them to focus on the application development 
     instead of the card operating system.
     
     What do you think?

     I've posted part of the press release below and if you really want to 
     study what SmartX is, go to http://www.smartxml.com for a tutorial and 
     FAQ.
     
     SmartX separates application development from the complexity of smart 
     card device management, a breakthrough that for the first time allows 
     easy implementation of the same application on different types or 
     generations of smart card. Based on the eXtensible Markup Language 
     (XML) standard, smartX allows developers to write smart card 
     applications independent of manufacturer-specific card management 
     protocols, essentially enabling them to write ``virtual smart card 
     objects'' that are platform (card and terminal) independent.

     Charles Cagliostro
     SCIA Board

______________________________ 
Forward Header 
__________________________________
Subject: XML Messaging Draft Charter
Author:  "[email-masked]" 
[SMTP:[email-masked]] at 
NA01
Date:    24/06/99 7:18 PM

In the last IETF meeting, in 
Minneapolis, I gave a presentation on 
"XML Messaging" which suggested 
extracting from IOTP the ideas it 
contained on handling messages so 
that they could form a separate 
standard that would have wider 
applicability. During the meeting 
this was thought a good idea.

The attached HTML document (and plain 
text below) contain an *initial* 
draft for a charter for an XML 
Messaging working group that might be 
formed to develop the standard. 
Please note that:
*     it IS a draft - comments ARE 
welcome
*     I do not presume that a working 
group will be formed - that is the 
decision of the IESG

However I would like to start 
informal discussion on the idea. So 
any comments are really welcome, 
particularly from groups, not 
necessarily within the IETF, that 
might make use of XML Messaging. It 
is important that the requirements of 
a good cross-section of potential 
users of XML messaging are included 
in this work.

I also suggest, with the chair's 
permission, that ideas on what to do 
in the area of "XML Messaging" is 
discussed during the Trade WG 
meetiing at the next IETF meeting in 
Oslo on July 14.

Regards

David Burdett

Draft charter as HTML ...
<<XML Messaging Charter - draft.htm>>

... and as text ...
==================================== 
XML MESSAGING (XMLMSG)
     
Chair(s):
     
[TBD]
     
[Applications/Transport] Area Director(s):
     
TBD
     
[This potentially could be either the Applications Area or Transport Area or

joint in both areas.]
     
Area Advisor:
     
[TBD]
     
Mailing Lists:
     
General Discussions: ietf-xmlmsg@xxx 
To Subscribe: [TBD]
Archive: [TBD]
     
Description of Working Group:
     
Purpose
     
The Extensible Mark-Up Language (XML) (see 
http://www.w3.org/TR/1998/REC-xml-19980210) is becoming popular as the basis

for Internet protocols such as IOTP and RosettaNet. Other existing protocols

also state an intention to migrate to XML such as OFX and FSML. [please 
suggest other appropriate standards]
     
Many of these protocols have common requirements which are independent of 
the purpose of the protocols, the information they are carrying or the 
processes that these protocols initiate and control.
     
The purpose of the XMLMSG working group is to develop standard approaches to

common requirements for these protocols so that solutions may benefit from 
re-usability of software components and enhanced interoperability.
     
The list of requirements is described below under three headings: 
1)     Common XML Message Elements
2)     Document Exchange Architecture 
3)     Common Document Exchanges
     
Common XML Message Elements
     
The following are to be considered as common XML Message elements:
1) Standard Message Header. These elements will identify, describe and 
classify the XML documents that make up the messages in the protocol 
2) Packaged Data. An XML element that can be used to encapsulate any
arbitrary data, for example binary data, or other XML documents, inside an 
XML document
3) Message Error Data. These elements specify the nature and position of 
errors found in an XML document that has been received
4) Signature Data. These elements apply digital signatures to the data in 
the message. The intention is that this will use the results of the joint 
W3C/IETF XMLDSIG working group
5) Status Data. These elements describe the success or failure of a process 
which the protocol is used to initiate.
6) XML Message Structure. This element will describe how the other Common 
XML Message elements can be combined to form a basic XML document for a 
protocol message that can be used to "wrap" data which is domain specific.
     
The intention is not to duplicate the effort of others.  For example, if W3C

standardizes the packaging of arbitrary data, then this working group would 
use the results of their work.
     
Document Exchange Architecture
     
This will define how to use the Common XML Message Elements to exchange 
documents between the parties involved in the protocol. Specifically the 
following areas will be considered.
1) Simple Document Exchange. This will describe how to carry out a Document 
Exchange consisting of Request Messages and Response Messages that:
     a) Initiate a process on a remote system. This will describe how to
use a message that conforms to the XML Message Structure to request the 
initiation of a process at a remote location, and
     b) Receive the results of a process. This will describe how to
construct a message using the XML Message Structure that responds to the 
request and describes the success, or failure, of the process
2) Combining Document Exchanges. This will describe how to combine two or 
more Simple Document Exchanges between two or more organizations into higher

level processes for greater functionality
3) Process Authorization. This will describe how to determine if the XML 
document that forms a request message is authorized and therefore the 
requested document exchange should be carried out, particularly when 
authorization is dependent on the successful completion of an earlier 
document exchange
4) Problem Reporting. How to report errors found in messages so that the 
problems in systems that caused the error can be resolved
5) Idempotency. This will describe standard approaches towards handling 
duplicate messages and data that has been received.
6) Restarts and Recovery. If a document exchange fails this will describe 
standard approaches towards recovering from the failure.
     
Common Document Exchanges
     
These are common Document Exchanges that use  the Document Exchange 
structure described above to implement commonly used functionality:
1) Process Inquiry. This will describe a Document Exchange that can be used 
to inquire on the current status of any other process that is supported by a

protocol based on XML Messaging.
2) Ping Transaction. This will describe a Document Exchange that can be used

to determine if the servers and systems that are supporting a protocol based

on XML Messaging are available and functioning.
3) Authentication. This will describe a Document Exchange that can be used 
to discover information about and authenticate another system or user of the

protocol.
     
Development Approach
     
Three documents are to be developed that correspond to each of the three 
groupings above.  While some work will proceed in parallel on all three 
groups, they are expected to be advanced for standardization in the order 
listed above
     
Goals and Milestones:
     
To be completed.

****************************************************************************
****
**************
     
This Email and any attached files are confidential and may also be
privileged. 
If you are not the intended recipient, please notify the postmaster using
email 
address [email-masked] or call +44 171 557 5000 and ask for the
IT Helpdesk.  You should not copy this email and any attached files, use
them 
for any purpose or disclose the contents to any other person; all copies of
the 
Email and associated files in your possession should be destroyed.
     
Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England
     
Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com
     
****************************************************************************
****
*************

---

From: [email-masked]
Date: Fri, 25 Jun 1999 20:27:24 +0100

Andrew

Thanks for providing the information. I've had a quick look at SML (smartX
Markup Language) and what it seems to be is a way for applications running
on a system to send messages created using XML to a smart card driver
without having to understand the machine/operating system specific APIs to
use.

I don't think it's addressing the same area as XML Messaging which focusses
primarily on how two (or more) systems attached to the internet can invoke
(and manage, respond to, etc.) processes remotely using XML messages.

Thanks

David

> ----------
> From: 	Marchewka, Andrew[SMTP:[email-masked]]
> Sent: 	25 June 1999 06:09
> To: 	[email-masked]
> <<File: XMLMESSA.HTM>>

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]