Issues for Interoperable Naming Service FTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 2635: NotFound exception needs clarification
Issue 2636: Binding type "n_context":
Issue 2660: Naming FTF: Stringified name ambiguity
Issue 2669: INS: compliance with RFC2396
Issue 2794: Alternate Protocol Specifications within URIs
Issue 2885: Naming FTF: Allocation of port number
Issue 2899: Unclear requirements for support of textual object keys
Issue 2942: Interoperable Naming Service: Why no CosNaming::NamingContextExt: :bind_st
Issue 2943: Naming FTF / RFC2396 Compliance Issue
Issue 2953: Problems with step-wise resolution
Issue 2970: Support of Interop Naming for Default Names is Not Scalable and is ineffici
Issue 3058: case-sensitivity in comparing interoperable names
Issue 3091: Illegal Examples
Issue 3100: fragment part in file: or http: IOR
Issue 3106: Default values for to_url are problematic
Issue 3107: -ORBDefaultInitRef append of "/"
Issue 3108: -ORBDefaultInitRef append of "/"
Issue 3263: Inadequate error codes for NamingContextExt
Issue 3324: INS stringfied name, etc.
Issue 3360: INS Issue: Orderof how the Initial reference is resolved
Issue 3535: INS Issue: When are -ORBInitRef arguments processed?
Issue 4287: Need a Registration Mechanism to publish INS references
Issue 4557: What are the semantics of AlreadyBound in NamingContextExt::resolve_str()
Issue 5926: Binding a Stringified Name
Issue 9811: FormalNumber: formal/04-10-03, Section TOC

Issue 2635: NotFound exception needs clarification (naming_ftf)

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.
 

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.
 
 

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.
 

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.

:Names and Uniform Resource Locators

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)

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.

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

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.

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.

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

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. 

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?

 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.

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

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

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

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.

"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 "\\\\".

 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 ?

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.

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

    In formal/01-02-65 the NamingContextExt::resolve_str() is defined as
(pages 2-18 and A-3):

Object resolve_str (in StringName sn) raises (NotFound, CannotProceed,
InvalidName, AlreadyBound);

    The AlreadyBound exception listed in the raises clause appears
superfluous.  The spec does not say when or if the exception can be raised,
and the text implies that it cannot be raised, because it reads:

This is a convenience operation that performs a resolve in the same manner
as

NamingContext::resolve. It accepts a stringified name as an argument instead
of a

Name.



    However, the resolve() operation never raises AlreadyBound.  It appears
as if the exception in question should be removed from the raises clause.

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

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