Issue 3565: ORB throwing exception if it finds unknown service context (interop) Source: UBS (Urs Kuenzler, urs.kuenzler(at)ubs.com) Nature: Uncategorized Issue Severity: Summary: Why does it make sense at all to allow an ORB to throw an exception if it finds a service context it does not "understand"? This is not very helpful for interoperability. Would a sending ORB have to handle this exception and resend the same request without context to allow to interoperate with an ORB throwing BAD_PARAM in this case? If an unknown service context is sent with a reply, the receiving ORB would throw BAD_PARAM at the caller (even if it got a valid reply). The originator of the service context wouldn't even know. Resolution: To close with Issue 3561 resolution to eliminate option of throwing exception Revised Text: Resolved by revision proposed in Issue 3561. Actions taken: April 14, 2000: received issue October 4, 2000: closed issue Discussion: Allowing an ORB to throw an exception for unknown service contexts causes difficulties when interceptors are used. End of Annotations:===== From: urs.kuenzler@ubs.com Disposition-Notification-To: urs.kuenzler@ubs.com X-OpenMail-Hops: 2 Date: Fri, 14 Apr 2000 08:46:12 +0200 Message-Id: Subject: RE: Wrong minor code specified in Chapter 13 MIME-Version: 1.0 TO: interop@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 14 Apr 2000 08:46:12 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 14 Apr 2000 08:46:12 +0200" X-UIDL: l4&e9G\L!!K#Rd9 Date: Fri, 14 Apr 2000 13:08:07 -0500 Subject: Issue 3565 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id OAA00553 Content-Type: text/plain; charset=iso-8859-1 X-UIDL: ,#ad90N To: interop@omg.org Cc: interceptors-ftf@omg.org Subject: RE: Issue 3565 proposal Date: Fri, 14 Apr 2000 19:20:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: JD0!!oR+e9/X_!!an*e9 Status: U In general I agree with your proposal. But I think your text implies another issue that I don't think has been discussed: If a service context is recognized as well defined for the version of giop being used, including some standard semantics for how it should be processed, should it also be made available to interceptors? The answer could be YES, NO, or UNDEFINED. I don't off hand see any particularly strong arguments for either YES or NO. What do others think? Paul > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Friday, April 14, 2000 2:08 PM > To: interop@omg.org > Cc: interceptors-ftf@omg.org > Subject: Issue 3565 proposal > > > > > This is an interop issue, but it definitely affects interceptors, so I > cc'ed interceptors-ftf. The problem is that the following > text from the > spec says unknown service contexts can be ignored or an > exception can be > thrown. Can anyone explain why this is necessary? It breaks > interceptors > since portable, non-standard interceptors can have their own service > context ids that no ORB will recognize. > > ---------------------- > Service context IDs are associated with a specific version of > GIOP, but > will always be > allocated in the OMG service context range. This allows any ORB to > recognize when > it is receiving a standard service context, even if it has > been defined in > a version of > GIOP that it does not support. > > The following are the rules for processing a received service context: > ? The service context is in the OMG defined range: > ? If it is valid for the supported GIOP version, then it must be > processed correctly > according to the rules associated with it for that GIOP > version level. > ? If it is not valid for the GIOP version, then it may be > ignored by the > receiving > ORB, however it must be passed on through a bridge. No > exception shall > be > raised. > > ? The service context is not in the OMG-defined range: > ? The receiving ORB may choose to ignore it, process it if it > ?understands? it, or > raise a system exception, however it must be passed on through a > bridge. If a > system exception is raised, it shall be BAD_PARAM with an > OMG standard > minor code of 1. > ---------------------- > > Here's a proposed replacement of the above text that I > believe satisfies > the interceptor issue. I'm not positive whether it satisfies > the broader, > interoperability issue. > > ---------------------- > OMG-defined service context IDs are associated with a > specific version of > GIOP, > but will always be allocated in the OMG service context > range. This allows > any ORB > to recognize when it is receiving a standard service context, > even if it > has been > defined in a version of GIOP that it does not support. > > The following are the rules for processing a received service context: > - If it is valid for the supported GIOP version, then it must > be processed > correctly > according to the rules associated with it for that GIOP version level. > - If it is not valid for the GIOP version, or if it is not in the > OMG-defined range, > then it shall be retained by the receiving ORB for interceptors and > bridges. The > ORB does not need to process it other than passing it on > through a bridge > and > making it available to interceptors. > ---------------------- > > > Russell Butek > butek@us.ibm.com > > From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAB32542; Mon, 17 Apr 2000 08:41:42 -0500 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id IAA27754; Mon, 17 Apr 2000 08:50:19 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568C4.0046843E ; Mon, 17 Apr 2000 08:50:13 -0400 X-Lotus-FromDomain: IBMUS To: Paul Kyzivat cc: interop@omg.org, interceptors-ftf@omg.org Message-ID: <852568C4.00460347.00@d54mta08.raleigh.ibm.com> Date: Mon, 17 Apr 2000 07:35:33 -0500 Subject: RE: Issue 3565 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: '-~e9?^C!!FBhd9*~)!! Status: U Russell Butek butek@us.ibm.com Paul Kyzivat on 04/14/2000 06:20:52 PM To: interop@omg.org cc: interceptors-ftf@omg.org Subject: RE: Issue 3565 proposal In general I agree with your proposal. But I think your text implies another issue that I don't think has been discussed: If a service context is recognized as well defined for the version of giop being used, including some standard semantics for how it should be processed, should it also be made available to interceptors? The answer could be YES, NO, or UNDEFINED. I don't off hand see any particularly strong arguments for either YES or NO. What do others think? Paul > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Friday, April 14, 2000 2:08 PM > To: interop@omg.org > Cc: interceptors-ftf@omg.org > Subject: Issue 3565 proposal > > > > > This is an interop issue, but it definitely affects interceptors, so I > cc'ed interceptors-ftf. The problem is that the following > text from the > spec says unknown service contexts can be ignored or an > exception can be > thrown. Can anyone explain why this is necessary? It breaks > interceptors > since portable, non-standard interceptors can have their own service > context ids that no ORB will recognize. > > ---------------------- > Service context IDs are associated with a specific version of > GIOP, but > will always be > allocated in the OMG service context range. This allows any ORB to > recognize when > it is receiving a standard service context, even if it has > been defined in > a version of > GIOP that it does not support. > > The following are the rules for processing a received service context: > ? The service context is in the OMG defined range: > ? If it is valid for the supported GIOP version, then it must be > processed correctly > according to the rules associated with it for that GIOP > version level. > ? If it is not valid for the GIOP version, then it may be > ignored by the > receiving > ORB, however it must be passed on through a bridge. No > exception shall > be > raised. > > ? The service context is not in the OMG-defined range: > ? The receiving ORB may choose to ignore it, process it if it > ?understands? it, or > raise a system exception, however it must be passed on through a > bridge. If a > system exception is raised, it shall be BAD_PARAM with an > OMG standard > minor code of 1. > ---------------------- > > Here's a proposed replacement of the above text that I > believe satisfies > the interceptor issue. I'm not positive whether it satisfies > the broader, > interoperability issue. > > ---------------------- > OMG-defined service context IDs are associated with a > specific version of > GIOP, > but will always be allocated in the OMG service context > range. This allows > any ORB > to recognize when it is receiving a standard service context, > even if it > has been > defined in a version of GIOP that it does not support. > > The following are the rules for processing a received service context: > - If it is valid for the supported GIOP version, then it must > be processed > correctly > according to the rules associated with it for that GIOP version level. > - If it is not valid for the GIOP version, or if it is not in the > OMG-defined range, > then it shall be retained by the receiving ORB for interceptors and > bridges. The > ORB does not need to process it other than passing it on > through a bridge > and > making it available to interceptors. > ---------------------- > > > Russell Butek > butek@us.ibm.com > > From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA38768; Mon, 17 Apr 2000 08:51:51 -0500 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id JAA35634; Mon, 17 Apr 2000 09:00:31 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568C4.00477461 ; Mon, 17 Apr 2000 09:00:28 -0400 X-Lotus-FromDomain: IBMUS To: Paul Kyzivat cc: interop@omg.org, interceptors-ftf@omg.org Message-ID: <852568C4.0047723D.00@d54mta08.raleigh.ibm.com> Date: Mon, 17 Apr 2000 07:51:14 -0500 Subject: RE: Issue 3565 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: Jl on 04/14/2000 06:20:52 PM To: interop@omg.org cc: interceptors-ftf@omg.org Subject: RE: Issue 3565 proposal In general I agree with your proposal. But I think your text implies another issue that I don't think has been discussed: If a service context is recognized as well defined for the version of giop being used, including some standard semantics for how it should be processed, should it also be made available to interceptors? The answer could be YES, NO, or UNDEFINED. I don't off hand see any particularly strong arguments for either YES or NO. What do others think? Paul > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Friday, April 14, 2000 2:08 PM > To: interop@omg.org > Cc: interceptors-ftf@omg.org > Subject: Issue 3565 proposal > > > > > This is an interop issue, but it definitely affects interceptors, so I > cc'ed interceptors-ftf. The problem is that the following > text from the > spec says unknown service contexts can be ignored or an > exception can be > thrown. Can anyone explain why this is necessary? It breaks > interceptors > since portable, non-standard interceptors can have their own service > context ids that no ORB will recognize. > > ---------------------- > Service context IDs are associated with a specific version of > GIOP, but > will always be > allocated in the OMG service context range. This allows any ORB to > recognize when > it is receiving a standard service context, even if it has > been defined in > a version of > GIOP that it does not support. > > The following are the rules for processing a received service context: > ? The service context is in the OMG defined range: > ? If it is valid for the supported GIOP version, then it must be > processed correctly > according to the rules associated with it for that GIOP > version level. > ? If it is not valid for the GIOP version, then it may be > ignored by the > receiving > ORB, however it must be passed on through a bridge. No > exception shall > be > raised. > > ? The service context is not in the OMG-defined range: > ? The receiving ORB may choose to ignore it, process it if it > ?understands? it, or > raise a system exception, however it must be passed on through a > bridge. If a > system exception is raised, it shall be BAD_PARAM with an > OMG standard > minor code of 1. > ---------------------- > > Here's a proposed replacement of the above text that I > believe satisfies > the interceptor issue. I'm not positive whether it satisfies > the broader, > interoperability issue. > > ---------------------- > OMG-defined service context IDs are associated with a > specific version of > GIOP, > but will always be allocated in the OMG service context > range. This allows > any ORB > to recognize when it is receiving a standard service context, > even if it > has been > defined in a version of GIOP that it does not support. > > The following are the rules for processing a received service context: > - If it is valid for the supported GIOP version, then it must > be processed > correctly > according to the rules associated with it for that GIOP version level. > - If it is not valid for the GIOP version, or if it is not in the > OMG-defined range, > then it shall be retained by the receiving ORB for interceptors and > bridges. The > ORB does not need to process it other than passing it on > through a bridge > and > making it available to interceptors. > ---------------------- > > > Russell Butek > butek@us.ibm.com > > From: Paul Kyzivat To: interop@omg.org, interceptors-ftf@omg.org Subject: RE: Issue 3565 proposal Date: Mon, 17 Apr 2000 13:13:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: &,A!!8,R!!Y_!!!?#]!! > As the Interceptor specs stands right now, the answer to your > question is YES. Is that a problem? I am not sure if it is a problem - probably not, as long as everyone agrees. What I had in mind were SCs that must be processed in a special way. One that clearly falls in this category is the CodeSet SC. The orb must do something special with it. The question is, must the orb also make it available for regular interceptors? I think there may be others in RT Corba and possibly messaging that may have similar issues. There probably are others like this. There may also be issues on the sending end. There may be rules for some service contexts - e.g., that they should only be sent once per connection. If the orb is taking responsibility for sending them when required, should it permit interceptors to also insert these scs into requests? Paul > > I don't see how we can restrict access to service contexts > because it may be interceptors that handle each service context. > > Russell Butek > butek@us.ibm.com > > > Paul Kyzivat on 04/14/2000 06:20:52 PM > > To: interop@omg.org > cc: interceptors-ftf@omg.org > Subject: RE: Issue 3565 proposal > > > > > In general I agree with your proposal. > > But I think your text implies another issue that I don't > think has been > discussed: > > If a service context is recognized as well defined for the > version of giop > being used, including some standard semantics for how it should be > processed, > should it also be made available to interceptors? The answer > could be YES, > NO, or UNDEFINED. I don't off hand see any particularly > strong arguments > for > either YES or NO. > > What do others think? > > Paul > > > -----Original Message----- > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > Sent: Friday, April 14, 2000 2:08 PM > > To: interop@omg.org > > Cc: interceptors-ftf@omg.org > > Subject: Issue 3565 proposal > > > > > > > > > > This is an interop issue, but it definitely affects > interceptors, so I > > cc'ed interceptors-ftf. The problem is that the following > > text from the > > spec says unknown service contexts can be ignored or an > > exception can be > > thrown. Can anyone explain why this is necessary? It breaks > > interceptors > > since portable, non-standard interceptors can have their own service > > context ids that no ORB will recognize. > > > > ---------------------- > > Service context IDs are associated with a specific version of > > GIOP, but > > will always be > > allocated in the OMG service context range. This allows any ORB to > > recognize when > > it is receiving a standard service context, even if it has > > been defined in > > a version of > > GIOP that it does not support. > > > > The following are the rules for processing a received > service context: > > ? The service context is in the OMG defined range: > > ? If it is valid for the supported GIOP version, then it must be > > processed correctly > > according to the rules associated with it for that GIOP > > version level. > > ? If it is not valid for the GIOP version, then it may be > > ignored by the > > receiving > > ORB, however it must be passed on through a bridge. No > > exception shall > > be > > raised. > > > > ? The service context is not in the OMG-defined range: > > ? The receiving ORB may choose to ignore it, process it if it > > ?understands? it, or > > raise a system exception, however it must be passed on through a > > bridge. If a > > system exception is raised, it shall be BAD_PARAM with an > > OMG standard > > minor code of 1. > > ---------------------- > > > > Here's a proposed replacement of the above text that I > > believe satisfies > > the interceptor issue. I'm not positive whether it satisfies > > the broader, > > interoperability issue. > > > > ---------------------- > > OMG-defined service context IDs are associated with a > > specific version of > > GIOP, > > but will always be allocated in the OMG service context > > range. This allows > > any ORB > > to recognize when it is receiving a standard service context, > > even if it > > has been > > defined in a version of GIOP that it does not support. > > > > The following are the rules for processing a received > service context: > > - If it is valid for the supported GIOP version, then it must > > be processed > > correctly > > according to the rules associated with it for that GIOP > version level. > > - If it is not valid for the GIOP version, or if it is not in the > > OMG-defined range, > > then it shall be retained by the receiving ORB for interceptors and > > bridges. The > > ORB does not need to process it other than passing it on > > through a bridge > > and > > making it available to interceptors. > > ---------------------- > > > > > > Russell Butek > > butek@us.ibm.com > > > > > > > From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA32742; Mon, 17 Apr 2000 13:38:30 -0500 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id NAA43992; Mon, 17 Apr 2000 13:50:33 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568C4.0061FD03 ; Mon, 17 Apr 2000 13:50:17 -0400 X-Lotus-FromDomain: IBMUS To: Paul Kyzivat cc: interop@omg.org, interceptors-ftf@omg.org Message-ID: <852568C4.006106CC.00@d54mta08.raleigh.ibm.com> Date: Mon, 17 Apr 2000 12:30:37 -0500 Subject: RE: Issue 3565 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: L3Z!!j,dd9ZUY!!K~3!! I personally think all service contexts should be available to interceptors. I'd like to hear other viewpoints. You're asking another question here, too. Are interceptors permitted to insert ORB-related scs into requests? As the Interceptor spec stands today, the answer is YES. Russell Butek butek@us.ibm.com Paul Kyzivat on 04/17/2000 12:13:23 PM To: interop@omg.org, interceptors-ftf@omg.org cc: Subject: RE: Issue 3565 proposal > As the Interceptor specs stands right now, the answer to your > question is YES. Is that a problem? I am not sure if it is a problem - probably not, as long as everyone agrees. What I had in mind were SCs that must be processed in a special way. One that clearly falls in this category is the CodeSet SC. The orb must do something special with it. The question is, must the orb also make it available for regular interceptors? I think there may be others in RT Corba and possibly messaging that may have similar issues. There probably are others like this. There may also be issues on the sending end. There may be rules for some service contexts - e.g., that they should only be sent once per connection. If the orb is taking responsibility for sending them when required, should it permit interceptors to also insert these scs into requests? Paul > > I don't see how we can restrict access to service contexts > because it may be interceptors that handle each service context. > > Russell Butek > butek@us.ibm.com > > > Paul Kyzivat on 04/14/2000 06:20:52 PM > > To: interop@omg.org > cc: interceptors-ftf@omg.org > Subject: RE: Issue 3565 proposal > > > > > In general I agree with your proposal. > > But I think your text implies another issue that I don't > think has been > discussed: > > If a service context is recognized as well defined for the > version of giop > being used, including some standard semantics for how it should be > processed, > should it also be made available to interceptors? The answer > could be YES, > NO, or UNDEFINED. I don't off hand see any particularly > strong arguments > for > either YES or NO. > > What do others think? > > Paul > > > -----Original Message----- > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > Sent: Friday, April 14, 2000 2:08 PM > > To: interop@omg.org > > Cc: interceptors-ftf@omg.org > > Subject: Issue 3565 proposal > > > > > > > > > > This is an interop issue, but it definitely affects > interceptors, so I > > cc'ed interceptors-ftf. The problem is that the following > > text from the > > spec says unknown service contexts can be ignored or an > > exception can be > > thrown. Can anyone explain why this is necessary? It breaks > > interceptors > > since portable, non-standard interceptors can have their own service > > context ids that no ORB will recognize. > > > > ---------------------- > > Service context IDs are associated with a specific version of > > GIOP, but > > will always be > > allocated in the OMG service context range. This allows any ORB to > > recognize when > > it is receiving a standard service context, even if it has > > been defined in > > a version of > > GIOP that it does not support. > > > > The following are the rules for processing a received > service context: > > ? The service context is in the OMG defined range: > > ? If it is valid for the supported GIOP version, then it must be > > processed correctly > > according to the rules associated with it for that GIOP > > version level. > > ? If it is not valid for the GIOP version, then it may be > > ignored by the > > receiving > > ORB, however it must be passed on through a bridge. No > > exception shall > > be > > raised. > > > > ? The service context is not in the OMG-defined range: > > ? The receiving ORB may choose to ignore it, process it if it > > ?understands? it, or > > raise a system exception, however it must be passed on through a > > bridge. If a > > system exception is raised, it shall be BAD_PARAM with an > > OMG standard > > minor code of 1. > > ---------------------- > > > > Here's a proposed replacement of the above text that I > > believe satisfies > > the interceptor issue. I'm not positive whether it satisfies > > the broader, > > interoperability issue. > > > > ---------------------- > > OMG-defined service context IDs are associated with a > > specific version of > > GIOP, > > but will always be allocated in the OMG service context > > range. This allows > > any ORB > > to recognize when it is receiving a standard service context, > > even if it > > has been > > defined in a version of GIOP that it does not support. > > > > The following are the rules for processing a received > service context: > > - If it is valid for the supported GIOP version, then it must > > be processed > > correctly > > according to the rules associated with it for that GIOP > version level. > > - If it is not valid for the GIOP version, or if it is not in the > > OMG-defined range, > > then it shall be retained by the receiving ORB for interceptors and > > bridges. The > > ORB does not need to process it other than passing it on > > through a bridge > > and > > making it available to interceptors. > > ---------------------- > > > > > > Russell Butek > > butek@us.ibm.com > > > > > > > From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA32742; Mon, 17 Apr 2000 13:38:30 -0500 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id NAA43992; Mon, 17 Apr 2000 13:50:33 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568C4.0061FD03 ; Mon, 17 Apr 2000 13:50:17 -0400 X-Lotus-FromDomain: IBMUS To: Paul Kyzivat cc: interop@omg.org, interceptors-ftf@omg.org Message-ID: <852568C4.006106CC.00@d54mta08.raleigh.ibm.com> Date: Mon, 17 Apr 2000 12:30:37 -0500 Subject: RE: Issue 3565 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: L3Z!!j,dd9ZUY!!K~3!! I personally think all service contexts should be available to interceptors. I'd like to hear other viewpoints. You're asking another question here, too. Are interceptors permitted to insert ORB-related scs into requests? As the Interceptor spec stands today, the answer is YES. Russell Butek butek@us.ibm.com Paul Kyzivat on 04/17/2000 12:13:23 PM To: interop@omg.org, interceptors-ftf@omg.org cc: Subject: RE: Issue 3565 proposal > As the Interceptor specs stands right now, the answer to your > question is YES. Is that a problem? I am not sure if it is a problem - probably not, as long as everyone agrees. What I had in mind were SCs that must be processed in a special way. One that clearly falls in this category is the CodeSet SC. The orb must do something special with it. The question is, must the orb also make it available for regular interceptors? I think there may be others in RT Corba and possibly messaging that may have similar issues. There probably are others like this. There may also be issues on the sending end. There may be rules for some service contexts - e.g., that they should only be sent once per connection. If the orb is taking responsibility for sending them when required, should it permit interceptors to also insert these scs into requests? Paul > > I don't see how we can restrict access to service contexts > because it may be interceptors that handle each service context. > > Russell Butek > butek@us.ibm.com > > > Paul Kyzivat on 04/14/2000 06:20:52 PM > > To: interop@omg.org > cc: interceptors-ftf@omg.org > Subject: RE: Issue 3565 proposal > > > > > In general I agree with your proposal. > > But I think your text implies another issue that I don't > think has been > discussed: > > If a service context is recognized as well defined for the > version of giop > being used, including some standard semantics for how it should be > processed, > should it also be made available to interceptors? The answer > could be YES, > NO, or UNDEFINED. I don't off hand see any particularly > strong arguments > for > either YES or NO. > > What do others think? > > Paul > > > -----Original Message----- > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > Sent: Friday, April 14, 2000 2:08 PM > > To: interop@omg.org > > Cc: interceptors-ftf@omg.org > > Subject: Issue 3565 proposal > > > > > > > > > > This is an interop issue, but it definitely affects > interceptors, so I > > cc'ed interceptors-ftf. The problem is that the following > > text from the > > spec says unknown service contexts can be ignored or an > > exception can be > > thrown. Can anyone explain why this is necessary? It breaks > > interceptors > > since portable, non-standard interceptors can have their own service > > context ids that no ORB will recognize. > > > > ---------------------- > > Service context IDs are associated with a specific version of > > GIOP, but > > will always be > > allocated in the OMG service context range. This allows any ORB to > > recognize when > > it is receiving a standard service context, even if it has > > been defined in > > a version of > > GIOP that it does not support. > > > > The following are the rules for processing a received > service context: > > ? The service context is in the OMG defined range: > > ? If it is valid for the supported GIOP version, then it must be > > processed correctly > > according to the rules associated with it for that GIOP > > version level. > > ? If it is not valid for the GIOP version, then it may be > > ignored by the > > receiving > > ORB, however it must be passed on through a bridge. No > > exception shall > > be > > raised. > > > > ? The service context is not in the OMG-defined range: > > ? The receiving ORB may choose to ignore it, process it if it > > ?understands? it, or > > raise a system exception, however it must be passed on through a > > bridge. If a > > system exception is raised, it shall be BAD_PARAM with an > > OMG standard > > minor code of 1. > > ---------------------- > > > > Here's a proposed replacement of the above text that I > > believe satisfies > > the interceptor issue. I'm not positive whether it satisfies > > the broader, > > interoperability issue. > > > > ---------------------- > > OMG-defined service context IDs are associated with a > > specific version of > > GIOP, > > but will always be allocated in the OMG service context > > range. This allows > > any ORB > > to recognize when it is receiving a standard service context, > > even if it > > has been > > defined in a version of GIOP that it does not support. > > > > The following are the rules for processing a received > service context: > > - If it is valid for the supported GIOP version, then it must > > be processed > > correctly > > according to the rules associated with it for that GIOP > version level. > > - If it is not valid for the GIOP version, or if it is not in the > > OMG-defined range, > > then it shall be retained by the receiving ORB for interceptors and > > bridges. The > > ORB does not need to process it other than passing it on > > through a bridge > > and > > making it available to interceptors. > > ---------------------- > > > > > > Russell Butek > > butek@us.ibm.com > > > > > > > Date: Tue, 18 Apr 2000 08:08:33 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org, interceptors-ftf@omg.org Subject: RE: Issue 3565 proposal In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BDF0@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?Qad9;-U!!g*Od9:nA!! On Mon, 17 Apr 2000, Paul Kyzivat wrote: > > As the Interceptor specs stands right now, the answer to your > > question is YES. Is that a problem? > > I am not sure if it is a problem - probably not, as long as everyone agrees. > What I had in mind were SCs that must be processed in a special way. > One that clearly falls in this category is the CodeSet SC. > The orb must do something special with it. The question is, must the orb > also make it available for regular interceptors? I think there may be others > in RT Corba and possibly messaging that may have similar issues. We seem to get deeper and deeper into problems regarding codesets. I'm quite worried by all the complexity this causes... Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html To: Michi Henning cc: Paul Kyzivat , interop@omg.org, interceptors-ftf@omg.org Subject: Re: Issue 3565 proposal In-Reply-To: Your message of "Mon, 17 Apr 2000 15:13:19 PDT." From: Bill Janssen Message-Id: <00Apr17.171929pdt."3438"@watson.parc.xerox.com> Date: Mon, 17 Apr 2000 17:19:32 PDT Content-Type: text X-UIDL: G+;!!k_~e9:;\d9o`e!! > We seem to get deeper and deeper into problems regarding codesets. I'm quite > worried by all the complexity this causes... Indeed. One thing that might be a good idea would be to switch from the OSF character set registry to the IANA registry. The OSF one seems to have a small number of registrations. The IANA one is the more general-purpose Internet one, and of course is more `alive'. Bill To: interop@omg.org Subject: issue 3565 should be sharper Sender: Bill Janssen From: Bill Janssen Mime-Version: 1.0 Message-Id: <00May8.173425pdt."3438"@watson.parc.xerox.com> Date: Mon, 8 May 2000 17:34:35 PDT Content-Type: text/plain; charset=US-ASCII X-UIDL: NJFe97=bd9@^L!!kEo!! As Herr Kuenzler points out, it is silly for an ORB to raise an exception over an unknown service context -- and we should make it clear that this has always been the case, not just for CORBA 2.4. We should say that it's just a bug if an ORB throws such an exception; unknown service contexts should always just be ignored, and what's more, the original GIOP spec intended exactly that behavior. This should be a `clarification' that applies back to GIOP 1.0. Bill Date: Tue, 9 May 2000 11:07:49 +1000 (EST) From: Michi Henning To: Bill Janssen cc: interop@omg.org Subject: Re: issue 3565 should be sharper In-Reply-To: <00May8.173425pdt."3438"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: m~Vd9ESQe97NN!!I7Ee9 On Mon, 8 May 2000, Bill Janssen wrote: > As Herr Kuenzler points out, it is silly for an ORB to raise an > exception over an unknown service context -- and we should make it > clear that this has always been the case, not just for CORBA 2.4. > We > should say that it's just a bug if an ORB throws such an exception; > unknown service contexts should always just be ignored, and what's > more, the original GIOP spec intended exactly that behavior. This > should be a `clarification' that applies back to GIOP 1.0. I agree with that. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org Subject: RE: issue 3565 should be sharper Date: Tue, 9 May 2000 08:27:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: \4Ne9UXLe91O0e9\dbd9 I agree. Paul > -----Original Message----- > From: Bill Janssen [mailto:w.janssen@ieee.org] > Sent: Monday, May 08, 2000 8:35 PM > To: interop@omg.org > Subject: issue 3565 should be sharper > > > As Herr Kuenzler points out, it is silly for an ORB to raise an > exception over an unknown service context -- and we should make it > clear that this has always been the case, not just for CORBA 2.4. We > should say that it's just a bug if an ORB throws such an exception; > unknown service contexts should always just be ignored, and what's > more, the original GIOP spec intended exactly that behavior. This > should be a `clarification' that applies back to GIOP 1.0. > > Bill > From: "Rutt, T E (Tom)" To: interop@omg.org, "'Paul Kyzivat'" Subject: RE: issue 3565 should be sharper Date: Tue, 9 May 2000 10:36:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: #QAe9cl>!!0>$!!X&Z!! The problem is, that this allowance was added to GIOP 1.2 explicitly. I think we have to wait for GIOP 1.3 to add this new conformance item. I think that GIOP 1.3 should wait til the end of the year, with CORBA 3.0 and all coming. Thus the deprication, to not break existing systems which do this allowed "stupid" thing. -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com > ---------- > From: Paul Kyzivat[SMTP:paulk@roguewave.com] > Sent: Tuesday, May 09, 2000 8:27 AM > To: interop@omg.org > Subject: RE: issue 3565 should be sharper > > I agree. > > Paul > > > -----Original Message----- > > From: Bill Janssen [mailto:w.janssen@ieee.org] > > Sent: Monday, May 08, 2000 8:35 PM > > To: interop@omg.org > > Subject: issue 3565 should be sharper > > > > > > As Herr Kuenzler points out, it is silly for an ORB to raise an > > exception over an unknown service context -- and we should make it > > clear that this has always been the case, not just for CORBA 2.4. We > > should say that it's just a bug if an ORB throws such an exception; > > unknown service contexts should always just be ignored, and what's > > more, the original GIOP spec intended exactly that behavior. This > > should be a `clarification' that applies back to GIOP 1.0. > > > > Bill > > > From: urs.kuenzler@ubs.com Received: (from uucp@localhost) by pluto.ubs.com (8.8.8+Sun/8.8.8) id SAA27922; Tue, 9 May 2000 18:22:01 +0200 (MET DST) Received: from unknown(160.59.228.5) by pluto.ubs.com via smap (V5.5) id xma027916; Tue, 9 May 00 18:21:59 +0200 Received: from localhost (root@localhost) by hermes1.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id SAA01903; Tue, 9 May 2000 18:21:58 +0200 (METDST) Disposition-Notification-To: urs.kuenzler@ubs.com X-OpenMail-Hops: 2 Date: Tue, 9 May 2000 18:21:54 +0200 Message-Id: Subject: RE: issue 3565 should be sharper MIME-Version: 1.0 TO: interop@omg.org, terutt@lucent.com CC: hans-peter.hoidn@ubs.com, hans.kneubuehl@ubs.com, karsten-oliver.starr@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 9 May 2000 18:21:54 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: )0i!![>"e9i];!!,mV!! Whatever may be needed to keep the specification "backwards compatible"... an ORB using this option (throwing BAD_PARAM on an unknown service context) is just not interoperable, allthough it complies to the interoperability specification. Shouldn't it be possible to correct such problems also for past and current versions? regards urs kuenzler > -----Original Message----- > From: terutt [mailto:terutt@lucent.com] > Sent: Tuesday, May 09, 2000 4:36 PM > To: interop; paulk > Cc: terutt > Subject: RE: issue 3565 should be sharper > > > The problem is, that this allowance was added to GIOP 1.2 > explicitly. I > think > we have to wait for GIOP 1.3 to add this new conformance item. > > I think that GIOP 1.3 should wait til the end of the year, > with CORBA 3.0 > and all coming. > > Thus the deprication, to not break existing systems which do > this allowed > "stupid" thing. > > > -- > Tom Rutt > Lucent Technologies - Bell Labs > Rm 4L-336 Tel: +1(732)949-7862 > 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA email: terutt@lucent.com > > > > > ---------- > > From: Paul Kyzivat[SMTP:paulk@roguewave.com] > > Sent: Tuesday, May 09, 2000 8:27 AM > > To: interop@omg.org > > Subject: RE: issue 3565 should be sharper > > > > I agree. > > > > Paul > > > > > -----Original Message----- > > > From: Bill Janssen [mailto:w.janssen@ieee.org] > > > Sent: Monday, May 08, 2000 8:35 PM > > > To: interop@omg.org > > > Subject: issue 3565 should be sharper > > > > > > > > > As Herr Kuenzler points out, it is silly for an ORB to raise an > > > exception over an unknown service context -- and we should make it > > > clear that this has always been the case, not just for > CORBA 2.4. We > > > should say that it's just a bug if an ORB throws such an > exception; > > > unknown service contexts should always just be ignored, and what's > > > more, the original GIOP spec intended exactly that behavior. This > > > should be a `clarification' that applies back to GIOP 1.0. > > > > > > Bill > > > > > > From: "Rutt, T E (Tom)" To: interop@omg.org, "Rutt, T E (Tom)" , "'urs.kuenzler@ubs.com'" Cc: hans-peter.hoidn@ubs.com, hans.kneubuehl@ubs.com, karsten-oliver.starr@ubs.com Subject: RE: issue 3565 should be sharper Date: Thu, 11 May 2000 14:42:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: 9/Ud9+\l!!=]\d9]$-e9 I Just realized, we have another issue, which we approved already but could change before the report, that the minor code for the exception thrown for bad service context is incorrectly specified in the text to be 1, which is registered for another problem. So, the throwing of the exception could not have been properly implemented, since the minor code was inappropriately specified. Perhaps, looking at both issues, we could claim that the original exception throwing was so broken, that the best way to resolve both issues, is to withdraw the minor code for incorrect service context, and change the text in the GIOP to not refer to throwing exception for service context outside the OMG range. What do you all think about this approach? -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com > ---------- > From: urs.kuenzler@ubs.com[SMTP:urs.kuenzler@ubs.com] > Sent: Tuesday, May 09, 2000 12:21 PM > To: interop@omg.org; terutt@lucent.com > Cc: hans-peter.hoidn@ubs.com; hans.kneubuehl@ubs.com; > karsten-oliver.starr@ubs.com > Subject: RE: issue 3565 should be sharper > > Whatever may be needed to keep the specification "backwards compatible"... > an > ORB using this option (throwing BAD_PARAM on an unknown service context) > is > just not interoperable, allthough it complies to the interoperability > specification. Shouldn't it be possible to correct such problems also for > past > and current versions? > > regards > urs kuenzler > > > -----Original Message----- > > From: terutt [mailto:terutt@lucent.com] > > Sent: Tuesday, May 09, 2000 4:36 PM > > To: interop; paulk > > Cc: terutt > > Subject: RE: issue 3565 should be sharper > > > > > > The problem is, that this allowance was added to GIOP 1.2 > > explicitly. I > > think > > we have to wait for GIOP 1.3 to add this new conformance item. > > > > I think that GIOP 1.3 should wait til the end of the year, > > with CORBA 3.0 > > and all coming. > > > > Thus the deprication, to not break existing systems which do > > this allowed > > "stupid" thing. > > > > > > -- > > Tom Rutt > > Lucent Technologies - Bell Labs > > Rm 4L-336 Tel: +1(732)949-7862 > > 101 Crawford Corner Rd Fax: +1(732)949-1196 > > Holmdel NJ, 07733 USA email: terutt@lucent.com > > > > > > > > > ---------- > > > From: Paul Kyzivat[SMTP:paulk@roguewave.com] > > > Sent: Tuesday, May 09, 2000 8:27 AM > > > To: interop@omg.org > > > Subject: RE: issue 3565 should be sharper > > > > > > I agree. > > > > > > Paul > > > > > > > -----Original Message----- > > > > From: Bill Janssen [mailto:w.janssen@ieee.org] > > > > Sent: Monday, May 08, 2000 8:35 PM > > > > To: interop@omg.org > > > > Subject: issue 3565 should be sharper > > > > > > > > > > > > As Herr Kuenzler points out, it is silly for an ORB to raise an > > > > exception over an unknown service context -- and we should make it > > > > clear that this has always been the case, not just for > > CORBA 2.4. We > > > > should say that it's just a bug if an ORB throws such an > > exception; > > > > unknown service contexts should always just be ignored, and what's > > > > more, the original GIOP spec intended exactly that behavior. This > > > > should be a `clarification' that applies back to GIOP 1.0. > > > > > > > > Bill > > > > > > > > > > To: "Rutt, T E (Tom)" cc: interop@omg.org, "'urs.kuenzler@ubs.com'" , hans-peter.hoidn@ubs.com, hans.kneubuehl@ubs.com, karsten-oliver.starr@ubs.com Subject: Re: issue 3565 should be sharper In-Reply-To: Your message of "Thu, 11 May 2000 11:44:08 PDT." From: Bill Janssen Message-Id: <00May11.165355pdt."3438"@watson.parc.xerox.com> Date: Thu, 11 May 2000 16:54:03 PDT Content-Type: text X-UIDL: ]9;e9!N*e9Q70e9==Le9 > I Just realized, we have another issue, which we approved already but could > change > before the report, that the minor code for the exception thrown for bad > service context > is incorrectly specified in the text to be 1, which is registered for > another problem. > > So, the throwing of the exception could not have been properly implemented, > since the > minor code was inappropriately specified. > > Perhaps, looking at both issues, we could claim that the original exception > throwing was > so broken, that the best way to resolve both issues, is to withdraw the > minor code for > incorrect service context, and change the text in the GIOP to not refer to > throwing > exception for service context outside the OMG range. > > What do you all think about this approach? Any excuse in a storm. This is so obviously wrong that we really need to fix it. Go for it, Tom. Bill Date: Fri, 12 May 2000 10:47:25 +1000 (EST) From: Michi Henning To: "Rutt, T E (Tom)" cc: interop@omg.org, "'urs.kuenzler@ubs.com'" , hans-peter.hoidn@ubs.com, hans.kneubuehl@ubs.com, karsten-oliver.starr@ubs.com Subject: RE: issue 3565 should be sharper In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 5S So, the throwing of the exception could not have been properly implemented, > since the > minor code was inappropriately specified. > > Perhaps, looking at both issues, we could claim that the original exception > throwing was > so broken, that the best way to resolve both issues, is to withdraw the > minor code for > incorrect service context, and change the text in the GIOP to not refer to > throwing > exception for service context outside the OMG range. I agree with Bill. Throwing an exception is simply wrong. Cheers, Michi. From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA47798; Sat, 13 May 2000 04:50:04 -0500 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id EAA51222; Sat, 13 May 2000 04:59:14 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568DE.00315AD3 ; Sat, 13 May 2000 04:59:05 -0400 X-Lotus-FromDomain: IBMUS To: "Rutt, T E (Tom)" cc: interop@omg.org, "Rutt, T E (Tom)" , "'urs.kuenzler@ubs.com'" , hans-peter.hoidn@ubs.com, hans.kneubuehl@ubs.com, karsten-oliver.starr@ubs.com Message-ID: <852568DC.006F8066.00@d54mta08.raleigh.ibm.com> Date: Thu, 11 May 2000 15:07:47 -0500 Subject: RE: issue 3565 should be sharper Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: aBGe94AM!!)E'!!iM"!! Sounds fine to me. Russell Butek butek@us.ibm.com "Rutt, T E (Tom)" on 05/11/2000 01:42:26 PM To: interop@omg.org, "Rutt, T E (Tom)" , "'urs.kuenzler@ubs.com'" cc: hans-peter.hoidn@ubs.com, hans.kneubuehl@ubs.com, karsten-oliver.starr@ubs.com Subject: RE: issue 3565 should be sharper I Just realized, we have another issue, which we approved already but could change before the report, that the minor code for the exception thrown for bad service context is incorrectly specified in the text to be 1, which is registered for another problem. So, the throwing of the exception could not have been properly implemented, since the minor code was inappropriately specified. Perhaps, looking at both issues, we could claim that the original exception throwing was so broken, that the best way to resolve both issues, is to withdraw the minor code for incorrect service context, and change the text in the GIOP to not refer to throwing exception for service context outside the OMG range. What do you all think about this approach? -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com > ---------- > From: urs.kuenzler@ubs.com[SMTP:urs.kuenzler@ubs.com] > Sent: Tuesday, May 09, 2000 12:21 PM > To: interop@omg.org; terutt@lucent.com > Cc: hans-peter.hoidn@ubs.com; hans.kneubuehl@ubs.com; > karsten-oliver.starr@ubs.com > Subject: RE: issue 3565 should be sharper > > Whatever may be needed to keep the specification "backwards compatible"... > an > ORB using this option (throwing BAD_PARAM on an unknown service context) > is > just not interoperable, allthough it complies to the interoperability > specification. Shouldn't it be possible to correct such problems also for > past > and current versions? > > regards > urs kuenzler > > > -----Original Message----- > > From: terutt [mailto:terutt@lucent.com] > > Sent: Tuesday, May 09, 2000 4:36 PM > > To: interop; paulk > > Cc: terutt > > Subject: RE: issue 3565 should be sharper > > > > > > The problem is, that this allowance was added to GIOP 1.2 > > explicitly. I > > think > > we have to wait for GIOP 1.3 to add this new conformance item. > > > > I think that GIOP 1.3 should wait til the end of the year, > > with CORBA 3.0 > > and all coming. > > > > Thus the deprication, to not break existing systems which do > > this allowed > > "stupid" thing. > > > > > > -- > > Tom Rutt > > Lucent Technologies - Bell Labs > > Rm 4L-336 Tel: +1(732)949-7862 > > 101 Crawford Corner Rd Fax: +1(732)949-1196 > > Holmdel NJ, 07733 USA email: terutt@lucent.com > > > > > > > > > ---------- > > > From: Paul Kyzivat[SMTP:paulk@roguewave.com] > > > Sent: Tuesday, May 09, 2000 8:27 AM > > > To: interop@omg.org > > > Subject: RE: issue 3565 should be sharper > > > > > > I agree. > > > > > > Paul > > > > > > > -----Original Message----- > > > > From: Bill Janssen [mailto:w.janssen@ieee.org] > > > > Sent: Monday, May 08, 2000 8:35 PM > > > > To: interop@omg.org > > > > Subject: issue 3565 should be sharper > > > > > > > > > > > > As Herr Kuenzler points out, it is silly for an ORB to raise an > > > > exception over an unknown service context -- and we should make it > > > > clear that this has always been the case, not just for > > CORBA 2.4. We > > > > should say that it's just a bug if an ORB throws such an > > exception; > > > > unknown service contexts should always just be ignored, and what's > > > > more, the original GIOP spec intended exactly that behavior. This > > > > should be a `clarification' that applies back to GIOP 1.0. > > > > > > > > Bill > > > > > > > > > >