${taskforce.name} Avatar
  1. OMG Task Force

Naming FTF — All Issues

  • Key: NAM
  • Issues Count: 41
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
NAM-41 Name equivalence NAM 1.0b1 open
NAM-40 INS: why NamingService instead of NameService? NAM 1.0b1 NAM 1.0 Resolved closed
NAM-39 Need a Registration Mechanism to publish INS references NAM 1.0b1 NAM 1.0 Resolved closed
NAM-38 INS stringfied name, etc. NAM 1.0b1 NAM 1.0 Resolved closed
NAM-37 Inadequate error codes for NamingContextExt NAM 1.0b1 NAM 1.0 Resolved closed
NAM-36 -ORBDefaultInitRef append of "/" NAM 1.0b1 NAM 1.0 Resolved closed
NAM-35 -ORBDefaultInitRef append of "/" NAM 1.0b1 NAM 1.0 Resolved closed
NAM-34 Default values for to_url are problematic NAM 1.0b1 NAM 1.0 Resolved closed
NAM-33 Illegal Examples NAM 1.0b1 NAM 1.0 Closed; No Change closed
NAM-31 List binding return type NAM 1.0b1 open
NAM-30 BindingIterator NAM 1.0b1 open
NAM-32 FormalNumber: formal/04-10-03, Section TOC NAM 1.3 open
NAM-17 Name comparisons NAM 1.0b1 open
NAM-18 Open Interpretation for next_one NAM 1.0b1 open
NAM-27 Changes to struct binding NAM 1.0b1 open
NAM-26 Destroy operation in original spec NAM 1.0b1 open
NAM-21 Specification of out parameter bl NAM 1.0b1 open
NAM-20 next_n return NAM 1.0b1 open
NAM-24 Destroying an iteratorr NAM 1.0b1 open
NAM-25 Text for destroy should be updated NAM 1.0b1 open
NAM-29 Meaning of "Why"member in the NotFound exception NAM 1.0b1 open
NAM-23 Fewer returns of requested number of bindings NAM 1.0b1 open
NAM-19 Specification of return value from next_one NAM 1.0b1 open
NAM-22 Value of how_many NAM 1.0b1 open
NAM-28 Names Library Benefits? NAM 1.0b1 open
NAM-14 Problems with step-wise resolution NAM 1.0b1 NAM 1.0 Closed; No Change closed
NAM-13 Naming FTF / RFC2396 Compliance Issue NAM 1.0b1 NAM 1.0 Resolved closed
NAM-10 Naming FTF: Allocation of port number NAM 1.0b1 NAM 1.0 Resolved closed
NAM-9 Alternate Protocol Specifications within URIs NAM 1.0b1 NAM 1.0 Resolved closed
NAM-7 Naming FTF: Stringified name ambiguity NAM 1.0b1 NAM 1.0 Resolved closed
NAM-6 Binding type "n_context": NAM 1.0b1 NAM 1.0 Resolved closed
NAM-8 INS: compliance with RFC2396 NAM 1.0b1 NAM 1.0 Resolved closed
NAM-12 Interoperable Naming Service: Why no CosNaming::NamingContextExt: :bind_st NAM 1.0b1 NAM 1.0 Resolved closed
NAM-11 Unclear requirements for support of textual object keys NAM 1.0b1 NAM 1.0 Closed; No Change closed
NAM-5 NotFound exception needs clarification NAM 1.0b1 NAM 1.0 Resolved closed
NAM-4 Binding a Stringified Name NAM 1.0 open
NAM-16 case-sensitivity in comparing interoperable names NAM 1.0b1 NAM 1.0 Resolved closed
NAM-15 Support of Interop Naming for Default Names is Not Scalable and is ineffici NAM 1.0b1 NAM 1.0 Resolved closed
NAM-2 INS Issue: Orderof how the Initial reference is resolved NAM 1.0 open
NAM-1 fragment part in file: or http: IOR NAM 1.0 open
NAM-3 INS Issue: When are -ORBInitRef arguments processed? NAM 1.0 open

Issues Descriptions

Name equivalence

  • Key: NAM-41
  • Legacy Issue Number: 498
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: NAM 1.0b1 — Wed, 12 Feb 1997 05:00 GMT
  • Updated: Wed, 11 Mar 2015 23:32 GMT

INS: why NamingService instead of NameService?

  • Key: NAM-40
  • Legacy Issue Number: 2347
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: NAM 1.0b1 — Wed, 27 Jan 1999 05:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

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

  • Updated: Wed, 11 Mar 2015 04:16 GMT

Need a Registration Mechanism to publish INS references

  • Key: NAM-39
  • Legacy Issue Number: 4287
  • Status: closed  
  • Source: Oracle ( Hemanth Puttaswamy)
  • Summary:

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

  • Reported: NAM 1.0b1 — Thu, 26 Apr 2001 04:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

    withdrawn

  • Updated: Fri, 6 Mar 2015 21:38 GMT

INS stringfied name, etc.

  • Key: NAM-38
  • Legacy Issue Number: 3324
  • Status: closed  
  • Source: yk.fujitsu.co.jp ( Euji Yano)
  • Summary:

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

  • Reported: NAM 1.0b1 — Mon, 14 Feb 2000 05:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

    closed. Not an issue

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Inadequate error codes for NamingContextExt

  • Key: NAM-37
  • Legacy Issue Number: 3263
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Mon, 31 Jan 2000 05:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 21:37 GMT

-ORBDefaultInitRef append of "/"

  • Key: NAM-36
  • Legacy Issue Number: 3108
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

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

  • Reported: NAM 1.0b1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

    CLOSED (No Action Required)

  • Updated: Fri, 6 Mar 2015 21:37 GMT

-ORBDefaultInitRef append of "/"

  • Key: NAM-35
  • Legacy Issue Number: 3107
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

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

  • Reported: NAM 1.0b1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

    CLOSED (No Action Required)

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Default values for to_url are problematic

  • Key: NAM-34
  • Legacy Issue Number: 3106
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    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

  • Reported: NAM 1.0b1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Illegal Examples

  • Key: NAM-33
  • Legacy Issue Number: 3091
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: NAM 1.0b1 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Closed; No Change — NAM 1.0
  • Disposition Summary:

    Typo / Not an Issue

  • Updated: Fri, 6 Mar 2015 21:37 GMT

List binding return type

  • Key: NAM-31
  • Legacy Issue Number: 24
  • Status: open  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: NAM 1.0b1 — Mon, 1 Jul 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

BindingIterator

  • Key: NAM-30
  • Legacy Issue Number: 64
  • Status: open  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: NAM 1.0b1 — Sat, 3 Aug 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

FormalNumber: formal/04-10-03, Section TOC

  • Key: NAM-32
  • Legacy Issue Number: 9811
  • Status: open  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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

  • Reported: NAM 1.3 — Thu, 8 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Name comparisons

  • Key: NAM-17
  • Legacy Issue Number: 270
  • Status: open  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: NAM 1.0b1 — Thu, 17 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Open Interpretation for next_one

  • Key: NAM-18
  • Legacy Issue Number: 271
  • Status: open  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Changes to struct binding

  • Key: NAM-27
  • Legacy Issue Number: 280
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Destroy operation in original spec

  • Key: NAM-26
  • Legacy Issue Number: 279
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification of out parameter bl

  • Key: NAM-21
  • Legacy Issue Number: 274
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

next_n return

  • Key: NAM-20
  • Legacy Issue Number: 273
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Destroying an iteratorr

  • Key: NAM-24
  • Legacy Issue Number: 277
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text for destroy should be updated

  • Key: NAM-25
  • Legacy Issue Number: 278
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of "Why"member in the NotFound exception

  • Key: NAM-29
  • Legacy Issue Number: 298
  • Status: open  
  • Source: Anonymous
  • Summary:

    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

  • Reported: NAM 1.0b1 — Wed, 23 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fewer returns of requested number of bindings

  • Key: NAM-23
  • Legacy Issue Number: 276
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification of return value from next_one

  • Key: NAM-19
  • Legacy Issue Number: 272
  • Status: open  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Value of how_many

  • Key: NAM-22
  • Legacy Issue Number: 275
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Names Library Benefits?

  • Key: NAM-28
  • Legacy Issue Number: 281
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Tue, 22 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problems with step-wise resolution

  • Key: NAM-14
  • Legacy Issue Number: 2953
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Tue, 5 Oct 1999 04:00 GMT
  • Disposition: Closed; No Change — NAM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming FTF / RFC2396 Compliance Issue

  • Key: NAM-13
  • Legacy Issue Number: 2943
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Mon, 11 Oct 1999 04:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming FTF: Allocation of port number

  • Key: NAM-10
  • Legacy Issue Number: 2885
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Mon, 13 Sep 1999 04:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alternate Protocol Specifications within URIs

  • Key: NAM-9
  • Legacy Issue Number: 2794
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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)
  • Reported: NAM 1.0b1 — Thu, 8 Jul 1999 04:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming FTF: Stringified name ambiguity

  • Key: NAM-7
  • Legacy Issue Number: 2660
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Fri, 21 May 1999 04:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Binding type "n_context":

  • Key: NAM-6
  • Legacy Issue Number: 2636
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Wed, 5 May 1999 04:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

INS: compliance with RFC2396

  • Key: NAM-8
  • Legacy Issue Number: 2669
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Fri, 28 May 1999 04:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interoperable Naming Service: Why no CosNaming::NamingContextExt: :bind_st

  • Key: NAM-12
  • Legacy Issue Number: 2942
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Thu, 23 Sep 1999 04:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unclear requirements for support of textual object keys

  • Key: NAM-11
  • Legacy Issue Number: 2899
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    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:

  • Reported: NAM 1.0b1 — Tue, 5 Oct 1999 04:00 GMT
  • Disposition: Closed; No Change — NAM 1.0
  • Disposition Summary:

    The INS specification is not specifying server side behavior.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NotFound exception needs clarification

  • Key: NAM-5
  • Legacy Issue Number: 2635
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Wed, 5 May 1999 04:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

    closed issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Binding a Stringified Name

  • Key: NAM-4
  • Legacy Issue Number: 5926
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: NAM 1.0 — Fri, 2 May 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

case-sensitivity in comparing interoperable names

  • Key: NAM-16
  • Legacy Issue Number: 3058
  • Status: closed  
  • Source: med.uu.nl ( Philip Lijnzaad)
  • Summary:

    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.

  • Reported: NAM 1.0b1 — Mon, 22 Nov 1999 05:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

    Add clarification text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support of Interop Naming for Default Names is Not Scalable and is ineffici

  • Key: NAM-15
  • Legacy Issue Number: 2970
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

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

  • Reported: NAM 1.0b1 — Mon, 11 Oct 1999 04:00 GMT
  • Disposition: Resolved — NAM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

INS Issue: Orderof how the Initial reference is resolved

  • Key: NAM-2
  • Legacy Issue Number: 3360
  • Status: open  
  • Source: Anonymous
  • Summary:

    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 ?

  • Reported: NAM 1.0 — Thu, 24 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

fragment part in file: or http: IOR

  • Key: NAM-1
  • Legacy Issue Number: 3100
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: NAM 1.0 — Wed, 8 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

INS Issue: When are -ORBInitRef arguments processed?

  • Key: NAM-3
  • Legacy Issue Number: 3535
  • Status: open  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    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.

  • Reported: NAM 1.0 — Fri, 7 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT