Internet DRAFT - draft-hately-uddi-uri-scheme
draft-hately-uddi-uri-scheme
Internet Draft A Hately, IBM
Document: draft-hately-uddi-uri-scheme-00.txt K Best, OASIS Open
Expires: January 2005 July 2004
UDDI URI Scheme Registration with IANA
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026 [1] except that the right to produce
derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This IETF document reproduces the UDDI keying scheme definition
found in the OASIS UDDI Version 3 Specification [2] and is published
as an RFC for ease of access and IANA registration. Change control is
retained within OASIS
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [3].
Table of Contents
1. Introduction...................................................2
2. URI Scheme Formal Syntax Definition and Character Encoding.....2
3. Intended Usage.................................................4
Hately Expires - January 2005 [Page 1]
UDDI URI Scheme Registration with IANA July 2004
4. Applications and or protocols which may use the UDDI URI scheme4
5. Security Considerations........................................4
6. IANA Considerations............................................4
References........................................................5
Acknowledgments...................................................6
Author's Addresses................................................6
1. Introduction
The OASIS Universal Description Discovery & Integration (UDDI)
Version 3 Specification provides a system for registering and
discovering the information required to use a Web service and
information about the provider offering the Web service. The focus of
UDDI is the definition of a set of services supporting the
description and discovery of (1) businesses, organizations, and other
Web services providers, (2) the Web services they make available, and
(3) the technical interfaces which may be used to access those
services. Each of the enumerated entities is uniquely identified in a
UDDI registry by a unique key to facilitate queries and updates
pertaining to the entity.
1.1 Licensing and Availability
The UDDI Version 3 Specification may be used under the terms set
forth in the OASIS IPR Policy [4]. Under that policy, information
regarding claims and licenses is available at [http://www.oasis-
open.org/committees/uddi-spec/ipr.php]
2. URI Scheme Formal Syntax Definition and Character Encoding
A UDDI URI is the unique key for each entity in a UDDI registry. The
complete ABNF grammar in Section 2.1 is the only authoritative syntax
definition.
2.1 ABNF Grammar
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [5].
uddiScheme = %d117.100.100.105 ; "uddi" in lower case
uddiKey = keyGeneratorKey / nonKeyGeneratorKey
nonKeyGeneratorKey = uuidKey / domainKey / derivedKey
uuidKey = uddiScheme ":" uuid_part
Hately Expires -
- January 2005 [Page 2]
UDDI URI Scheme Registration with IANA July 2004
uuid_part = 8HEXDIG "-"
4HEXDIG "-"
4HEXDIG "-"
4HEXDIG "-"
12HEXDIG
domainKey = uddiScheme ":" hostname
hostname = *(domainlabel ".") toplabel ["."]
domainlabel = alphanum /
alphanum *(alphanum / "-") alphanum
toplabel = ALPHA / ALPHA *(alphanum / "-") alphanum
alphanum = ALPHA / DIGIT
derivedKey = nonKeyGeneratorKey ":" KSS
keyGeneratorKey = nonKeyGeneratorKey ":" "keygenerator"
KSS = 1*uric ; KSS MUST NOT BE "keygenerator"
Uric = reserved / unreserved / escaped
reserved = ";" / "/" / "?" / ":" / "@" / "&" /
"=" / "+" / "$" / ","
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
escaped = "%" HEXDIG HEXDIG
There are some extra restrictions on domain names that are not
captured in the ABNF syntax above:
1. The maximum length of a string representation of a domain name is
253 characters/octets.
2. The maximum length of an individual domainlabel is 63
characters/octets.
3. KSS must not be "keygenerator"
Hately Expires - January 2005 [Page 3]
UDDI URI Scheme Registration with IANA July 2004
3. Intended Usage
A UDDI URI is intended to represent a uddiKey to reference an entity
within a given UDDI registry. Within a given registry each uddiKey
references only one entity. The uddiKey for an entity can be used
for internal referencing pointers from one UDDI entity to another
using a uddiKey. An example of an internal reference in UDDI is that
several Web services implementing the same specification should all
reference the same Web service concept (tModel) by using the uddiKey
for the tModel in the technical fingerprint of the service (tModelKey
contained in a child of the bindingTemplate). The uddiKey for an
entity can also be used for external referencing where the
combination of a SOAP endpoint to access the registry plus a UDDI key
allows a UDDI aware application to retrieve a particular entity in
that registry.
4. Applications and or protocols which may use the UDDI URI scheme
UDDI aware applications make extensive use of the UDDI URI scheme to
identify the entities in a registry. These UDDI aware applications
use a particular UDDI URI within a particular registry to reference
the meta-data for Web service providers (businessEntity elements) and
Web service concepts (tModel elements) and the actual Web service
meta-data itself (businessService and bindingTemplate elements).
5. Security Considerations
When a UDDI URI is carried within SOAP messages to a UDDI registry,
security is addressed by framework and policies of the UDDI node
receiving the message as part of the registry. As indicated in the
UDDI specification, the security is addressed within the
corresponding protocol.
In general, security, as it relates to the usage and carriage of a
UDDI URI, is considered as an issue that should be addressed within
scope of UDDI security framework and policies or other relevant
protocols and is not within the scope of this document.
The primary security issue relating specifically to a UDDI URI is
that the mapping between the entity and the UDDI URI is registry
specific. This means that it is necessary for applications for and
users of UDDI registries to ensure that no assumption about identity
of an entity is derived solely from the uddiKey.
6. IANA Considerations
The purpose of this document is serving as a reference point for the
purposes of registering the UDDI URI scheme with IANA.
Hately Expires - January 2005 [Page 4]
UDDI URI Scheme Registration with IANA July 2004
Having the URI registered with IANA will ensure that there is no
duplication of the URI scheme "uddi". This document reproduces the
exact definition of the scheme from the UDDI Version 3.0
specification
[NOTE to IANA: Replace RFC XXXX with the RFC number of this
document]
Registration Template
URI scheme name: uddi
URI scheme syntax: Section 2 of RFC XXXX
Character encoding considerations: Section 2 of RFC XXXX
Intended usage: Section 3 of RFC XXXX
Applications and/or protocols which use this scheme: Section of
RFC XXXX
Interoperability considerations: None. (Section 2 of RFC XXXX
contains the first version of UDDI URI definition.)
Security considerations: Section 5 of RFC XXXX
Relevant publications: [2]
Contact: Andrew Hately, hately@us.ibm.com and Karl Best,
karl.best@oasis-open.org
Author/Change Controllers: Andrew Hately and Karl Best
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 OASIS UDDI Specification Technical Committee, Committee
Specification, "UDDI Version 3.0", OASIS, July 2002
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
4 OASIS Policy on Intellectual Property Rights, OASIS, [at
http://www.oasis-open.org/who/intellectualproperty.php]
Hately Expires - January 2005 [Page 5]
UDDI URI Scheme Registration with IANA July 2004
5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997
Acknowledgments
This document is prepared and posted with the agreement of the OASIS
UDDI Specification Technical Committee.
Committee's Address
The OASIS UDDI Specification Technical Committee can be contacted via
its permanent home page at
http://www.oasis-open.org/committees/uddi-spec
or through the current chairs:
Tony Rogers
Computer Associates
Email: tony.rogers@ca.com
Luc Clement
Systinet Corporation
Email: luc.clement@systinet.com
Author's Addresses
Andrew Hately
IBM
11501 Burnet Road
Austin, TX USA
Phone: +1.512.331.3826
Email: hately@us.ibm.com
Karl Best
OASIS Open
630 Boston Rd
Billerica, MA 01821
978-667-5115
Email: karl.best@oasis-open.org
Hately Expires - January 2005 [Page 6]
