Issue 2864: How to obtain initial reference to the GIOPProxy object (firewall-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Description: The specification does not outline a specific method by which to obtain the initial reference to the GIOPProxy object. We believe that an interoperable solution for obtaining this initial reference is needed in order to insure that all implementations will be able to be correctly configured to contact all other implementations. Resolution: Revised Text: Actions taken: August 24, 1999: received issue Discussion: End of Annotations:===== From: "Niebuhr, Brian" To: "'firewall-rtf@omg.org'" Subject: Issue 1 Date: Tue, 24 Aug 1999 22:56:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 47f793195211bffb14c014060985ecfc Issue 1 Description: The specification does not outline a specific method by which to obtain the initial reference to the GIOPProxy object. We believe that an interoperable solution for obtaining this initial reference is needed in order to insure that all implementations will be able to be correctly configured to contact all other implementations. Proposed Solution: We propose that all GIOPProxy objects be required to generate a stringified IOR. Further, any node (ORB or Firewall) which needs to be able to contact a GIOPProxy object should be able to be configured to use a stringified IOR of the GIOPProxy object. This eliminates any ambiguity in the mechanism by which the IOR may be transferred. Specifically, we propose that the statement "If the GIOP Proxy is an outbound one, the ORB should be configured with the IOR of the proxy object. If the GIOP Proxy is an inbound one, the server's IOR should contain the IOR of the proxy object on the firewall" in section 4.7 should be changed to "Each client ORB should be configured with the stringified IOR of the GIOPProxy object on the innermost outbound firewall. Each server ORB should be configured with the stringified IOR of the GIOPProxy object on the outermost inbound firewall. Each firewall can be configured with the stringified IORs of the GIOPProxy objects on the next inbound and outbound firewalls." Date: Tue, 30 Nov 1999 00:03:51 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org Subject: RE: Round 1 - issue 2864 Message-ID: <3322393875.943920231@localhost> In-Reply-To: <001701bf3a6e$650b0da0$4d01020a@leo.dublin.iona.ie> X-Mailer: Mulberry (Win32) [2.0.0b1, s/n P005-300802-002] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: Z+md9'oi!!;08e9Ki2!! --On 29 November 1999 13:34 +0000 Martin Chapman wrote: > Issue 2864: How to obtain initial reference to the GIOPProxy object > (firewall-rtf) > > Click here for this issue's archive. > Nature: Uncategorized Issue > Severity: > Summary: Proxified object references obtained by invoking > Resolution: The issue revoles around whether the spec should use > stringified IORs. IORs by their nature are interoperable so > transmissting > them in the "native" format as opposed to a string format is not an > issue. > Revised Text: None > Actions taken: Close issue. Agreed. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 From: "Whitmore, Brent" To: "'firewall-rtf@omg.org'" Subject: RE: VOTE 1 draft 2 (Issue 2864) Date: Wed, 1 Dec 1999 12:26:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 'Pmd9ZM2e9;1Me9b3$e9 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All: The resolution text of 2864 says: "The issue revoles around whether the spec should use stringified IORs. IORs by their nature are interoperable so transmissting them in the "native" format as opposed to a string format is not an issue." In our view, the issue revolves around how and where firewalls should publish their IORs. The specific questions that we want answered are: 1) In what form does a firewall express its proxy object to ORBs? 2) Where and how does an ORB obtain references to the firewalls with which it interoperates? At the heart of the matter is a chicken-or-egg problem. Compliant firewalls must know about ORBs and ORBs must know about firewalls. In the beginning, neither firewalls nor ORBs know about any ORBs or firewalls, respectively. Consequently, one cannot use IIOP to communicate IORs. Instead, one must rely upon existing communication facilities, e.g., files, web servers, napkins + file editors, to initially configure some subset of the firewalls and IORs. Also, please bear in mind that we really do not want to put any more ORB-like behavior in firewalls than is absolutely necessary. Here's a proposal: Define a firewall mapping for interoperable names. Require compliant firewalls to provide software agents for corbaloc URLs. Define a fixed object key value for the agent, say "fwproxy". Also define a new optional protocol identifier ( in the Interoperable Naming spec's syntax) for SSL/TLS connections with the agent. Call it "iiops". The identifier tells the ORB to establish the connection using IIOP over SSL/TLS. The ORBs contacting the agents must restrict themselves to only making those requests defined by F/W spec for the Firewall Proxy object. This scheme permits us to leverage commonplace DNS and IP machinary and an (mostly) already-specified ORB capability. The agents (or proxy objects) need only respond to Request and LocateRequest messages as per the Interoperable Naming Spec, keeping the ORBishness of firewalls to a minimum. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1 Comment: Crypto Provided by Network Associates iQA/AwUBOEWEV+ASrup3GmIGEQIgCwCfY/9BE5SUrwhr5+hbHc8WIIzEe3EAoPFV w9lZRKfSyRI3xC52BYaMiWo8 =DX9O -----END PGP SIGNATURE----- X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 1 Dec 1999 17:02:26 -0500 (EST) From: Polar Humenn To: "Whitmore, Brent" cc: "'firewall-rtf@omg.org'" Subject: RE: VOTE 1 draft 2 (Issue 2864) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ISpd9CFa!!Va^!!ja$"! On Wed, 1 Dec 1999, Whitmore, Brent wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All: > > The resolution text of 2864 says: "The issue revoles around whether > the spec should use stringified IORs. IORs by their nature are > interoperable so transmissting them in the "native" format as > opposed > to a string format is not an issue." > > In our view, the issue revolves around how and where firewalls > should > publish their IORs. The specific questions that we want answered > are: > > 1) In what form does a firewall express its proxy object to ORBs? > > 2) Where and how does an ORB obtain references to the firewalls with > which it interoperates? > > At the heart of the matter is a chicken-or-egg problem. Compliant > firewalls must know about ORBs and ORBs must know about firewalls. > In the beginning, neither firewalls nor ORBs know about any ORBs or > firewalls, respectively. Consequently, one cannot use IIOP to > communicate IORs. Instead, one must rely upon existing > communication > facilities, e.g., files, web servers, napkins + file editors, to > initially configure some subset of the firewalls and IORs. Also, > please bear in mind that we really do not want to put any more > ORB-like behavior in firewalls than is absolutely necessary. > > Here's a proposal: Define a firewall mapping for interoperable > names. Require compliant firewalls to provide software agents for > corbaloc URLs. Define a fixed object key value for the agent, say > "fwproxy". Also define a new optional protocol identifier > ( > in the Interoperable Naming spec's syntax) for SSL/TLS connections > with the agent. Call it "iiops". The identifier tells the ORB to > establish the connection using IIOP over SSL/TLS. The ORBs > contacting the agents must restrict themselves to only making those > requests defined by F/W spec for the Firewall Proxy object. > > This scheme permits us to leverage commonplace DNS and IP machinary > and an (mostly) already-specified ORB capability. The agents (or > proxy objects) need only respond to Request and LocateRequest > messages as per the Interoperable Naming Spec, keeping the > ORBishness > of firewalls to a minimum. Actually this approach is the wrong way. The INS way of getting any IOR's other than straight IIOP is to use a LOCATION_FORWARD. So you would naming your firewall proxy manager with: corbaloc://fwhost:8888/FireWallProxy and during the request it that host and port will send back a location forward with the correct reference, quite possibly with an SSL component. IOR's are far to complex to develop stringified naming schemes to go above what we have now. Cheers, -Polar > -----BEGIN PGP SIGNATURE----- > Version: PGP 6.5.1 > Comment: Crypto Provided by Network Associates > > iQA/AwUBOEWEV+ASrup3GmIGEQIgCwCfY/9BE5SUrwhr5+hbHc8WIIzEe3EAoPFV > w9lZRKfSyRI3xC52BYaMiWo8 > =DX9O > -----END PGP SIGNATURE----- > ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "Whitmore, Brent" To: "'Polar Humenn'" , "Whitmore, Brent" Cc: "'firewall-rtf@omg.org'" Subject: RE: VOTE 1 draft 2 (Issue 2864) Date: Wed, 1 Dec 1999 15:30:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: QcXd9>1=!!LF?e92fV!! > Actually this approach is the wrong way. > > The INS way of getting any IOR's other than straight IIOP is to use > a > LOCATION_FORWARD. > > So you would naming your firewall proxy manager with: > > corbaloc://fwhost:8888/FireWallProxy > > and during the request it that host and port will send back a > location > forward with the correct reference, quite possibly with an > SSL component. > I think that this was what I was describing, though more from the firewall's point of view than from the ORB's or ORB user's viewpoints. For a non-SSL IOR, this is exactly the string that a developer would pass to ORB::string_to_object to obtain an object reference to the firewall proxy. Using your example with the scheme I described, the ORB would answer a reference for the firewall proxy object on the firewall host "fwhost" that is listening on port 8888 of that host. The client ORB expects to communicate with that proxy object using a non-SSL connection. > IOR's are far to complex to develop stringified naming > schemes to go above > what we have now. The only change to current naming schemes that I am suggesting is to permit "iiops" as well as "iiop" as a protocol qualifier in the existing syntax. So the URL to pass to ORB::string_to_object when one wants an SSL connection for talking to the firewall proxy in the example above would be: corbaloc:iiops:fwhost:8888/FireWallProxy I got the syntax part wrong in my initial post, BTW. I really mean to suggest that we alter the URL syntax so that = "iiop" | "iiops" in 13.6.7.1 paragraph 4 on p. 13-85 of the CORBA 2.3 spec, as well as in 13.6.7.2 para. 1 at the top of p. 13-87. (Note that the examples do not always match the syntax description in this section of the spec.) Also, change the comment in 13.6.7.2, para. 2 under the entry for "port:" on p. 13-87, to direct assignment of different default ports depending on whether the iiop id is "iiop:", "//", or "iiops:". > > Cheers, > -Polar > Likewise! - Brent X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 1 Dec 1999 18:53:36 -0500 (EST) From: Polar Humenn To: "Whitmore, Brent" cc: "'firewall-rtf@omg.org'" Subject: RE: VOTE 1 draft 2 (Issue 2864) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 7[Fe9UZD!!a$Xd9&-[!! Brent, I can see your problem, I think. Is the thing that you are looking for is a "secure" way to bootstrap the firewall proxy? In my scenario the level of trust is equivalent to use a straight IIOP INS name and wait for the LCOATION_FORWARD to come about with the proper IOR. The fact is that you cannot even "trust" the reference you could construct from the "iiops:host:999/objectkey" specification, because the port number itself is not sufficient for trust, and because the ORB behind this INS reference also can hand over a location forward. It is always up to the client ORB to verify the final credentials of the target, which is in this case the proxy manager. The fact that the "initial" LOCATION_FORWARD comes from an "insecure" source, doesn't mean it is not "trusted" to some degree. In anycase, it is the final end connection to the target object that is paramount. This situation is analogous to having a key to a door, and getting the address of that door deliivered by some raggy not so clean looking individual with platypus on a leash. What does it matter, as opposed to getting the address delivered by some government courier with a top secret clearance? If your key opens up the door, what does it matter how you came about the address of the door? Regards, -Polar On Wed, 1 Dec 1999, Whitmore, Brent wrote: > > > Actually this approach is the wrong way. > > > > The INS way of getting any IOR's other than straight IIOP is to > use a > > LOCATION_FORWARD. > > > > So you would naming your firewall proxy manager with: > > > > corbaloc://fwhost:8888/FireWallProxy > > > > and during the request it that host and port will send back a > location > > forward with the correct reference, quite possibly with an > > SSL component. > > > > I think that this was what I was describing, though more from the > firewall's > point of view than from the ORB's or ORB user's viewpoints. For a > non-SSL > IOR, this is exactly the string that a developer would pass to > ORB::string_to_object to obtain an object reference to the firewall > proxy. > Using your example with the scheme I described, the ORB would answer > a > reference for the firewall proxy object on the firewall host > "fwhost" that > is listening on port 8888 of that host. The client ORB expects to > communicate with that proxy object using a non-SSL connection. > > > IOR's are far to complex to develop stringified naming > > schemes to go above > > what we have now. > > The only change to current naming schemes that I am suggesting is to > permit > "iiops" as well as "iiop" as a protocol qualifier in the existing > syntax. > So the URL to pass to ORB::string_to_object when one wants an SSL > connection > for talking to the firewall proxy in the example above would be: > > corbaloc:iiops:fwhost:8888/FireWallProxy > > I got the syntax part wrong in my initial post, BTW. I really mean > to > suggest that we alter the URL syntax so that > > = "iiop" | "iiops" > > in 13.6.7.1 paragraph 4 on p. 13-85 of the CORBA 2.3 spec, as well > as in > 13.6.7.2 para. 1 at the top of p. 13-87. (Note that the examples do > not > always match the syntax description in this section of the spec.) > Also, > change the comment in 13.6.7.2, para. 2 under the entry for "port:" > on p. > 13-87, to direct assignment of different default ports depending on > whether > the iiop id is "iiop:", "//", or "iiops:". > > > > > Cheers, > > -Polar > > > > Likewise! > - Brent > ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: From: "Martin Chapman" To: "Whitmore, Brent" , Subject: RE: VOTE 1 draft 2 (Issue 2864) Date: Thu, 2 Dec 1999 11:37:59 -0000 Message-ID: <000801bf3cb9$aee32000$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 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: AXNe9Oh)!![>W!!jQ+e9 A iiops prefix would in my mind mean establishing an IIOP/SSL connection to the location agent. It will reply with an IOR that may or may not have an SSL tag in it. I'm not against the iiops per see (i haven't thought about it enough to love or hate the idea yet), though I'd like to point out two things 1) I don't see how it solves your problem and 2) I don't think this is the right place to do it - it looks more like an INS FTF issue, so I would be inclined to rule the iiops proposal out of scope. What we might be able to do (i'll check with those that know) is propose a new reserved object_key as you suggested. Then I can see that you could build a small locater in a firewall that only speaks iiop and rejects anything other than "FireWallProxy". Martin. > -----Original Message----- > From: Whitmore, Brent [mailto:Brent_Whitmore@NAI.com] > Sent: 01 December 1999 23:30 > To: 'Polar Humenn'; Whitmore, Brent > Cc: 'firewall-rtf@omg.org' > Subject: RE: VOTE 1 draft 2 (Issue 2864) > > > > > Actually this approach is the wrong way. > > > > The INS way of getting any IOR's other than straight IIOP is to > use a > > LOCATION_FORWARD. > > > > So you would naming your firewall proxy manager with: > > > > corbaloc://fwhost:8888/FireWallProxy > > > > and during the request it that host and port will send back a > location > > forward with the correct reference, quite possibly with an > > SSL component. > > > > I think that this was what I was describing, though more from the > firewall's > point of view than from the ORB's or ORB user's viewpoints. For a > non-SSL > IOR, this is exactly the string that a developer would pass to > ORB::string_to_object to obtain an object reference to the firewall > proxy. > Using your example with the scheme I described, the ORB would answer > a > reference for the firewall proxy object on the firewall host > "fwhost" that > is listening on port 8888 of that host. The client ORB expects to > communicate with that proxy object using a non-SSL connection. > > > IOR's are far to complex to develop stringified naming > > schemes to go above > > what we have now. > > The only change to current naming schemes that I am suggesting is > to permit > "iiops" as well as "iiop" as a protocol qualifier in the existing > syntax. > So the URL to pass to ORB::string_to_object when one wants an SSL > connection > for talking to the firewall proxy in the example above would be: > > corbaloc:iiops:fwhost:8888/FireWallProxy > > I got the syntax part wrong in my initial post, BTW. I really mean > to > suggest that we alter the URL syntax so that > > = "iiop" | "iiops" > > in 13.6.7.1 paragraph 4 on p. 13-85 of the CORBA 2.3 spec, as well > as in > 13.6.7.2 para. 1 at the top of p. 13-87. (Note that the examples do > not > always match the syntax description in this section of the spec.) > Also, > change the comment in 13.6.7.2, para. 2 under the entry for "port:" > on p. > 13-87, to direct assignment of different default ports depending > on whether > the iiop id is "iiop:", "//", or "iiops:". > > > > > Cheers, > > -Polar > > > > Likewise! > - Brent > From: "Whitmore, Brent" To: firewall-rtf@omg.org Subject: RE: VOTE 1 draft 2 (Issue 2864) Date: Thu, 2 Dec 1999 10:04:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ~Pf!!4fTd9f%~e9*]Yd9 > -----Original Message----- > From: Martin Chapman [mailto:mchapman@iona.com] > Sent: Thursday, December 02, 1999 6:38 AM > To: Whitmore, Brent; firewall-rtf@omg.org > Subject: RE: VOTE 1 draft 2 (Issue 2864) > (snip) > > > What we might be able to do (i'll check with those that > know) is propose a > new reserved object_key as you suggested. Then I can see that > you could > build a small locater in a firewall that only speaks iiop and > rejects > anything other than "FireWallProxy". > > Martin. > I think that doing this addresses our concerns on this point sufficiently. Thanks, all. Regards, Brent Reply-To: From: "Martin Chapman" To: "Whitmore, Brent" , Subject: RE: VOTE 1 draft 2 (Issue 2864) Date: Fri, 3 Dec 1999 14:20:12 -0000 Message-ID: <000801bf3d99$83269e20$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 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: )ffd9R -----Original Message----- > From: Whitmore, Brent [mailto:Brent_Whitmore@NAI.com] > Sent: 02 December 1999 18:05 > To: firewall-rtf@omg.org > Subject: RE: VOTE 1 draft 2 (Issue 2864) > > > > > > -----Original Message----- > > From: Martin Chapman [mailto:mchapman@iona.com] > > Sent: Thursday, December 02, 1999 6:38 AM > > To: Whitmore, Brent; firewall-rtf@omg.org > > Subject: RE: VOTE 1 draft 2 (Issue 2864) > > > (snip) > > > > > > What we might be able to do (i'll check with those that > > know) is propose a > > new reserved object_key as you suggested. Then I can see that > > you could > > build a small locater in a firewall that only speaks iiop and > rejects > > anything other than "FireWallProxy". > > > > Martin. > > > > I think that doing this addresses our concerns on this point > sufficiently. > > Thanks, all. > > Regards, > Brent > Reply-To: From: "Martin Chapman" To: "Tally, Gregg" , Subject: RE: Vote 1 draft 4 Date: Wed, 8 Dec 1999 10:01:55 -0000 Message-ID: <001001bf4163$421e1a20$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: 7&Le9X4g!!H!md9`o#e9 On issue 2864, it is a vendor's reposnsiblity to come up with a mechanism to publish IORs for its services. No other spec mandataes how this should be done. The INS spec however introduced a generic mechanism to bootstrap services, and as previously discused, it would be acceptable for us to reserve a well known key for GIOP Proxy objects, for use in corba urls. 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. > -----Original Message----- > From: Tally, Gregg [mailto:Gregg_Tally@NAI.com] > Sent: 07 December 1999 22:25 > To: 'mchapman@iona.com'; firewall-rtf@omg.org > Subject: RE: Vote 1 draft 4 > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This vote applies to the 4th version of Vote 1 on the Firewall RTF > issues. > > Company: TIS Labs @ Network Associates > Voter: Gregg Tally > > Issue Yes/No/Abstain > 1996 Yes > 2240 Yes > 2261 No > 2304 Yes > 2455 Yes > 2633 Yes > 2634 Yes > 2864 No > > Regarding 2864, we feel that the issue is not just stringified vs. > native format IORs. Rather, we believe that the specification > should > state that a firewall must publish the IOR for a GIOPProxy object, > and should state the means for doing so. Otherwise, a compliant > firewall is not required to publish the IOR at all and that does not > seem to be interoperable. > > Gregg Tally > NAI Labs - Network Associates > 3060 Washington Road > Glenwood MD 21738 > V: 443-259-2329 F: 301-854-4731 > > -----BEGIN PGP SIGNATURE----- > Version: PGP 6.5.1 > Comment: Crypto Provided by Network Associates > > iQA/AwUBOE2JgnHzTGgl/063EQJc/QCfQKMCkSXUeBHLmTe/oZvEEHyRRIcAoJmF > BOyrtnRB3M9/1No0tRlDm1wi > =qkag > -----END PGP SIGNATURE----- > Date: Wed, 08 Dec 1999 12:45:01 +0000 From: Owen Rees To: mchapman@iona.com, "Tally, Gregg" , firewall-rtf@omg.org Subject: RE: Vote 1 draft 4 - issue 2864 Message-ID: <4059263504.944657101@ews-proj-2.hpl.hp.com> In-Reply-To: <001001bf4163$421e1a20$4d01020a@leo.dublin.iona.ie> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: ,Dld9RJ4!!<-2!!)da!! --On 08 December 1999, 10:01 +0000 Martin Chapman wrote: > On issue 2864, it is a vendor's reposnsiblity to come up with a mechanism > to publish IORs for its services. No other spec mandataes how this should > be done. The INS spec however introduced a generic mechanism to bootstrap > services, and as previously discused, it would be acceptable for us to > reserve a well known key for GIOP Proxy objects, for use in corba urls. > > 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. > The INS spec as I last saw it mandated a mechanism to configure an ORB to cause some given IOR to be returned out of "resolve_initial_references", it did not require that a name service publish an IOR that could be used in that way. Some of what seems to be the more controversial stuff ('clients' inventing IORs, URL-like IORs, fixed object keys etc.) is, as I understand it, there, at least in part, to make it possible to configure a client to use a name service that *has not* published its IOR. On reflection, I think we may be looking at the wrong end of the problem with this issue, or at least not enough of the overall problem. Having an IOR for any relevant GIOP proxy is necessary if and only if there is some configuration mechanism into which you must feed it. As far as I can see, there is no specified way to configure an ORB to know about the firewall proxies. An ORB supporting a server needs a list of inbound firewall proxy data (to be inserted into the IORs its POAs will create when appropriate). An ORB supporting a client needs to be configured to know about outbound proxies (I am not sure innermost is enough with nested proxies chosen from TCP, SOCKS, GIOP in all possible combinations). If we do not standardise this ORB configuration mechanism, I don't see the point of standardising what data proxies deliver for use in configuring ORBs (and other proxies). Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Reply-To: From: "Martin Chapman" To: "Owen Rees" , "Tally, Gregg" , Subject: RE: Vote 1 draft 4 - issue 2864 Date: Wed, 8 Dec 1999 14:55:23 -0000 Message-ID: <000201bf418c$4179ee40$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: <4059263504.944657101@ews-proj-2.hpl.hp.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3S$!!o&n!!p"M!!c!:!! > -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: 08 December 1999 12:45 > To: mchapman@iona.com; Tally, Gregg; firewall-rtf@omg.org > Subject: RE: Vote 1 draft 4 - issue 2864 > > > --On 08 December 1999, 10:01 +0000 Martin Chapman > wrote: > > > On issue 2864, it is a vendor's reposnsiblity to come up with a > mechanism > > to publish IORs for its services. No other spec mandataes how > this should > > be done. The INS spec however introduced a generic mechanism to > bootstrap > > services, and as previously discused, it would be acceptable for > us to > > reserve a well known key for GIOP Proxy objects, for use in corba > urls. > > > > 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. > > > > The INS spec as I last saw it mandated a mechanism to configure an > ORB to > cause some given IOR to be returned out of > "resolve_initial_references", it > did not require that a name service publish an IOR that could be > used in > that way. True. > > Some of what seems to be the more controversial stuff ('clients' > inventing > IORs, URL-like IORs, fixed object keys etc.) is, as I understand > it, there, > at least in part, to make it possible to configure a client to use a > name > service that *has not* published its IOR. Correct. there are features defined for a "mini" name service - given only a host name you can send locaterequests with well known keys to this agent. > > On reflection, I think we may be looking at the wrong end of the problem > with this issue, or at least not enough of the overall problem. > > Having an IOR for any relevant GIOP proxy is necessary if and > only if there > is some configuration mechanism into which you must feed it. Agreed. > > As far as I can see, there is no specified way to configure an ORB > to know > about the firewall proxies. An ORB supporting a server needs a list > of > inbound firewall proxy data (to be inserted into the IORs its POAs > will > create when appropriate). An ORB supporting a client needs to be > configured > to know about outbound proxies (I am not sure innermost is enough > with > nested proxies chosen from TCP, SOCKS, GIOP in all possible > combinations). Agreed > > If we do not standardise this ORB configuration mechanism, I don't > see the > point of standardising what data proxies deliver for use in > configuring > ORBs (and other proxies). The original submitters agreed not to adrress this in the spec, since it is much more broader than just firewall config. Doing this in an RTF may upset some of the original submitters with veto power. Martin.