Subject: [kitten] proposed RFC 6680 erratum for GSS_Getname_attribute() network interaction

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Apr 2015 13:56:26 -0400 (EDT)

It was unclear if there was actually support for an erratum for this, so
let me throw out some text and see what response it gets.

In section 7.5.  GSS_Get_name_attribute()

OLD:
   This function outputs the value(s) associated with a given GSS name
   object for a given name attribute.

NEW:
   This function outputs the value(s) associated with a given GSS name
   object for a given name attribute.  It is permitted to block pending
   network interactions when the attr input is not an attribute which
   would be included in the attrs output of a call to GSS_Inquire_name()
   on the same name input.

COMMENT:
   RFC 6680 makes no mention of blocking or not blocking on network
   interaction, though RFC 2743 does.  This seems like the most reasonable
   interpretation of what is currently in RFC 6680.  Calls which are not
   explicitly permitted to block are assumed to be not permitted to block.

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Apr 2015 14:02:32 -0500

>    would be included in the attrs output of a call to GSS_Inquire_name()

I'm OK with this.

Perhaps we should publish draft-williams-kitten-generic-naming-
attributes-02 and make it update RFC6680 (since that I-D deals with
blocking already).

>    explicitly permitted to block are assumed to be not permitted to block.

I agree with the gist of this, but GSS in general is a bit wishy-washy
as to all sorts of things related to programming language run-times.
What is "blocking"?  A good definition is hard to come by.  Is CPU bound
and long-running "blocking"?  What if such a task task could be handed
to a task queue?

Ideally we'd have async I/O extensions for functions that can block...
But this is difficult to do if we cannot assume threading (so that GSS
mechanisms can run their event loops in separate threads).

Which reminds me: we should do that (add async interfaces that depend on
threading rather than adding interfaces to applications' event loops).

Nico
--