Subject: RE: GSSAPI service registry

From: "Linn, John" <[email-masked]>
Date: Thu, 12 Feb 1998 09:03:51 -0500

Here's where I think this discussion stands: 

>    >- leave 2078bis silent on the topic
> 
Points in favor: stability, avoiding extension of 2078bis' scope further
towards naming.  Points against: clarification of service name elements
would help interoperability, and 2078bis (as the place where the
structure of a host-based service name is defined in a
mechanism-independent way) seems like the right place for any such
discussion to be incorporated

>    >
>    >- change 2078bis to recommend/require "rcmd" as the service
> element's
>    >value for a host-based service name corresponding to multiple
> protocols
> 
This is clearly unpopular, and we're unaware of a standards-track
precedent for it. I think it's off the list. 

>    >
>    >- change 2078bis to recommend/require "host" as the service
> element's
>    >value for a host-based service name corresponding to multiple
> protocols
> 
If a multi-protocol service element value is to be defined, "host" seems
to be the choice of choice. 

How about the following approach: specify "host" as the generic value
within the 2078bis name structure definition, and recommend there that a
document specifying GSS integration into a particular protocol should
state either:

(a) that a specific IANA-registered name associated with that protocol
shall be used (this admits, if needed, the possibility that a single
name could be registered and shared among a related set of protocols),

(b) that the generic name "host" shall be used, or

(c) that, for that protocol, fallback in specified order (a, then b) or
(b, then a) shall be applied?

--jl

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 12 Feb 1998 20:21:48 -0500

From: "Linn, John" <[email-masked]>
   Date: Thu, 12 Feb 1998 09:03:51 -0500

This works for me.

					- Ted