[uddi-spec] Draft of UDDI URI registration

[Andrew Hately <hately@us.ibm.com>]

CR009 will need to be accepted
first, and any impact from CR027 resolved as well.

Here is a first draft of the document
for review.

The next steps are to resolve any
IP issues (Tom/Luc) and to close on any CRs that would impact the key syntax.

I also believe I need to write
a section on encoding, and would like some clarification regarding our
intended support of URI escaping in the UDDI scheme.

1.        Introduction


The 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.

2.        
URL 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 [  Crocker,
D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd.,
November 1997
].

uddiScheme     =  %d117.100.100.105
; uddi” in lower case

uddiKey        =
 uuidKey / domainKey / derivedKey

uuidKey        =
 uddiScheme “:” uuid_part

uuid_part        
       =  8HEXDIG “-“
         
        4HEXDIG “-“
         
        4HEXDIG “-“
         
        4HEXDIG “-“
         
        12HEXDIG

domainKey      =  uddiScheme
“:” host_part

host_part      =  hostname

hostname       =  *(domainlabel
“.”) toplabel [“.”]

domainlabel    =  alphanum
/ alphanum *(alphanum / “-“) alphanum

toplabel       =  ALPHA
/ ALPHA *(alphanum / “-“) alphanum

alphanum       =  ALPHA
/ DIGIT

derivedKey     =  uddiKey
“:” KSS

KSS          
 =  1*uric

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.        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. 
    
Having the URI registered with IANA
will ensure that there is no    duplication of the URL 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

    
      URL scheme name:
uddi 
    
      URL 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 URL definition.)  
    
      Security considerations:
Section 5 of RFC XXXX 
    
      Relevant publications:
[2] 
    
      Contact: Andrew
Hately, hately@us.ibm.com 
    
      Author/Change
Controller: OASIS

References

  Bradner, S., "The Internet
Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

  OASIS UDDI Technical Committee
Specification "UDDI Version 3.0", OASIS, July 2002

  Bradner, S., "Key words
for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997

  Crocker, D. and Overell, P.(Editors),
"Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet
Mail Consortium and Demon Internet Ltd., November 1997


Andrew Hately
IBM Austin
UDDI Development, Emerging Technologies 
Lotus Notes: Andrew Hately/Austin/IBM@IBMUS
Internet: hately@us.ibm.com
(512) 838-2866,  t/l 678-2866