Summary: The Name equivalence issue has appeared in comp. object.corba. Follow up posting from Michi Henning

Summary: INS specifies that the default object key for the `root" context of a
CosNaming service is "NamingService". However, the keyword passed to
CORB::ORB::resolve_initial_references() to locate the CosNaming service
is "NameService". This is bound to create confusion, if only among
implementors. Suggest changing the object key of the root naming
context to "NameService".

resolve_initial_reference token references to "NamingService" have been changed to "NameService"

Inter-Operable Naming service does provide a standard way to resolve the
references using corbaloc: and corbaname: url's, but does not specify on how to
publish the service reference for INS url's. If we leave it upto the implementor
then there is no standard like we have it on the resolution of reference.

One portable way of doing this would be to use
ORB.register_initial_reference(<INSObjectKey>, <ObjRef>) to publish <ObjRef>.

withdrawn

"Several points in the INS specification are not clear to me. I'd like to
confirm that my understanding of these points is valid.

I investigated the INS FTF document (ptc/99-12-03) and associated errata
(ab/00-01-04). However, I am still not sure about the details in section
"4.8.4.1 Default Resolution Order", the minor codes values in section
"13.6.7 Object URLs" and the details of stringified names specified in
section "4.5 Stringified Names" in the specification. The unclear points are:

1) Assume that a client program calls ORB_init with ORBInitRef (without
ORBDefaultInitRef), and then calls CORBA::ORB::resolve_initial_references.
A pre-configured ORB setting is used.

If "1. Resolve with -ORBInitRef for this <ObjectID>" fails for any reason,
must "2. Resolve with pre-configured ORB setting" be performed?

I don't think so. The Client program wanted an IOR that is required by an
ORB::init parameter. If the ORB returns a pre-configured IOR, then the
client can't know if the returned IOR is the one that the client wanted or
pre-configured IOR.

2) Is there any value defined in the specification (or other specification)
about the BAD_PARAM minor codes for "BadScheme", "BadAddress" and
"BadSchemeSpecificPart"?

When exceptions are raised with these minor codes, exactly what's wrong
with the associated URL?

3) If an escaped character in a string name is not one of '\', '/' or '.',
is the string name valid?

I believe it is valid. "\A\B" should be changed into "AB".

4) If a string name is empty, such as "", is the string name invalid?

I believe it is invalid. If it is valid, what is the string length?

5) If the first character of string name is '/' or string name is just "/",
is the string name invalid?

I believe it is invalid.

If it is valid, is "AAA.aaa//BBB.bbb" interpreted as:
[0] "AAA", "aaa"
[1] "", ""
[2] "BBB", "bbb"

6) If the last character of string name is the escape character, '\', is
the string name invalid?

I believe it is invalid.

7) If I want to change "
", which is not escaped yet, to an escaped string
name, is the escaped string name "\\\" or "\\\\"? The "\\\" means one
escape character and two escaped characters '\'. The "\\\\" means two pairs
of escape character and escaped character '\'.

I believe that "
" should be changed to "\\\\".

closed. Not an issue

Consider the following situation:

• Two naming servers:
  One is new and implements NamingContextExt.
  The other is old and only implements the old NamingContext interface.

• the old one is federated into the new one

• a client invokes an operation in the extended interface,
  on the new one, using a compound name that references the old one.

It is not clear what exception should be returned in this case.

There seem a couple of semi-reasonable candidates:
CannotProceed & NO_IMPLEMENT.

withdrawn by submitter

-ORBInitialRef appends a "/" before concatenating the initial
reference tokens. This is not necessary as the "/" can be part of the
ORBInitialRef value itself. Appending "/" arbitrarily restricts the form
of the resultant URIs.

CLOSED (No Action Required)

-ORBInitialRef appends a "/" before concatenating the initial
reference tokens. This is not necessary as the "/" can be part of the
ORBInitialRef value itself. Appending "/" arbitrarily restricts the form
of the resultant URIs.

CLOSED (No Action Required)

Summary: In the operation to_url, defaulting the address and protocol for
to iiop and localhost is of little value and has created some confusion.
Suggest that no default be allowed

Agreed.

The Sep 01 revision of the INS document (99-09-01) twice shows example
URLs (on page 3-4 and 3-7) that are illegal according to the grammar on
page 3-5. The example on page 3-4 reads

corbaloc:iiop://1.1@555xyz.com/Prod/TradingService

However, the grammar allows either the <iiop_default> string `//' or
the <iiop_prot_token> `iiop', but not both. A valid URL can therefore
never contain a <iiop_prot_addr> that starts in `iiop://'.

So what's correct, the example or the grammar?

Typo / Not an Issue

Summary: The "list" operation to access the bindings within a naming context has an overly verbose return type. Could it (and some of its exceptions) be simplified?

Summary: The name service doesn"t really specify when false is first returned. Is when it returns the last one, or when it is already pointing out of range?

This is simply an administrative error, the table of contents within the document does not reflect the fact that the lightweight naming chapter (chapter 3) was incorporated into the document

Summary: Naming Service spec: "The kind attribute adds descriptive power to names.."(p. 3-2) Interpretation: kind value is opaque, never looked at, carried arround with each name. Interpretation correct?

Summary: It is open to interpretation as to whether FALSE is returned with the last valid binding or after the last valid binding. Call next_one one more time after last valid binding to get FALSE?

Summary: Proposal to revise the Naming Service. p. 3-6 and 3-12 of CORBAservices replace the definition of Binding

Summary: The destroy operation was the only option in original spec before Lifecycle spec. By inheriting from LifeCycleObject, we get the remove operation which does same as destroy.

Summary: When next_n returns FALSE, it needs to be specified what happens to the out parameter bl. Spec should mandate that lenght of returned sequence must be zero.

Summary: next_n returns a boolean value. It is specified nowhere what the return value means in various cases

Summary: Naming Service implementation should be free to destroy an iterator as soon as last value has been retrieved. Clients should be allowed to call next_one or next_n after one of these calls.

Summary: Text for destroy should be updated to state that a call to destroy after next_one or next_n have returned FALSE may no longer be valid and may raise OBJECT_NOT_EXIST.

Summary: Text explains when the NotFound exception is raised, but it does not explain the meaning of "why"member in the exception. Why can be missing node, not_context, not_object

Summary: The spec says nothing about whether the Naming Service is allowed to return fewer than requested number of bindings.

Summary: The return value from next_one is specified as "If there are no more bindings, false is returned". What is returned if there is another binding?

Summary: The spec says nothing about how to say "as many as you can" with the value of how_many. Specify that how_many value should return as many bindings as it can in a single call.

Summary: Problem understanding benefits of Names Library. There are differences between what the standard says and what the pseudo-IDL for the names library says.

The specification of the NamingContext interface distinguishes between
object and context bindings. It requires that when a multi-component
name is resolved, each name other than the last must designate a context
binding - an object binding to an object that happens to conform to the
NamingContext interface shall not be sufficient.

This restriction is easy for a name server to support, because it has
direct access to the binding information. (In fact, multi-component
resolution is easier for the server with this restriction because it
need not narrow an object reference to determine if it is a
NamingContext - a potentially expensive operation.)

However this restriction places an unacceptable burden on "an
application that chooses to do piecewise resolution". As things stand,
an application that wishes to do piecewise resolution in a conforming
way must first list each context in order to determine the binding type
of the component at the next level. (There are many reasons to do
step-wise resolution. For instance, some piece of code may have a
"working context" in which it stores bindings. A client of it may be
responsible for selecting the working context and providing it as an
object reference. Also, when federated naming contexts are used,
stepwise resolution can be a significant performance win.) The cost of
doing the list can be arbitrarily high, depending on the number of
bindings in the context.

Decided not to add extra operations to support this particular client case.

I have one issue with the naming FTF Sept 9th doc
concerning RFC2396. I would like an issue number to
be assigned to this. (This post has already appeared
in a slightly different form on the naming_ftf list).

I am extremeley reluctant to suggest further changes to the URL
at this point but feel the issue has to be considered.

Fortunately, the suggested changes to the URL forms are
small.

1. RFC2396 Compliance:
I received some email from some individuals that are a bit
more URI "aware" than I, pointing out
that in 2396:
a. URI's that start out <scheme>:/ have to follow
one set of rules (hier_part URIs), those that don't
start with a leading "/" after the scheme are
free to do what they'd like (opaque part URIs).

The details are in the first paragraphs of
chapter 3 of 2396.

b. Our use of "//" as a familiar shorthand for
iiop, will put corbaloc/corbaname in the
restricted hier_part category, with a likely
disapproval from IANA. (For any number of
reasons, multiple <authority>'s, <authority>'s
using different transports, non-hierarchial keys...)

c. If we were to remove the shorthand "//" for iiop and
allow "" as well as "iiop" for the iiop protocol id,
we would be compliant and have URLs like:

corbaloc::xyz.com/a/b/c
corbaname::xyz.com,atm:2452r2f34f/aContext#a/b/c

d. For discussion purposes, I have attached a BNF file describing
corbaloc / corbaname in the same style as the BNF in Appendix A of
2396. In it, I have broken out "//" as a seperate token:
iiop_id_reserved_2396. (BNF at bottom of email)

e. Possible courses of action:
We can:
1. leave "//" and hope IANA won't object or simply do
not register the schemes.
2. remove "//" and use "" for iiop
3. support "", leave "//" with a footnote indicating
that it may be deprecated, depending on IANA
approval.

RFC2396 compliance is desirable. Agreed to change the iiop protocol shorthand from "//" to ":".

Summary: The INS Adopted Specification lists port 9999 as a place holder until
a final allocation of a port number has been made. The apparent intent
is to register a port number above 1024. The current status hurts
interoperability of emerging implementations, for the following
reasons:

• Use of port number 9999 should be discouraged, as it is already
  registered to Anoop Tewari <anoop@next.distinct.com>:

distinct 9999/tcp distinct
distinct 9999/udp distinct

• There is already an well-known port number assigned to Christian
  Callsen <Christian.Callsen@eng.sun.com>:

omginitialrefs 900/tcp OMG Initial Refs
omginitialrefs 900/udp OMG Initial Refs

Why is an allocation of a port number > 1024 desirable, when a
well-known port has been assigned already?

If a different port number is registered with IANA, what is the
purpose of the port 900 allocation?

The longer the final value remains undetermined, the more
implementations will hard-code some value, which is likely to be
different from the final value, which will give later interoperability
problems.

Application made to IANA for a port assignment. Port number assigned is 2809.

Summary: Object URIs should accommodate multiple protocols. This is important for a
wide range of present day systems, such as embedded and real-time systems
that do not or cannot use TCP/IP, and will accommodate future expansion of
CORBA beyond TCP/IP networks.

Object URIs should

• be extensible to allow additional addressing schemes for, at least, GIOPs
  over transports other than TCP/IP. A default of IIOP that results in a
  shorter form is allowable.
• accommodate additional standardized addressing schemes as transports and
  protocols become adopted. (similar to that provided by the present IOR
  structure through the adoption of new standard profiles)
• accommodate additional proprietary addressing schemes targeted for
  markets for which standardization might be inappropriate or too costly. In
  particular, it should allow assignment of partitions of the naming space to
  entities (similar to the current provision for vendor-specific profile tags)

Support for multiple protocols is required. changed iioploc/iiopname to corbaloc/corbaname and chang

Summary: I think we all agree that the following stringified names are syntax errors:

/ab
a//b
ab/

That is to ensure that there is only a single representation of empty
id and kind fields. In other words, the above names are correctly expressed
as:

./ab
a/./b
ab/.

It occurred to me that we have a related problem with empty kind fields.
For example, the following two strings appear to denote the same
name component:

ab.
ab

In other words, the spec isn"t clear whether the trailing dot is permitted.

Original submission intention is for a name to have a single valid stringified representation. Clar

Summary: by using bind_context/rebind_context/bind_new_context versus those
that are bound by using other means?

If an application uses resolve() to lookup a naming context, it has no
way of telling whether the naming context has the binding type
n_context. In fact, it doesn"t care. So an application choosing to do
piecewise resolution against CosNaming would see a different behavior
than if it were to do whole resolution. This seems to contradict the
subsection "Resolution of Compound Names" in Section 4.2, page 4-8. It
seems that n_context is an implementation issue of CosNaming that is
exposed to the application.

The suggestion is to remove the third paragraph of the Usage section,
or to change it so that n_context be set for any naming context bound
in the namespace.

Clarify role of when naming_contexts participate in name resolution, make text consistent with Usage

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

The INS (orbos/98-10-11) has a new method resolve_str to convert from a
StringName to an object in one step; the alternative would be to call
to_name (to convert a StringName to a Name) and then call resolve (to
convert the Name into an object reference).

Why isn't there a similar operation for bind, called bind_str: given a
StringName and an object reference, create the indicated binding. The
current interface requires two method calls to create the binding.

The submitters had considered a number of convenience operators but decline to add stringified versi

The core changes introduced by the adoption of the INS specification
have provided the means for a client to fabricate an object reference
with a key containing arbitrary octets, and designating any server
address.

This is the first time that an OMG specification has violated the rule
that object keys are opaque, formatted at the discretion of the server
orb. This rule is violated because, at a minimum, the changes seem to
require that a key containing the characters "NameService" must be a
valid key in some server in order to support the INS specification.

It seems that CORBA is now requiring that a conforming orb must natively
support at least some range of text-like keys, either in all servers or
in at least one specially constructed server.

If this is indeed a requirement, then there is a need to spell out
clearly the extent of this requirement:

The INS specification is not specifying server side behavior.

Summary: Issue: NotFound exception needs clarification:

Page 4-10: Section 4.3.2 Exceptions

The subsection for "NotFound" describes the value of rest_of_name as:

rest_of_name identifies the portion of the name that caused the
error.

And then goes on to describe for each value of "why" the first name
component that rest_of_name must have.

This requirement is insufficient. It must require that rest_of_name
contains the remainder of the non-working name (just like that in
CannotProceed). For example, if you supply a name such as
"aa/aa/aa/aa" to any operation that raises NotFound, the current
definition requires it to return "aa" as the first component but does
not require that other components be set. In fact, Sun"s
implementation (and probably others) currently just returns one
component, which is useless.

closed issue, resolved

The NamingContextExt interface has a resolve_str
operation that takes a string and returns its
binding.

I suggest to add a converse bind_str operation:

void bind_str (in StringName sn, in Object obj)
raises (NotFound, CannotProceed, InvalidName,
AlreadyBound);

That would allow not only lightweight clients to
use the Naming Service, but also lightweight servers
to publish their references as easily as possible.

(And a Lightweight Naming Service would be possible
that just implemented these two operations.)

while reading the Interoperable Naming specification (orbos/98-10-11), I
looked in vain for any mention of whether the comparison of names for
equality is done in a case-sensitive way or not. I suspected that it is
case-sensitive (and personal communication with Michi Henning confirmed
this), but I think the specification would gain preciseness if this was
stated clearly. This might be addressed by the FTF which I think is currently
active.

Add clarification text.

The point I mean to make is on the resolution of corbanames
beginning with "corbaname:///".

The spec implies that name beginning with "corbaname:///" are basically
resolved by a NamingContext found at

"corbaloc://localhost:9999/NameService".

Agreed that the default localhost:9999 idea is problematic. To allow URLs to be used relative to the

The latest INS doc 99-12-03.pdf explains the order the Initial reference
should be resolved is
1. Try using -ORBInitDef definition
2. Try using -ORBDefaultInitDef defintion
3. Then finally try with Pre-Configured ORB Settings.

The above would be the resolve_initial_references protocol. Now, If the user
sets a -ORBInitDef in the format

-ORBInitDef NotificationService=corbaloc:rir:/NotificationService

If the user does orb.resolve_initial_references( "NotificationService" )
then according to the spec, r_i_r() first checks -ORBInitDef's, In this case
finds one and also finds that the NotificationService can be obtained by
r_i_r()
again it calls the same method. Doesn't this lead to an infinite loop ?

I am just reflecting over the optional IOR syntaxes using file:// and
http:// URI's and have one suggestion. URI's sport a `fragment identi-
fier', i.e. an identifier following a hash sign.
Now this fragment identifier could be useful to disambiguate between
many IORs in the referenced file. I can think of several possibilities:

1.) The fragment-id is numerical. The file contains many IORs, separated
by newlines, and the fragment-id is an index into the file.

2.) The file contains many lines of the format `identifier WS IOR', i.e.
a simple tab-separated table. The fragment-id denotes the first IOR
where the identifier matches.

3.) The ORB checks each IOR in the file and looks for one whose Reposi-
tory Id matches the fragment-id.

Section 4.8.2 of ptc/99-12-03 should specify at what time strings
given to -ORBInitRef are processed into object references. Should they
be processed during ORB_init() and stored for later use by
resolve_initial_references(), or should they be processed each time
resolve_initial_references() is called?

This matters for corbaname: (and file:, http:, etc.) URIs whose
resolutions can change over time.

If they are processed at ORB_init() time, are they processed in the
order they were specified on the command line? Suppose an ORB with an
administratively configured NameService reference is called with a
command line of

-ORBInitRef Foo=corbaname:rir:#foo -ORBInitRef NameService=IOR:...

If ORB_init() processes the arguments into object references in order,
foo will be looked up in the administratively configured name service,
rather than the one specified on the command line. This may or may not
be considered a useful feature.