Issue 2899: Unclear requirements for support of textual object keys (naming_ftf) Source: Cisco Systems (Mr. Paul Kyzivat, pkyzivat@cisco.com) Nature: Uncategorized Issue Severity: 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: Resolution: The INS specification is not specifying server side behavior. Revised Text: Actions taken: October 5, 1999: received issue October 21, 1999: moved from orb_revision to naming-ftf May 4, 2000: closed, no action taken Discussion: End of Annotations:===== Date: Tue, 05 Oct 1999 10:56:34 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: issues@omg.org CC: CORE RTF , Interop RTF , Naming FTF Subject: Unclear requirements for support of textual object keys X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pD=e9]$)!!AECe9AJj!! 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: - if all servers should support this, then how is the feature to be manifested? These can't be object ids in the root poa, because the root poa doesn't support user specified object ids. If these should be objects in some other poa, which one? - if a specially constructed server is required to provide this capability, is this a required component of an ORB? Is it to be configurable? If so, what degree of configurability is required? I think this is a nasty position to be in. I would rather not be trying to resolve it. But now it seems that it must be resolved, so I suggest the following as a least-invasive: - add an additional alternative to the POA's IdAssignmentPolicy: PUBLIC_ID in addition to the current USER_ID and SYSTEM_ID. - in POAs with the PUBLIC_ID policy, keys are restricted in the octets they may contain. (We can discuss the restriction - I suggest alphanumeric characters only.) - at most one POA may have the PUBLIC_ID policy. Some exception to be raised if an attempt is made to violate this. With these changes, the orb can use the object id as the key in the poa with the PUBLIC_ID policy, and can use characters outside the reserved set to distinguish the keys for other POAs. I don't want to see a special server required because it is a slippery slope. It also smells like yet another naming service in a different package. Also, it is a barrier to entry for service providers that want to provide some particular service that is portable across orbs. X-Authentication-Warning: suntan.dstc.edu.au: mcfadden owned process doing -bs Date: Wed, 6 Oct 1999 10:06:35 +1000 (EST) From: Ted McFadden To: Paul H Kyzivat cc: issues@omg.org, CORE RTF , Interop RTF , Naming FTF Subject: Re: Unclear requirements for support of textual object keys In-Reply-To: <37FA11A2.674919E6@roguewave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: fd)e9e:_!!([A!!4?g!! On Tue, 5 Oct 1999, Paul H Kyzivat wrote: > 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. I may have missed it, but I can't find a place in the INS spec chapters where "NameService" is required. It certainly makes things more convenient and makes for shorter URLs, but that was the point of corbaloc/corbaname. In the revised naming service chapter, "NameService" is a default key if no key is explicitly specified in a corbaname. Prior to the Sept. 9 document, there was no way to specify a URL with a key other than "NameService", now it is possible as corbanames are proper extensions of corbalocs. So a server need not have a key of "NameService". A vendor could use any proprietary key and end up requiring corbnames like: corbaname://555xyz.com/%23%56%29%11%99%33%22%23/a/b/c (not that I'd ever like to use a URL like that). The only other use of a "NameService" key is in the core chapter 4. Where it is not specifically required either. An ORB must be configurable so that an arbitrary object reference can be set to be any of the initial services. -ORBInitRef NameService=IOR:45AB..... -ORBInitRef NameService=corbaloc://xyz.com/a/b/c -ORBDefaultInitRef is also provided to allow all initial services to be resolved from a single URL prefix. This would require a key that at least contains "NameService", but only if there is not a specific ORBInitRef. This is a convenience that does not dictate server keys. > > 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: > > - if all servers should support this, then how is the feature to be > manifested? These can't be object ids in the root poa, because > the root poa doesn't support user specified object ids. If these > should be objects in some other poa, which one? > > - if a specially constructed server is required to provide this > capability, is this a required component of an ORB? Is it to > be configurable? If so, what degree of configurability is > required? > > I think this is a nasty position to be in. I would rather not be > trying > to resolve it. But now it seems that it must be resolved, so I > suggest > the following as a least-invasive: > > - add an additional alternative to the POA's IdAssignmentPolicy: > PUBLIC_ID in addition to the current USER_ID and SYSTEM_ID. > > - in POAs with the PUBLIC_ID policy, keys are restricted in the > octets they may contain. (We can discuss the restriction - I > suggest alphanumeric characters only.) > > - at most one POA may have the PUBLIC_ID policy. Some exception > to be raised if an attempt is made to violate this. > > With these changes, the orb can use the object id as the key in the > poa > with the PUBLIC_ID policy, and can use characters outside the > reserved > set to distinguish the keys for other POAs. > > I don't want to see a special server required because it is a > slippery > slope. It also smells like yet another naming service in a different > package. Also, it is a barrier to entry for service providers that > want > to provide some particular service that is portable across orbs. > Regards, Ted. X-Authentication-Warning: mcfadden.dialup.dstc.edu.au: mcfadden owned process doing -bs Date: Thu, 7 Oct 1999 00:42:02 +1000 (EST) From: Ted McFadden X-Sender: mcfadden@mcfadden.dialup.dstc.edu.au To: Paul H Kyzivat cc: issues@omg.org, CORE RTF , Interop RTF , Naming FTF Subject: Re: Unclear requirements for support of textual object keys In-Reply-To: <37FB5FF3.895CF7C2@roguewave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Ted McFadden wrote: > > > > I may have missed it, but I can't find a place in the INS spec > > chapters where "NameService" is required. It certainly makes > things > > more convenient and makes for shorter URLs, but that was the > point > > of corbaloc/corbaname. > > I guess you have me in the sense that it is no longer "required". > But as you point out, the corbaloc feature was added as a > generalized > way to support exactly that, and an orb that doesn't support it will > in > general be viewed as degraded. As long as I had some software agent to handle the corbaloc/corbaname, I can't say that I'd view an orb as being degraded. I appreciate that you are not too keen on forwarding agents. > > > > > In the revised naming service chapter, "NameService" is a > default > > key if no key is explicitly specified in a corbaname. Prior to > the > > Sept. 9 document, there was no way to specify a URL with a key > > other than "NameService", now it is possible as corbanames are > > proper extensions of corbalocs. So a server need not have a key > > of "NameService". A vendor could use any proprietary key and end > > up requiring corbnames like: > > > > corbaname://555xyz.com/%23%56%29%11%99%33%22%23/a/b/c > > > > (not that I'd ever like to use a URL like that). > > I agree with you that I'd never want to see a URL like that. It is > no > better than IOR:. It would be very difficult to sell an orb that > required anyone to type such things. > > > > > The only other use of a "NameService" key is in the core chapter > 4. > > Where it is not specifically required either. > > > > An ORB must be configurable so that > > an arbitrary object reference can be set to be any of the > initial > > services. > > > > -ORBInitRef NameService=IOR:45AB..... > > -ORBInitRef NameService=corbaloc://xyz.com/a/b/c > > > > -ORBDefaultInitRef is also provided to allow all initial > services to > > be resolved from a single URL prefix. This would require a key > that > > at least contains "NameService", but only if there is not a > specific > > ORBInitRef. This is a convenience that does not dictate server > keys. > > My point remains - we have for the first time provided a capability > for > clients to create IORs, including the keys they contain. But it is > clear > (from this discussion if nothing else) that then intent of this has > not > been adequately explained. > > - should a conforming implementation of the INS be accessible > via a corbaloc url with the key NameService? It should not have to be. The INS implementation can be advertised anyway the underlying ORB or external forwarding agents support. > > - should an orb be expected to provide a way for a server writer > to make his server available via a corbaloc url? If so, is > (or should there be) a standard way to write the server to do > this? > > - if yes to the above, can the server developer choose the key? > This is a personal opinion: I don't believe the orb should be obligated to provide this. But if it did, for the URLs to be useful, the developer would have to be allowed to select the key. Regards, Ted. Date: Wed, 06 Oct 1999 10:42:59 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Ted McFadden CC: issues@omg.org, CORE RTF , Interop RTF , Naming FTF Subject: Re: Unclear requirements for support of textual object keys X-Priority: 3 (Normal) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: g"Pe9F2l!!j@Wd9;Mb!! Ted McFadden wrote: > > I may have missed it, but I can't find a place in the INS spec > chapters where "NameService" is required. It certainly makes > things > more convenient and makes for shorter URLs, but that was the point > of corbaloc/corbaname. I guess you have me in the sense that it is no longer "required". But as you point out, the corbaloc feature was added as a generalized way to support exactly that, and an orb that doesn't support it will in general be viewed as degraded. > > In the revised naming service chapter, "NameService" is a default > key if no key is explicitly specified in a corbaname. Prior to the > Sept. 9 document, there was no way to specify a URL with a key > other than "NameService", now it is possible as corbanames are > proper extensions of corbalocs. So a server need not have a key > of "NameService". A vendor could use any proprietary key and end > up requiring corbnames like: > > corbaname://555xyz.com/%23%56%29%11%99%33%22%23/a/b/c > > (not that I'd ever like to use a URL like that). I agree with you that I'd never want to see a URL like that. It is no better than IOR:. It would be very difficult to sell an orb that required anyone to type such things. > > The only other use of a "NameService" key is in the core chapter > 4. > Where it is not specifically required either. > > An ORB must be configurable so that > an arbitrary object reference can be set to be any of the initial > services. > > -ORBInitRef NameService=IOR:45AB..... > -ORBInitRef NameService=corbaloc://xyz.com/a/b/c > > -ORBDefaultInitRef is also provided to allow all initial services > to > be resolved from a single URL prefix. This would require a key > that > at least contains "NameService", but only if there is not a > specific > ORBInitRef. This is a convenience that does not dictate server > keys. My point remains - we have for the first time provided a capability for clients to create IORs, including the keys they contain. But it is clear (from this discussion if nothing else) that then intent of this has not been adequately explained. - should a conforming implementation of the INS be accessible via a corbaloc url with the key NameService? - should an orb be expected to provide a way for a server writer to make his server available via a corbaloc url? If so, is (or should there be) a standard way to write the server to do this? - if yes to the above, can the server developer choose the key? Date: Thu, 7 Oct 1999 18:09:55 PDT Sender: Bill Janssen From: Bill Janssen To: Ted McFadden , Paul H Kyzivat Subject: Re: Unclear requirements for support of textual object keys CC: issues@omg.org, CORE RTF , Interop RTF , Naming FTF In-Reply-To: <37FB5FF3.895CF7C2@roguewave.com> References: <37FB5FF3.895CF7C2@roguewave.com> Content-Type: text X-UIDL: pn8!!6&Ce9-4/e9~6$e9 Excerpts from local.omg: 6-Oct-99 Re: Unclear requirements fo.. Paul H Kyzivat@roguewave (2515*) > - should a conforming implementation of the INS be accessible > via a corbaloc url with the key NameService? I certainly hope so. And the quicker someone registers a standard port for NameService the better. Our INS naming service is already out there on port 9999. Bill Date: Fri, 8 Oct 1999 12:28:42 +1000 (AUS Eastern Standard Time) From: Ted McFadden To: Bill Janssen cc: Paul H Kyzivat , issues@omg.org, CORE RTF , Interop RTF , Naming FTF Subject: Re: Unclear requirements for support of textual object keys In-Reply-To: Message-ID: X-X-Sender: mcfadden@piglet.dstc.edu.au MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: !7dd9:"ad9TG8e9-dcd9 On Thu, 7 Oct 1999, Bill Janssen wrote: > Excerpts from local.omg: 6-Oct-99 Re: Unclear requirements fo.. Paul H > Kyzivat@roguewave (2515*) > > > - should a conforming implementation of the INS be accessible > > via a corbaloc url with the key NameService? > > I certainly hope so. And the quicker someone registers a standard port > for NameService the better. Our INS naming service is already out there > on port 9999. > The port application has just been sent to IANA. Regards, Ted. Date: Tue, 12 Oct 1999 18:50:12 +0200 Message-Id: <199910121650.SAA15151@pandora> From: Martin von Loewis To: paulk@roguewave.com CC: mcfadden@dstc.edu.au, issues@omg.org, orb_revision@omg.org, interop@omg.org, naming_ftf@omg.org In-reply-to: <37FB5FF3.895CF7C2@roguewave.com> (message from Paul H Kyzivat on Wed, 06 Oct 1999 10:42:59 -0400) Subject: Re: Unclear requirements for support of textual object keys References: <37FB5FF3.895CF7C2@roguewave.com> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII X-UIDL: bD#!!OP$e9-0C!!4MDe9 > - should a conforming implementation of the INS be accessible > via a corbaloc url with the key NameService? I don't think there is a conformance requirement to that respect, nor do I think there could be (what constitutes the implementation). However, users will certainly expect and require that. Please note that there are at least two ways for such an implementation to operate: A) There could be a proprietary API for generating corbaloc: urls (as you suggest below) B) The name service could be implemented using the standard language mapping, and the bootstrap server could re-locate from the corbaloc url to the root naming context. > - should an orb be expected to provide a way for a server writer > to make his server available via a corbaloc url? If so, is > (or should there be) a standard way to write the server to do > this? INS does not require it, nor does any other part of CORBA currently require it. I don't think there is a need to have a standard API for producing corbaloc urls; over time, experience will tell if this is really necessary. Regards, Martin Sender: jis@fpk.hp.com Message-ID: <380E1A59.8865A7B1@fpk.hp.com> Date: Wed, 20 Oct 1999 15:39:05 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Juergen Boldt CC: issues@emerald.omg.org, orb_revision@emerald.omg.org, interop@emerald.omg.org, naming_ftf@emerald.omg.org Subject: Re: issue 2899 -- Core RTF issue?? References: <4.1.19991020140902.00aa7a80@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: B%Ke9VL > This is issue 2899 > > Unclear requirements for support of textual object keys > > 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: No, primarily an naming FTF issue. Someday it might become a core issue, but not right now, since the Naming submitters have veto rights over the resolution of this issue. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Thu, 21 Oct 1999 19:21:56 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Jishnu Mukerji CC: Juergen Boldt , issues@emerald.omg.org, orb_revision@emerald.omg.org, interop@emerald.omg.org, naming_ftf@emerald.omg.org Subject: Re: issue 2899 -- Core RTF issue?? X-Priority: 3 (Normal) References: <4.1.19991020140902.00aa7a80@emerald.omg.org> <380E1A59.8865A7B1@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %2Wd9J+ad9NoGe9nDI!! Jishnu Mukerji wrote: > > Juergen Boldt wrote: > > > > This is issue 2899 > No, primarily an naming FTF issue. > Someday it might become a core issue, but not > right now, since the Naming submitters have veto rights over the > resolution of this issue. I believe Jishnu's reply ("No, ...") is in response to the title question of whether this is a Core RTF issue. I will accept his judgement on this (I don't think there is any appeal process). So I think Juergen should assign it to the Naming FTF. Reply-To: From: "Martin Chapman" To: "Michi Henning" Cc: "Tally, Gregg" , Subject: RE: Vote 1 draft 4 Date: Thu, 9 Dec 1999 09:49:19 -0000 Message-ID: <000401bf422a$aa1621a0$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 4lX!!$W?e9Tk/, but it is not explicit enough - the current text does not say a call to resolve_initial_reference() results in a url of the form ... I realize this is the intention but the INS text should be clarified (thats what i understood issue 2899 to be) - it also wouldn't harm reapeating this in the iioploc section. There is another slight problem, the firewall proxy is not intended for use by user code (only orb code) therefore we don't really want to be able to r_i_r("FirewallProxy"), but it would still be nice to allocate such an objectid so we can use the schemes above. What would you advise in this case? Martin. > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: 08 December 1999 21:03 > To: Martin Chapman > Cc: Tally, Gregg; firewall-rtf@omg.org > Subject: RE: Vote 1 draft 4 > > > On Wed, 8 Dec 1999, Martin Chapman wrote: > > > However, having checked with the INS spec, it does not mention > at all the > > notion of well known keys, and certainly doesn't recognize an > official list > > of keys - the ones used in the document are just examples. I > don't think its > > in the scope of this RTF to change this. It looks like the INS FTF > is > > rejecting this issue anyway (see: > > http://www.omg.org/issues/naming_ftf.html#Issue2899). So I'm > afraid you are > > left with a vendor specific key for URLs. > > Martin, that's not right. Whatever key can be used for > resolve_initial_references can also be used with INS. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3891 5009 (fax) > Annerley 4103 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html >