Naming Service Avatar
  1. OMG Specification

Naming Service — Closed Issues

  • Acronym: NAM
  • Issues Count: 20
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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-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-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

Issues Descriptions

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

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

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