OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

Messages By Date: members message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Proposed Charter for OASIS Identity Metasystem Interoperability (IMI) TC


To OASIS Members:

  A draft TC charter has been submitted to establish the OASIS Identity
Metasystem Interoperability (IMI) Technical Committee. In accordance with the
OASIS TC Process Policy section 2.2: 
(http://www.oasis-open.org/committees/process-2008-02-05.php#formation) the
proposed charter is hereby submitted for comment. The comment period shall
remain open until 11:45 pm ET on 7 August 2008. 

  OASIS maintains a mailing list for the purpose of submitting comments on
proposed charters. Any OASIS member may post to this list by sending email to:
mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly
archived at: 
http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to
receive emails must join the group by selecting "join group" on the group home
page:
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees
of organizational members do not require primary representative approval to
subscribe to the oasis-charter-discuss e-mail.

  A telephone conference will be held among the Convener, the OASIS TC
Administrator, and those proposers who wish to attend within four days of the
close of the comment period. The announcement and call-in information will be
noted on the OASIS Charter Discuss Group Calendar.

  We encourage member comment and ask that you note the name of the proposed TC
(IMI) in the subject line of your email message. 

Regards,

Mary
 
---------------------------------------------------
Mary P McRae
Manager of TC Administration, OASIS
email: mary.mcrae@oasis-open.org  
web: www.oasis-open.org
phone: 603.232.9090
 

===========
PROPOSED CHARTER FOR REVIEW AND COMMENT
OASIS Identity Metasystem Interoperability (IMI) Technical Committee 

1) The Charter of the TC, which includes only the following items: 
(1)(a) The name of the TC

OASIS Identity Metasystem Interoperability (IMI) Technical Committee

 (1)(b) A statement of purpose, including a definition of the problem to be
solved. 

The purpose of the Identity Metasystem Interoperability (IMI) Technical
Committee (TC) is to increase the quality and number of interoperable
implementations of Information Cards and associated identity system components
to enable the Identity Metasystem. In the Identity Metasystem, identities are
represented to users as "Information Cards." Information Cards enable users to
manage their digital identities from different identity providers and employ
them in various contexts to access online services. Information Cards have a
number of characteristics that help to improve user privacy and security when
accessing online services. Broad interoperability across platforms and services
is needed so that Information Card support is ubiquitous to realize the goals of
the Identity Metasystem.

(1)(c) The scope of the work of the TC.

The TC will accept as input the July 2008 Identity Selector Interoperability
Profile specification [1] and associated guides [2] [3] as published by
Microsoft, the July 2008 Web Services Addressing Endpoint References and
Identity specification [4] published by Microsoft and IBM, and the OSIS (Open
Source Identity Systems) Feature Tests [5] published by Identity Commons (the
Input documents).

Other contributions and changes to the input documents will be accepted for
consideration without any prejudice or restrictions and evaluated based on
technical merit insofar as they conform to this charter. OASIS members with
extensive experience and knowledge in these areas are particularly invited to
participate.
The following sub-sections describe the charter of the Identity Metasystem
Interoperability (IMI) TC with respect to these areas. The scope of the TC's
work is to continue further refinement and finalization of the Input Documents
to produce specifications that standardize the concepts and XML Schema
renderings of the areas described below in a form that is backward compatible
with the input documents.

---- First Phase of TC Work
The TC shall focus its initial activity on producing an Identity Selector
Interoperability Profile and the supporting WS-Addressing Endpoint References
and Identity specification. This is to be done in parallel with work on
interoperability testing described in Ongoing Work below. Upon publication of
the initial work, which is required to promote the interoperability testing
work, the TC shall begin its second phase work below.

---- Identity Selector Interoperability Profile
This profile defines an interoperable Information Card format and associated
identity system components that allow users to manage their digital identities
from different identity providers, and employ them in various contexts to access
online services.

---- Information Card Format

An Information Card represents a digital identity of a subject that can be
issued by an identity provider. It is an artifact containing metadata that
represents the token issuance relationship between an identity provider and a
subject, and provides a visual representation of the digital identity. Multiple
digital identities for a subject from the same identity provider are represented
by multiple and different Information Cards. Subjects may obtain an Information
Card from an identity provider, and may have a collection of Information Cards
from various identity providers. A user controls her Information Cards through a
software interface referred to as an Identity Selector.

Information Cards contain the following information:

* A language identifier to describe which language localizable elements have
been localized.
* A reference identifier to provide a specific reference for a card by which it
can be uniquely identified within the scope of an issuer
* A card name that is a friendly textual name for an issued Information Card.
* An image element that contains a base64 encoded inline image that provides a
graphical image for the issued Information Card, including MIME type information
for the type of image format.
* An issuer element that provides a logical name for the issuer of the
Information Card.
* Elements to indicate when an Information Card was issued and when it expires.
* An element to specify an identity provider's supported token services as a
list. This is an ordered list of Identity Provider (IP) / Security Token Service
(STS) endpoints, and the corresponding credential type to be used, for
requesting tokens. For each endpoint, the required credential type implicitly
determines the authentication mechanism to be used. Each IP/STS endpoint
reference in the Information Card includes the security policy metadata for that
endpoint.
* An element to specify an identity provider's supported token types as a list. 
* An element to provide information that identifies the relying party where
issued tokens for the Information Card will be used.
* An element to describe the supported claim types offered including display and
description information about the claim type. 
* An element to indicate the location and version of the privacy statement of
the identity provider.
* Extensibility points to support future enhancements to the Information Card
format.

---- Information Card Transfer Format

This profile will define how collections of Information Cards are transferred
between identity selectors. Rules are also defined that cover the portability of
content in Information Cards through the use of defined extensibility points.

---- Information Card Issuance

In order to provide the assurance that an Information Card is indeed issued by
the identity provider expected by the user, the Information Card must be carried
inside a digitally signed envelope that is signed by the identity provider. The
signature on the digitally signed envelope provides data origin authentication
assuring the user that it came from the right identity provider. The
specification will describe a specific profile of XML Digital Signatures [6]
that must be used to sign the envelope carrying the Information Card. An
identity selector must verify the enveloping signature. The Information Card can
then be extracted and stored in the Information Card collection.

---- Token Request and Response

For any given Information Card, an Identity Selector can obtain a security token
from the IP/STS for that Information Card using the "issuance binding" of
WS-Trust [7].

When requesting a security token from the IP/STS, an Identity Selector includes
the Information Card reference element, and all of its content, in the body of
the Request Security Token (RST) message as a top-level element. Generally an
Identity Selector should not send token scope information to an identity
provider to protect user privacy. When scope information is required by the
identity provider this profile defines rules for the behavior of the identity
selector. The profile also defines rules for use of client pseudonyms as PPIDs
and the use of proof keys for issued tokens.

This profile also defines an element that an Identity Selector may use as a top
level element in an RST to request a display token. A display token contains a
representation of the claims carried in the issued token that can be displayed
in a user interface.

---- Identity Provider Requirements

The Information Card schema includes the element content necessary for an
identity provider to express what credential the user must use in order to
authenticate to the IP/STS when requesting tokens. These include, but are not
limited to, Username/Password, Kerberos, X.509 (WSS Security Token Profiles [8])
and self issued tokens (see below).

Identity Providers must make their security policy available at a URL using the
HTTPS scheme. An Identity Selector may retrieve this policy using the mechanisms
defined in WS-MetadataExchange [9].

A policy assertion is defined to indicate that Information Cards, representing
identities that may be federated, must be pre-provisioned before token requests
can be made of the identity provider. This assertion is used in the IP/STS
policy metadata.

This profile also defines SOAP faults for use in error situations by an Identity
Provider.

---- Relying Party Requirements

A relying party specifies its security token requirements as part of its
security policy using the primitives and assertions defined in WS-SecurityPolicy
[10]. The claims requirement of a relying party can be expressed in its token
policy by using the optional Claims parameter defined in WS-Trust. However, the
Claims parameter has an open content model. This profile defines the ClaimType
element for use as a child of the Claims element.

This profile also defines SOAP faults for use in error situations by a Relying
Party.

---- Self Issued Identity Provider

The profile defines a simple identity provider, called the "Self Issued Identity
Provider" (SIP). This is an identity provider which allows users to self assert
identity in the form of self issued tokens. An identity selector may include a
co-resident self issued identity provider that conforms to the Simple Identity
Provider Profile. This profile allows self issued identities created within one
identity selector to be used in another identity selector such that users do not
have to re-register at a relying party when switching identity selectors. This
profile defines the characteristics and behaviors of Self Issued Identity
Providers and self issued tokens. 

---- Invoking Identity Selectors from Web Pages

HTML extensions are used to signal to the browser when to invoke the Identity
Selector. However, not all HTML extensions are supported by all browsers, and
some commonly supported HTML extensions are disabled in browser high security
configurations. For example, while the OBJECT tag is widely supported, it is
also disabled by high security settings on some browsers. An alternative is to
use an XHTML syntax . However, not all browsers provide full support for XHTML.
Two HTML extension formats are specified, the OBJECT tag and XHTML. Both share
the same set of optional parameters:
* issuer: the URL of the STS from which to obtain a token. 
* issuerPolicy, the URL of an endpoint from which the STS's WS-SecurityPolicy
can be retrieved using WS-MetadataExchange.  This endpoint must use HTTPS.
* tokenType: specifies the type of the token to be requested from the STS as a
URI. This parameter can be omitted if the STS and the web site front-end have a
mutual understanding about what token type will be provided or if the web site
is willing to accept any token type.
* requiredClaims: specifies the types of claims that must be supplied by the
identity. If omitted, there are no required claims. 
* optionalClaims: specifies the types of optional claims that may be supplied by
the identity. If omitted, there are no optional claims. 
* privacyUrl: specifies the URL of the human-readable privacy policy of the
site, if provided.
* privacyVersion: specifies the privacy policy version. This must be a value
greater than 0 if a privacyUrl is specified. If this value changes, the Identity
Selector UI notifies the user and allows them review the change to the privacy
policy.
The data types of these parameters are also defined for use with scripting.

---- WS-Addressing Endpoint References and Identity 

This specification provides a mechanism to describe security-verifiable identity
for endpoints by leveraging extensibility of the WS-Addressing [11]
specification. 

An element is defined for representing identity (as nested elements) that can be
provided as part of a WS-Addressing Endpoint Reference. Elements are defined to
identity claims for DNS name, Service Principal Name, User Principal Name and
Key Info.

These mechanisms enable messaging systems to support multiple trust models
across networks that include processing nodes such as endpoint managers,
firewalls, and gateways in a transport-neutral manner. These elements are used
within Identity Metasystem components but are also of broader applicability.

---- Second Phase of TC Work

The claim types defined in phase one must work with the Information Card format
but should also compose with other claim type dialects, e.g. the common claims
dialect defined in WS-Federation [12]. The TC will need to investigate
integrating other claim dialects into the Information Card model. The TC may
also look into issues around using specific sources of data, e.g.  LDAP or other
network level information, as claims.

The TC may also work on enhancements to the object tag described above, e.g. to
improve the display of Information Cards on web sites.

The TC may also work on improving how Information Cards can be used across a
number of different devices, or roamed, beyond the export format defined above.
This may require utilizing extensibility points in the protocols already in use
or potentially new protocols.

Utilizing the Trust 1.4 challenge/negation features and profiling schema for
specific tokens used with Information Cards are also areas of interest for the
second phase of TC work.

---- Ongoing TC Work

The TC shall focus on interoperability test definitions and runs to validate its
work on an ongoing basis. The TC will determine the feature areas to test and
the specific interoperability scenarios. Initially this work shall focus on the
first phase deliverables defined above. The TC is encouraged to use the OSIS
Feature Tests as a basis for this work. When the TC begins its second phase of
work new tests will need to be defined to support it.

The TC shall also consider and assist in the work of other related OASIS TCs on
an ongoing basis as agreed by the TC membership, e.g. assisting in the SAML
Information Card Profile [13] definition and ensuring that the IMI work composes
properly.

 ---- General Notes on Scope
The output specifications will uphold the basic principles of other Web services
specifications of independence and composition and be composable with the other
specifications in the Web services architecture, such as the specifications
listed in the References section. 
Each of the protocol elements will use implementation and language neutral XML
formats defined in XML Schema [14].

The following is a non-exhaustive list. It is provided only for the sake of
clarity. If some function, mechanism or feature is not mentioned here, and it is
not mentioned in the Scope of Work section either, then it will be deemed to be
out of scope.

The TC will not define a mapping of the functions and elements described in the
specifications to any programming language, to any particular messaging
middleware, nor to specific network transports.

----- Out of Scope
   
The following items are specifically out of scope of the work of the TC:

1. Definition of the form and content of privacy statements.
2. The establishment of trust between two or more business parties. 
3. Definition of new key derivation algorithms.
4. Definition of claim type transformation rules or mappings to other formats

The TC will not attempt to define concepts or renderings for functions that are
of wider applicability including but not limited to:
- Addressing
- Policy language frameworks and attachment mechanisms
- Reliable message exchange
- Transactions and compensation
- Secure Conversations
- Metadata Exchange
- Resource Transfer

Where required these functions are achieved by composition with other Web
services specifications. 

The TC will not attempt to define functionality duplicating that of any
normatively referenced specification in the input specifications.

(1)(d) A list of deliverables, with projected completion dates.

   The TC has the following set of deliverables:

* A revised Identity Selector Interoperability Profile v1.6 set of
specifications and associated Schemas. A Committee Specification is scheduled
for completion within 12 months of the first TC meeting.

* A revised Web Services Addressing Endpoint References and Identity
specification and associated Schemas. A Committee Specification is scheduled for
completion within 12 months of the first TC meeting.

* Any Interoperability Guides expected in 18 months from the first TC meeting. 

These specifications will reflect refinements, corrections or material
technological improvements with respect to the input documents and in accordance
with this charter.

Ratification of the above specifications as OASIS standards, including a brief
period to address any errata will mark the end of the TC's lifecycle. The TC may
decide to recharter when complete to continue maintenance activities on an
ongoing basis rather than permanently disband.

---------- References---------------
[1] Identity Selector Interoperability Profile V1.5, July 2008
http://schemas.xmlsoap.org/ws/2005/05/identity

[2] A Guide to Using the Identity Selector Interoperability Profile V1.5 within
Web Applications and Browsers, July 2008
http://schemas.xmlsoap.org/ws/2005/05/identity

[3] An Implementer?s Guide to the Identity Selector Interoperability Profile
V1.5, July 2008
http://schemas.xmlsoap.org/ws/2005/05/identity

[4] Application Note: Web Services Addressing Endpoint References and Identity,
July 2008
http://schemas.xmlsoap.org/ws/2006/02/addressingidentity 

[5] OSIS (Open Source Identity Systems) Feature Tests
http://osis.idcommons.net/wiki/Category:I4_FeatureTests

[6] XML-Signature Syntax and Processing, W3C Recommendation, 2002
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ 

[7] WS-Trust 1.3, OASIS Standard, March 2007
http://docs.oasis-open.org/ws-sx/ws-trust/200512

WS-Trust 1.4, OASIS Committee Draft, June 2008
http://docs.oasis-open.org/ws-sx/ws-trust/200802

[8] OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004),
OASIS Standard, March 2004
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.
0.pdf 

OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004), OASIS
Standard, February 2006.
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMes
sageSecurity.pdf 

Web Services Security: UsernameToken Profile, OASIS Standard, March 2004
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1
.0.pdf

Web Services Security: UsernameToken Profile 1.1, OASIS Standard, February 2006
http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-Usernam
eTokenProfile.pdf

Web Services Security X.509 Certificate Token Profile, OASIS Standard, March
2004
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.p
df 

Web Services Security X.509 Certificate Token Profile, OASIS Standard, February
2006
http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-
x509TokenProfile.pdf 

Web Services Security Kerberos Token Profile 1.1, OASIS Standard, February 2006
http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-Kerbero
sTokenProfile.pdf 

Web Services Security: SAML Token Profile, OASIS Standard, December 2004
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf 

Web Services Security: SAML Token Profile 1.1, OASIS Standard, February 2006
http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTok
enProfile.pdf 

Web Services Security Rights Expression Language (REL) Token Profile, OASIS
Standard, December 2004
http://docs.oasis-open.org/wss/oasis-wss-rel-token-profile-1.0.pdf 

Web Services Security Rights Expression Language (REL) Token Profile 1.1, OASIS
Standard, February 2006
http://www.oasis-open.org/committees/download.php/16687/oasis-wss-rel-token-prof
ile-1.1.pdf 

[9] Web Services Metadata Exchange (WS-MetadataExchange), Version 1.1, August
2006
http://specs.xmlsoap.org/ws/2004/09/mex

[10] WS-SecurityPolicy 1.2, OASIS Standard, December 2006
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512

WS-SecurityPolicy 1.3, OASIS Committee Draft, June 2007
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/

[11] "Web Services Addressing (WS-Addressing)", W3C Recommendation May 2006
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509 

[12] WS-Federation, OASIS Committee Draft, June 2008
http://docs.oasis-open.org/wsfed/federation/200706 

[13] SAML Information Card Profile, Editor Draft
http://www.oasis-open.org/committees/download.php/28626/draft-sstc-saml2-infocar
d-01.pdf 

[14] XML Schema Part 1: Structures Second Edition, W3C Recommendation, October
2004
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ 

XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, October 2004
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

(1)(e) Specification of the IPR Mode under which the TC will operate.
      
This TC will operate under the "RF (Royalty Free) on RAND Terms" IPR mode as
defined in the OASIS Intellectual Property Rights (IPR) Policy, effective 15
April 2005. 

(1)(f) The anticipated audience or users of the work.

The anticipated audience for this work includes:
* Vendors offering Web services products
* Telecom providers with identity enabled communication enabled telecom services
* Other specification authors that need identity capabilities for Web  services
* Software architects and programmers, who design, write or integrate
applications for Web services
* End users implementing Web services-based solutions that require identity
based mechanisms.  

(1)(g) The language in which the TC shall conduct business.

    This TC will use English as the language for conducting its operations.

(2) Non-normative information regarding the startup of the TC: 
(2)(a) Identification of similar or applicable work that is being done in other
OASIS TCs or by other organizations, why there is a need for another effort in
this area and how this proposed TC will be different, and what level of liaison
will be pursued with these other organizations.

The IMI TC will be performing new work activities that are currently not covered
by any other OASIS TC.

The TC co-chairs will coordinate closely with other bodies in order to inform
them about the progress of the work and also in order to count on their
expertise in the development of the work.

------------ Related Work

Similar Work:
The specifications developed by the IMI TC address functionality required for
user centric identity that is not addressed in other security related
activities. The IMI TC will be informed by the following:

* OSIS
http://osis.idcommons.net/wiki/Main_Page 
Many identity related projects that are both open-source and commercial use this
forum for defining tests and identifying public forums to demonstrate
interoperability, particularly around Information Cards.
* OpenID
http://openid.net/ 
OpenID is a decentralized framework for a shared identity service to allow
Internet users to log on to many different web sites using a single digital
identity.
* Concordia
http://projectconcordia.org/ 
Project Concordia is an initiative designed to drive interoperability across
identity protocols in use today.
* Higgins
http://www.eclipse.org/higgins/ 
An open source framework for integratein identity, profile, and relationship
information across multiple heterogeneous systems

The proposers of this TC recognize there are other possible  approaches to user
centric identity and believe that the defined Scope of Work of this TC addresses
many functional use cases of these parallel efforts. The proposers of this TC
seek involvement from authors of other such activities and the contribution of
their expertise and experience, and intend to work in harmony with them in the
creation of the product of this technical committee.

Applicable Work:
* OASIS Web Services Security TC. The IMI TC will ensure that its specifications
compose with the WSS TC specifications.
* OASIS Web Services Secure Exchange TC. The IMI TC will ensure that its
specifications compose with the WS-SX TC specifications.
* OASIS Web Services Federation TC. The IMI TC will ensure that its
specifications compose with the WS-FED TC specifications.
* OASIS Security Services Federation TC. The IMI TC will ensure that its
specifications compose with the SAML TC specifications.

The TC may decide to establish liaisons with other groups as needed.
Responsibilities for such liaison will be defined by the TC at that time.

(2)(b) The date, time, and location of the first meeting, whether it will be
held in person or by phone, and who will sponsor this first meeting. The first
meeting of a TC shall occur no less than 30 days after the announcement of its
formation in the case of a telephone or other electronic meeting, and no less
than 45 days after the announcement of its formation in the case of a
face-to-face meeting.

September 29th 2008 10am Ditton Manor, UK (Co-located at OASIS Standards Forum
2008: Security Challenges)

(2)(c) The projected on-going meeting schedule for the year following the
formation of the TC, or until the projected date of the final deliverable,
whichever comes first, and who will be expected to sponsor these meetings.

It is anticipated the IMI Technical Committee will meet via teleconference every
week at a time determined by the TC members during the TC's first meeting. 

It is anticipated that the IMI Technical Committee will meet face to face every
quarter at a time and location to be determined by the TC members.  

Actual pace of face to face and teleconference meetings will be determined by TC
members. 

One of the proposers, as listed below, will sponsor the teleconferences unless
other TC members offer to donate their own facilities.  If no other TC proposers
offer to sponsor teleconference facilities, Microsoft, IBM or Nortel will donate
their facilities. If OASIS establishes a phone bridge system as is being
discussed, the TC will consider use of that bridge system. 

(2)(d) The names, electronic mail addresses and membership affiliations of at
least Minimum Membership who support this proposal and are committed to the
Charter and projected meeting schedule.

Abbie Barbir (Nortel) abbieb@nortel.com
Adnan Onart (Nortel) AONART@nortel.com
Paul Knight (Nortel) paul.knight@nortel.com
Marc Goodner (Microsoft) mgoodner@microsoft.com
Michael McIntosh (IBM) mikemci@us.ibm.com
Anthony Nadalin, (IBM ), drsecure@us.ibm.com
John Bradley, (Individual), jbradley@mac.com
Richard Brackney (US DoD), rcbrack@verizon.net

(2)(e) The name of the Convener who must be an Eligible Person.
Abbie Barbir, Nortel

(2)(f) The name of the Member Section with which the TC intends to affiliate
with 
The TC will be affiliated with the IDTrust Member Section.

(2)(g) Optionally, a list of contributions of existing technical work that the
proposers anticipate will be made to this TC.        
      * Documents are listed below
           
[1] Identity Selector Interoperability Profile V1.5, July 2008
http://schemas.xmlsoap.org/ws/2005/05/identity

[2] A Guide to Using the Identity Selector Interoperability Profile V1.5 within
Web Applications and Browsers, July 2008
http://schemas.xmlsoap.org/ws/2005/05/identity

[3] An Implementer's Guide to the Identity Selector Interoperability Profile
V1.5, July 2008
http://schemas.xmlsoap.org/ws/2005/05/identity

[4] Application Note: Web Services Addressing Endpoint References and Identity,
July 2008
http://schemas.xmlsoap.org/ws/2006/02/addressingidentity 


(2)(h) Optionally, a draft Frequently Asked Questions (FAQ) document regarding
the planned scope of the TC, for posting on the TC's website.
          None

(2)(i) Optionally, a proposed working title and acronym for the specification(s)
to be developed by the TC. 
         None






 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]