Minor full_desc: The 2.2 spec states: "The hexadecimal strings are generated by first turning an object reference into
an IOR, and then encapsulating the IOR using the encoding rules of CDR." but it does not state which codeset is used in that
CDR encoding, since IIOP profiles contain strings (the hostname) the choice of codeset is crucial for interoperability Though most
implementors will probably use ASCII (UTF8) for that encoding a clarification seems to be required.

to Close with agreed change

Summary: Several Capule specific attributes and operations are residing on Security
Current, such as own_credentials, and principal_authenticator. This
maligns the thread model of a Current object. In convention with other
specifications there should be a seperate capusle specific interface for
these objects.

Close issue 2704 "Current contains thread specific information".

Summary: How is a SecAttribute"s value field encoded? How is the
defining_authority field encoded and what does it represent?

The specification is unclear about this in the data module chapter,
Appendix A. However, it is clear from the interoperability specification
that the defining_authority if it exists, it is an OID.

Close issue 2703 "How is a SecAttribute’s value field encoded"

Summary: The Public attribute is said to exist for the mere purpose of having at
least one credentials object with at least one attribute, if no user has
authenticated. (It is entirely debateable of whether a credentials object
should exist at all if a prinicpal does not authenticate). It appears the
only purpose for this public attribute, which is said to exist in every
Credentials instance regardless of authentication, is to be able to
"grant" rights to EVERY principal in a Domain Access Policy.

Access Policies (AP), as opposed to Domain Access Policies(DAP) (is an
extension of AP) do not have to follow the "grant/revoke/replace" scheme
of DAP.

Therefore, the Public attribute permiates the entire system just to
support an optional Domain Access Policy. In fact that most access
decisions will ignore the Public attribute if access is based on other
attributes. This situation reveals unecessary copying of data and checking
for it. Therefore the public attribute is extraneous and causes
inefficiences.

A better solution would be to confine the problem of "granting" rights
(which is in DAP only) to every principal in a "domain" to the Domain
Access Policy interface itself, such as an operation of "void
set_base_rights(RightsList rights);" and not permiate the entire system
with a useless attribute. And of course, eliminate the Public Security
Attribute all together, and all refernces to it.

Close Issue 2800 _Public

Summary: This is an issue vs the Security specification.

The reference to SSL,

ftp://ierf.cnsi.reston.va.us/internet-drafts/draft-freier-ssl-version3-
01.txt

is not valid even if you correct the domain from "ierf" to "ietf". In
fact, the Internet Draft (which was only valid for six months) has been
withdrawn and I was unable to find a copy anywhere on the web.

Possible solutions:

If someone has a copy, and copyright permissions allow, we can post it
on the OMG server and reference it even though it"s not a valid IETF
specification.

Otherwise, the spec should be updated to conform to TLS 1.0 and the
reference updated to this spec instead of the SSL draft.

In the future, IETF drafts (which have limited lifetime) should not be
normative refereces in any OMG specifications.

close issue 2789