Comments on OTA Requirements

[Mike Rawlins <rawlins@metronet.com>]

Here are my comments (marked MCR) on the Open Travel Alliance
requirements submitted by Tim Cochran.

Again, there still seems to be some confusion about the differences
between functional requirements, non-functional requirements,
deliverables, etc.  However, what you call it in your submission is not
as important as our getting it captured and expressed somewhere in the
final document.

Mike Rawlins

---------------------------------------------------------------------------------------------

Scott Hinkelman, IBM. OTA member.

The OTA (Open Travel Alliance) is pleased to provide this initial list
of Requirements
and Considerations for ebXML.

This document lists some initial requirements and considerations for the
ebXML effort,
in order for any future potential to be realized of the Travel Industry
(meaning OTA)
endorsing and utilizing the ebXML deliverables. Much of what is outlined
is based on
current experience with work under way to define Travel industry XML
standards.

This document is not an endorsement of ebXML from OTA. The OTA does not
sanction
this list as complete or official, but only as an initial snapshot in
the 1/2000 timeframe
of considerations for ebXML. OTA may revise this list at anytime.

NonFunctional

- The OTA needs to understand the process model from ebXML concerning
fixes,
updates, turn around time, etc before considering basing the Travel
content on any
ebXML dependency.

- The OTA needs to understand the custodian and maintenance ownership
model of the
ebXML standards before considering basing the Travel content on any
ebXML
dependency.

-The OTA needs to understand the licensing model for ebXML standards
before
considering basing the Travel content on any ebXML dependency.

MCR:  You have stated these as "OTA needs to understand..."   It would
be more helpful for our requirements if you could offer your needs
regarding these items.

Functional

MCR:  These are all primarily non-functional.

- Security: The Travel industry requires a wide range of security
service quality and
function from an underlying message infrastructure. Some messages will
contain highly
sensitive personal information that will require several aspects of
security (authentication,
authorization, etc), while some messages need to flow 'in the clear',
with minimal
infrastructure, such as a 'flight availability' query which does not
need encryption,
sender-id, authentication credentials, etc.

MCR:  This expresses a requirement for allowing flexibility in
implementing levels of security.

- Security: The Travel industry requires both 'Session-based' and
'NonSession-based'
security models. Session-based generally refers to a model where the
Subject 'becomes
authenticated', and then 'sends authenticated' messages. A Session-based
model requires
the Subject (client) to hold some form of time-out token that represents
authentication
credentials. A NonSession-based model generally refers to a model where
each message
stands alone, including all information to become authenticated, and the
Subject is not
required to hold any security tokens between messages.

MCR:  Similar to Miller and Rudie comments regarding a requirement for
communications based security and static security.

- Transaction Boundary: The Travel could make use of the caller (client)
being able to
own and demarcate traditional transaction boundaries, either across
trading partner
("servers") or across a single trading partner ("server").  However, the
Travel industry
requires a model that facilitates a "verify and <action>" model that
does not require the
client to explicitly own any transaction demarcations. It would seem
logical that a
common infrastructure should supply this form of verb-model for use
across many
industries.

MCR:  I'm not sure that I understand this requirement.  Perhaps we need
to discuss this more in Orlando, or you could expound a bit more on this
on the listserv.

- Grammar: The Travel industry requires consistency in noun<->verb,
verb<->noun
utilization across all grammar.

MCR:  A detailed requirement on the ebXML guidelines.

- Grammar: The Travel industry requires avoidance of the use of synonyms

such as "new" and "create" within the grammar.

MCR:  A detailed requirement on the ebXML guidelines.

- Underlying Standards: The Travel industry would recommend avoiding all
underlying
XML standards until ratified by appropriate bodies.

MCR:  A very good point which I think we have all talked about, but
haven't stated explicitly.  I see this as a basic requirement on the
ebXML guidelines that they depend only on standards or recommendations
approved by the appropriate bodies.

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/