Subject: Re: Use of authorization identity

From: "Raif S. Naffah" <[email-masked]>
Date: Tue, 05 Jun 2001 19:46:26 +1000

At 02:26 PM 6/4/01 -0700, John Gardiner Myers wrote:

>"Raif S. Naffah" wrote:
> > of course.  but this is not the issue.  the issue, is how a protocole
> > passes the contents of the authorization-id to a mechanism...

the keyword here is passes. not "internally repesent" as you mentioned in 
your message, or any other situation.

for mechanisms to be inter-operable between different implementations, and 
inter-changeable between protocols, the authorization id has to be passed 
from a protocol to a mechanism in a programming language, and an encoding 
neutral way.

octet sequences are such an alternative; strings are not.

(i'll pass on the discussion about Java-CORBA-C).

cheers;
rsn

---

From: "Raif S. Naffah" <[email-masked]>
Date: Wed, 06 Jun 2001 19:57:10 +1000

>from a protocol to a mechanism in a programming language, and an encoding 

re-reading my own words i realise that the previous statement is not 
(always) valid:

1. it is safe to assume that when a Protocol needs to use a Mechanism it 
needs to pass it more than just the authorization ID; eg. the Java API.

2. in the absence of a unified API, it does not matter if only the 
authorization ID is well defined in terms of its form, since 2 different 
implementations, in the same programming language, are likely to have 
different method names/mechanisms for instantiating the Mechanism, as well 
as a different order of parameters, even if they both use the same 
arguments+types.

3. in the presence of unified APIs (one per programming language), and 
within each of those languages (with that unified API), would mandating 
that the authorization ID be an octet sequence render the above statement 
true, but only for that language binding. ie. A Protocol knows how to 
handle the authorization ID, it passes it to the Mechanism as an octet 
sequence on one side, it gets it back on the other side, and handles it 
there with the right (as defined in its specs) encoding.

4. only with a programming language neutral interface definition; ie. OMG's 
IDL, would the above statement be always true.

although (3) and (4) are not likely to be included in the objectives of 
this WG, it's beneficial to clarify the specs in favour of having the 
authorization ID as an octet sequence.  this way at least the community of 
users using the same programming language API can have more flexibility in 
configuring/using different Protocols and Mechanisms.

thanks for the bandwidth + cheers;
rsn

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 07 Jun 2001 14:28:16 -0700

"Raif S. Naffah" wrote:
> this way at least the community of

I don't agree that octet strings have substantive advantages over
character strings for this purpose.  I would, however, like to defer the
debate over which alternative is more appropriate until after we have
agreement on the set of possible alternatives and the set of changes
needed for each alternative.

---

From: "Raif S. Naffah" <[email-masked]>
Date: Wed, 06 Jun 2001 19:57:10 +1000

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 07 Jun 2001 14:28:16 -0700