[anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt

[Nicolas.Williams at sun.com (Nicolas Williams)]

On Thu, Jul 19, 2007 at 03:21:10PM -0700, Caitlin Bestler wrote:
> >    You are mis-understanding the requirements.
> >    The requirements are there in order to free the API 
> > developer to be able to  do what make sense in a multitude of 
> > environments.  An object is said to be opaque to make sure 
> > that the *APPLICATION* does not depend upon the ability to 
> > look into the object in order to function.
> >    An object is said to be non-copyable, in order that you do 
> > not assume that you can copy it trivially by doing a structure copy.
> > 
> >    In both cases, if your choose to implement the accessor 
> > functions as #define macros, and the copy function as 
> > *foostruct=*barstruct, that's just fine.

Well, I would hope not -- implementing accessor functions as macros
makes the structure of the object part of the ABI, even though not part
of the API.  :)

> >    However, in a Posix environment, I can not assume that
> > 
> 
> Would you be ok with explicitly clarifying that the requirements
> described are only intended for the application layer code, and are
> not intended to constrain implementaion of the operating environment?

I think it should be quite clear already that "opaque" here means "with
respect to the application" since we're defining an API.  (And
certainly when the language is compared with that of other Internet RFCs
that describe APIs.)

But adding a simple qualifier like "with respect to the application"
should be no problem.  Michael?

> Or if there are constraints on the operating environment, to list those
> separately? For example, it is concievable that there is a requirement
> that the key material not be place in swap eligible memory. If so, that
> should be separate and explicit. (Personally, I think that falls under
> "quality of implementation" and is not something that should be
> standardized,
> but I could see valid arguments to the contrary).

Nothing in this API deals directly with cryptographic key material.

Nico
--