NAM — INS: compliance with RFC2396

Summary: Given that the FTF is considering changes to the URL schemes proposed by
the Interoperable Name Service proposal it may be worthwhile to raise the
issue of compliance with RFC2396 again. RFC2396 defines Uniform Resource
Locators.

The INS RFC (orbos/97-12-20) required that submissions specify a
relationship between CosNaming::Names and Uniform Resource Locators
(URLs). I assume it was implied that proposals must comply with the
current IETF specification for the Uniform Resource Locator (URL) generic
syntax.

RFC2396 uses the more general term Uniform Resource Identifier (URI). It
makes a clear distinction between two orthogonal parts of a URI.

The first part specifies how a remote resource can be located and
retrieved. When describing the distinction between the two parts the RFC
refers to this first part as the Uniform Resource Locator (URL) to stress
the aspect of "locating" a remote resource.

The second, optional component of a URI is the fragment identifier. This
part of the URI contains information that is interpreted by the user agent
AFTER the retrieval action has been successfully completed.

The proposed iiopname (or corbaname) scheme also has two components, one
part is used essentially as if it was a iioploc URL to LOCATE an object of
type CosNaming::NamingContext. The second component is interpreted, by the
ORB that uses the URL, AFTER the object was retrieved, to resolve a
stringified CosNaming::Name relative to that context.

Clearly, these two aspects of the bootstrapping mechanism: (1) locating
the naming context, and (2) resolving the name, are better defined as
orthogonal components.

An ordinary URL, for example using the iioploc scheme, suffices for
locating the naming context. A fragment identifier, separated from the
URL by the "#" character, is the ideal place for the stringified name that
is interpreted on the client-side.

A separator for corbaname is appropriate. This simplified the description of corbaname, into essent