NO SUBJECT Bob Blakley (internet: blakley at vnet.ibm.com) IBM Austin, 11400 Burnet Rd. Bldg 903 Rm 5b-09 Phone (512)838-8133 t/l 678-8133, FAX 838-2593
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NO SUBJECT Bob Blakley (internet: blakley at vnet.ibm.com) IBM Austin, 11400 Burnet Rd. Bldg 903 Rm 5b-09 Phone (512)838-8133 t/l 678-8133, FAX 838-2593
The conformance section in the text Piers sent defines a useful
set of tiered functionality, but I have a concern about its
minimum (mandatory) level. Since the minimum X/Open conformance
level requires support for per-message integrity, it's not possible
to write a conformant implementation which supports only peer
entity authentication without per-message security services. It
is, in contrast, consistent with the IETF text for a mechanism to
return conf_avail and integ_avail FALSE at context establishment
time. I could envision, e.g., such a mechanism as a means to
integrate a challenge-response authenticator exchange into a
caller protocol. Such a mechanism would probably also conflict
with another stated conformance requirement, the ability to
support mutual as well as unilateral authentication.
It's certainly legitimate to prescribe a set of conformance
levels which are tighter than the breadth of implementation options
permitted by the IETF specs, in the interests of portability,
but I'd like to explore whether a consensus exists which would
enable tighter alignment. Any comments, pro or con, on the prospect
and value of any of:
(1) requiring, in the RFCs, support for per-message integrity in
a conformant mechanism?
(2) limiting the base conformance level to a point which is
satisfied by peer entity authentication only, with per-message
integrity support as a separate tier?
(3) converging on whether mutual authentication support should
be required?
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06160;
19 May 95 11:44 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06156;
19 May 95 11:44 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09552;
19 May 95 11:44 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <LAA21398 at pad-thai.cam.ov.com>; Fri, 19 May 1995 11:00:22 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA13983; Fri, 19 May 95 11:00:04 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <LAA21374 at pad-thai.cam.ov.com>; Fri, 19 May 1995 11:00:12 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id LAA15761; Fri, 19 May 1995 11:00:06 -0400
Message-Id: <199505191500.LAA15761 at winkl.cam.ov.com>
To: dennis.glatting at cybersafe.com
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
In-Reply-To: Your message of "Thu, 18 May 1995 10:35:30 PDT."
<9505181735.AA03784 at sickly.cybersafe.com>
Date: Fri, 19 May 1995 11:00:06 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
CAT context fanciers:
Distilling the sense of the discussion, as I perceive it:
(1) There is interest in the ability to transfer established contexts
between different holders within an end system.
(2) There is acceptance that the ability to support (1) would be an
optional facility, which a given GSS-API implementation might or might
not provide.
(3) A specific proposal (gss_externalize_context() and
gss_internalize_context()) has been made to realize (1).
(4) For at least some set of cases, environments, and assumptions, it
has been shown that (1) can be achieved without modification to the
existing interface.
(5) We've had illuminating discussion about implementation strategies
and security and synchronization implications for alternatives (3) and
(4), but I don't believe we've yet agreed on either approach as a
suitable, feasible, and generally implementable means to provide (1).
Based on these premises (any of which is, of course, subject to
debate), and a desire to proceed with finalizing GSS-V2 for
advancement (wanting not to stray more than necessary from the mid-May
date targeted at the Danvers meeting), I propose the following: not to
add gss_externalize_context and gss_internalize_context into GSS-V2,
but rather that they should be discussed further and considered for a
separate document, entitled something like "Optional Extensions to
GSS-V2 for Context Transfer", which implementors could adopt and use
alongside GSS-V2 itself.
Comments?
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08347;
19 May 95 13:21 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08343;
19 May 95 13:20 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11480;
19 May 95 13:21 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <MAA24616 at pad-thai.cam.ov.com>; Fri, 19 May 1995 12:37:18 -0400
Received: from koriel.Sun.COM by MIT.EDU with SMTP
id AA27827; Fri, 19 May 95 12:36:59 EDT
Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
id AA05725; Fri, 19 May 95 09:36:44 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-248.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA20694; Fri, 19 May 1995 09:36:39 -0700
Received: from elros.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id JAA10455; Fri, 19 May 1995 09:36:33 -0700
Received: by elros.Eng.Sun.COM (5.x/SMI-SVR4)
id AA00515; Fri, 19 May 1995 09:36:27 -0700
Date: Fri, 19 May 1995 09:36:27 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <9505191636.AA00515 at elros.Eng.Sun.COM>
To: linn at cam.ov.com
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Cc: cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
John,
I think you summarized the issues about externalize/internalize well, but
allow me to offer an opinion on :
>
> Based on these premises (any of which is, of course, subject to
> debate), and a desire to proceed with finalizing GSS-V2 for
> advancement (wanting not to stray more than necessary from the mid-May
> date targeted at the Danvers meeting), I propose the following: not to
> add gss_externalize_context and gss_internalize_context into GSS-V2,
> but rather that they should be discussed further and considered for a
> separate document, entitled something like "Optional Extensions to
> GSS-V2 for Context Transfer", which implementors could adopt and use
> alongside GSS-V2 itself.
>
I realize there is pressure to get a gssapi v2 document out by mid-May (which
is right now, of course) and am sympathetic to your predicament. However, I am
concerned that in a rush to meet that deadline important issues are being
left unresolved. Two that come to my mind (perhaps not to other's) is the
structure of namespaces (meaning both a syntax and an OID), especially in
regard to how different mechanisms in a multi-mechanism implementation treat
these, and the externalize/internalize issue.
Of course, it can always be said that these will be covered in some other
document that will be auxiliary to gssapiv2, but that could be said of almost
any issue. While the importance of the namespace issue may be controversial,
there are several implementors, including me, who think some sort of
externalize/internalize interface is appropriate. The problems with handling
the functionality presented by such an interface using the existing calls is
problematic for at least two reasons :
o Applications may want to cache contexts that have been moved from one
address space to another to achieve performance improvements related
to frequency of use and other factors. To do this, either the gssapi
implementation must supply a caching scheme, which may not be suitable
for a given application or the externalize/internalize functionality
must be exposed. For the reasons given, I believe the latter is best.
o Interoperability between different implementations within different
address spaces will be very difficult to achieve if implementations
move contexts "under the covers." In addition to the problem of a
canonical form for the externalized representation of a context, there
is the problem of compatibility between the transport mechanisms used
by separate implementations to move the context information. Exposing
the externalized opaque data allows the application to use the appropriate
transport mechanism for its environment.
I don't think the best way to solve issues such as this one is to say "put it
in an auxiliary document." While things eventually have to come to closure,
doing so when major unresolved issues remain can be counterproductive. Readers
of the resulting base document will have to go around finding all the others
that describe functionality they need to compelete implementations (witness
the IP over XXX family [nation?] of documents).
I guess it should be obvious by now that I support the idea of thrashing out
these issues, even if it means not getting out a final draft of gssapiv2 right
now.
Dan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08867;
19 May 95 13:41 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08863;
19 May 95 13:41 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11816;
19 May 95 13:41 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <NAA25499 at pad-thai.cam.ov.com>; Fri, 19 May 1995 13:04:06 -0400
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA01967; Fri, 19 May 95 13:03:39 EDT
Received: from sickly.cybersafe.com (sickly.cybersafe.com [192.156.168.11]) by kerby.ocsg.com (8.6.12/8.6.11, dpg hack 11mar95) with SMTP id KAA02390; Fri, 19 May 1995 10:03:29 -0700
Received: by sickly.cybersafe.com (NX5.67d/NX3.0S)
id AA10049; Fri, 19 May 95 10:03:27 -0700
Date: Fri, 19 May 95 10:03:27 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <dennisg at sickly.cybersafe.com>
Message-Id: <9505191703.AA10049 at sickly.cybersafe.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: Dan Nessett <Danny.Nessett at eng.sun.com>
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Cc: linn at cam.ov.com, cat-ietf at mit.edu
Reply-To: dennis.glatting at cybersafe.com
> Date: Fri, 19 May 1995 09:36:27 -0700
> From: Danny.Nessett at Eng.Sun.COM (Dan Nessett)
>
> I realize there is pressure to get a gssapi v2 document out
> by mid-May (which is right now, of course) and am
> sympathetic to your predicament. However, I am
> concerned that in a rush to meet that deadline important
> issues are being left unresolved. Two that come to my mind
> (perhaps not to other's) is the structure of namespaces
> (meaning both a syntax and an OID), especially in regard
> to how different mechanisms in a multi-mechanism
> implementation treat these, and the
> externalize/internalize issue.
>
A third comes to mind too: mechanism negotiation. Where
does that stand?
-dpg
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09203;
19 May 95 13:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12091;
19 May 95 13:58 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09117;
19 May 95 13:58 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08766;
19 May 95 13:37 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgpd at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-cidrd-appeal-00.txt
Date: Fri, 19 May 95 13:37:44 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9505191337.aa08766 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the CIDR Deployment Working Group
of the IETF.
Title : An Appeal to the Internet Community to Return Unused IP
Networks(Prefixes) to the IANA
Author(s) : P. Nesser
Filename : draft-ietf-cidrd-appeal-00.txt
Pages : 5
Date : 05/18/1995
This document is an appeal to the Internet community to return unused
address space, i.e. any block of consecutive IP prefixes, to the Internet
Address Naming Authority (IANA) or any of the delegated registries, for
reapportionment. Similarly an appeal is issued to providors to return
unused prefixes which fall outside their customary address blocks to the
IANA for reapportionment.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-cidrd-appeal-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cidrd-appeal-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (192.12.192.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cidrd-appeal-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950518172730.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-cidrd-appeal-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cidrd-appeal-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950518172730.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09212;
19 May 95 13:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12101;
19 May 95 13:58 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09116;
19 May 95 13:58 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08722;
19 May 95 13:37 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pop at jhunix.hcf.jhu.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-myers-pop-pop3-01.txt
Date: Fri, 19 May 95 13:36:39 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9505191337.aa08722 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Post Office Protocol - Version 3
Author(s) : J. Myers, M. Rose
Filename : draft-myers-pop-pop3-01.txt
Pages : 18
Date : 05/18/1995
On certain types of smaller nodes in the Internet it is often impractical
to maintain a message transport system (MTS). For example, a workstation
may not have sufficient resources (cycles, disk space) in order to permit a
SMTP server [RFC821] and associated local mail delivery system to be kept
resident and continuously running. Similarly, it may be expensive (or
impossible) to keep a personal computer interconnected to an IP-style
network for long amounts of time (the node is lacking the resource known as
"connectivity").
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-myers-pop-pop3-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-pop-pop3-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (192.12.192.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-pop-pop3-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950518172453.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-myers-pop-pop3-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-pop-pop3-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950518172453.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09889;
19 May 95 14:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12593;
19 May 95 14:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09861;
19 May 95 14:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09731;
19 May 95 14:21 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: snadlcmib at cisco.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-snadlc-llc-mib-02.txt
Date: Fri, 19 May 95 14:21:03 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9505191421.aa09731 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNA DLC Services MIB Working
Group of the IETF.
Title : Definitions of Managed Objects for SNA Data Link
Control: LLC
Author(s) : S. Nix, W. Clark, S. Berl
Filename : draft-ietf-snadlc-llc-mib-02.txt
Pages : 68
Date : 05/18/1995
This specification defines an extension to the Management Information Base
(MIB) for use with SNMP-based network management. In particular, it
defines objects for managing the configuration, monitoring and control of
data link controls in an SNA environment. This draft identifies managed
objects for SNA Logical Link Control (LLC) links only.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-snadlc-llc-mib-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snadlc-llc-mib-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (192.12.192.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snadlc-llc-mib-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950518140218.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-snadlc-llc-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snadlc-llc-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950518140218.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10553;
19 May 95 15:12 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10547;
19 May 95 15:12 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13389;
19 May 95 15:12 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <OAA28077 at pad-thai.cam.ov.com>; Fri, 19 May 1995 14:26:08 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA14296; Fri, 19 May 95 14:25:49 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <OAA28069 at pad-thai.cam.ov.com>; Fri, 19 May 1995 14:26:05 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id OAA15806; Fri, 19 May 1995 14:26:03 -0400
Message-Id: <199505191826.OAA15806 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Status of GSS issues (was ... context functionality ...)
Date: Fri, 19 May 1995 14:26:02 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Dan, Dennis, all:
> However, I am
> concerned that in a rush to meet that deadline important
> issues are being left unresolved.
I'm not trying to leave issues unresolved; instead, I'm trying to
identify them so that they can be resolved. For cases where we
have consensus on the need for changes and on what those changes
should state, resolution can be achieved by including those changes.
> Two that come to my mind
> (perhaps not to other's) is the structure of namespaces
> (meaning both a syntax and an OID), especially in regard
> to how different mechanisms in a multi-mechanism
> implementation treat these,
In my working copy, I've already made edits in response to Dan's
comment (3 May) about inconsistency between the drafts in semantics
of GSS_Compare_name(), and per Dan's comment (27 April) about the
semantics of the input_name_type argument. I have noted, as requiring
further discussion and resolution, the 5 May and subsequent
discussion of a proposed GSS_Inquire_name() call; I was planning
to raise that issue shortly. Also re naming, there's the pending
question (Ted Ts'o, 13 April) of whether we should define a GSS-level
name type for host-based service.
> and the
> externalize/internalize issue.
which we're currently discussing. Views of other participants
hereby solicited.
>A third comes to mind too: mechanism negotiation. Where
>does that stand?
I believe we're awaiting preparation of a draft to specify the
negotiated mechanism; perhaps Doug Rosenthal and/or Denis Pinkas
can comment on its status. Like the Kerberos and SPKM specs,
this will be a separate mechanism document, not part of the
GSS-API spec itself, and can (I believe) operate to select a
common mechanism without application-provided input about
mechanism preferences. I don't believe that we've come to
agreement about how to restructure QOP parameters, thereby
allowing callers to indicate such preferences.
Other issues I've noted as pending discussion:
elaboration on cleanup after context establishment failure
context renewal proposal (John Wray, 10 April)
credential management: closure on added query facilities, per
April discussion (e.g., gss_inquire_cred_by_mech())
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11596;
19 May 95 16:22 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11592;
19 May 95 16:22 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14968;
19 May 95 16:22 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <PAA00790 at pad-thai.cam.ov.com>; Fri, 19 May 1995 15:43:49 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA27249; Fri, 19 May 95 15:43:31 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <PAA00782 at pad-thai.cam.ov.com>; Fri, 19 May 1995 15:43:47 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id PAA15967; Fri, 19 May 1995 15:43:45 -0400
Message-Id: <199505191943.PAA15967 at winkl.cam.ov.com>
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Status of GSS issues (was ... context functionality ...)
In-Reply-To: Your message of "Fri, 19 May 1995 14:26:02 EDT."
<199505191826.OAA15806 at winkl.cam.ov.com>
Date: Fri, 19 May 1995 15:43:44 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Re:
>Other issues I've noted as pending discussion:
>
>elaboration on cleanup after context establishment failure
I propose to state, for GSS_Init_sec_context() and
GSS_Accept_sec_context(), that:
"The input_context_handle argument is 0, specifying "not yet assigned",
on the first GSS_<Init,Accept>_sec_context() call relating to a
given context. If successful (i.e., if accompanied by major_status
GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and only if successful,
the initial GSS_<Init,Accept>_sec_context() call returns a non-zero
output_context_handle for use in future references to this context.
Once a non-zero output_context_handle has been returned, GSS-API
callers should call GSS_Delete_sec_context() to release
context-related resources if errors occur in later phases of
context establishment, or when an established context is
no longer required".
I also propose to include, per E-mail discussion, a statement that
the returned mech_type OID is valid only when GSS_S_COMPLETE
is returned.
If anyone sees a need for further changes or additions to the
text in this area, please comment.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12852;
19 May 95 17:45 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12848;
19 May 95 17:45 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16587;
19 May 95 17:45 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <RAA03338 at pad-thai.cam.ov.com>; Fri, 19 May 1995 17:04:06 -0400
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA06353; Fri, 19 May 95 17:03:36 EDT
Received: by dcl.MIT.EDU (5.0/4.7) id AA17500; Fri, 19 May 1995 17:03:35 +0500
Date: Fri, 19 May 1995 17:03:35 +0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9505192103.AA17500 at dcl.MIT.EDU>
To: dennis.glatting at cybersafe.com
Cc: Danny.Nessett at eng.sun.com, linn at cam.ov.com, cat-ietf at mit.edu,
cadams at bnr.ca
In-Reply-To: Dennis Glatting's message of Wed, 17 May 95 10:26:55 -0700,
<9505171726.AA00370 at sickly.cybersafe.com>
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 2703
Let me address some of the issues that have been raised in regards to
the gss_internalize_context() and gss_externalize_context() in a general
fashion, instead of trying to reply point by point to the the concerns
that have been raised.
1) Such routines are not necessary, since mechanisms can be
implemented to allow handles to be transferable between processes
within that context.
It is true that a mechanism *could* be designed in such a fashion;
however, there is no way that a portable application can know that a
particular mechanism can be support this easily.
Furthermore, in a user-mode GSSAPI library, (such as the GSS API
implementation donated to the MIT Kerberos V5 distribution by
OpenVision), it would be highly inefficient if a general purpose context
handle is always portable between processes. It is much more efficient
if there is an explicit call to produce an externalized version of
context which can then be transffered between processes.
2) The externalize_context() call might allow calling applications to
gain access to the context encryption keys, which might either (a)
cause problems with a product's export status, or (b) render controls
over whether or not a caller is authorized to make use of the context
useless.
If this is really a concern, a GSSAPI mechanism can simply encrypt the
externalized context before passing it back to the user, and decrypt
when internalizing it.
In a user-mode implementation, this is only security by obscurity, as
the calling program can simply search its own process space looking for
the encryption key for the context. But in a user-mode implementation,
the program could always extract the context keys directly by searching
its own data space anyway.
In a kernel-mode or daemon-process implementation, encrypting the
context works very well; and the gss_internalize_context() call can
enforce whatever mandatory access controls (or other special-purpose
controls) as necessary.
In summary, I think being able to internalize and externalize a context
is as fraught with peril as some people think. Actually, I think in
most cases it's rather straightforward. I would really rather prefer to
see these calls in the base V2 specification, since simply saying that
applications can "discover at link time" whether or not a mechanism will
support context externalization doesn't always work when you're dealing
with shared or dynamically linked libraries. It's much simpler if the
application can discover whether or not a mechanism supports this
feature by receiving an error status code after calling
gss_externalize_context(), or by checking some capabilities flags word.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12941;
19 May 95 17:54 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12935;
19 May 95 17:54 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16719;
19 May 95 17:54 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <RAA03708 at pad-thai.cam.ov.com>; Fri, 19 May 1995 17:18:58 -0400
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA11542; Fri, 19 May 95 17:18:40 EDT
Received: from krypton.mcc.com (krypton.mcc.com [128.62.30.63]) by turtle.mcc.com (8.6.10/mcc.8.6.9) with SMTP id QAA19453; Fri, 19 May 1995 16:17:55 -0500
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA20068; Fri, 19 May 95 16:17:54 CDT
Date: Fri, 19 May 95 16:17:54 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9505192117.AA20068 at krypton.mcc.com>
To: dennis.glatting at cybersafe.com
Cc: Danny.Nessett at eng.sun.com, linn at cam.ov.com, cat-ietf at mit.edu
In-Reply-To: <9505191703.AA10049 at sickly.cybersafe.com> (message from Dennis Glatting on Fri, 19 May 95 10:03:27 -0700)
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Dennis> A third comes to mind too: mechanism negotiation. Where
Dennis> does that stand?
I'm working with Denis Pinkas and Eric Baize (from Bull) to get the
original negotiation proposal, with initial feedback revisions, turned
into an Internet Draft. This I-D will then be circulated (for more
feedback), hopefully prior to the July IETF meetings.
- Doug
--
Doug Rosenthal
EINet | Email: rosenthal at einet.net
3500 W. Balcones Center Dr. | Voice: 512-338-3515
Austin, TX USA 78759 | Fax: 512-338-3897
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13241;
19 May 95 18:22 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13237;
19 May 95 18:22 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17261;
19 May 95 18:22 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <RAA04417 at pad-thai.cam.ov.com>; Fri, 19 May 1995 17:46:40 -0400
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA14924; Fri, 19 May 95 17:46:16 EDT
Received: from krypton.mcc.com (krypton.mcc.com [128.62.30.63]) by turtle.mcc.com (8.6.10/mcc.8.6.9) with SMTP id QAA19950; Fri, 19 May 1995 16:46:14 -0500
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA20103; Fri, 19 May 95 16:46:14 CDT
Date: Fri, 19 May 95 16:46:14 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9505192146.AA20103 at krypton.mcc.com>
To: linn at cam.ov.com
Cc: cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: <199505191826.OAA15806 at winkl.cam.ov.com> (message from John Linn on Fri, 19 May 1995 14:26:02 -0400)
Subject: Re: Status of GSS issues (was ... context functionality ...)
John> I believe we're awaiting preparation of a draft to specify
John> the negotiated mechanism; perhaps Doug Rosenthal and/or
John> Denis Pinkas can comment on its status. Like the Kerberos
John> and SPKM specs, this will be a separate mechanism document,
John> not part of the GSS-API spec itself, and can (I believe)
John> operate to select a common mechanism without
John> application-provided input about mechanism preferences. I
John> don't believe that we've come to agreement about how to
John> restructure QOP parameters, thereby allowing callers to
John> indicate such preferences.
Yes, that is the intent. The Internet Draft will cover this.
- Doug
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13631;
19 May 95 19:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13627;
19 May 95 19:01 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18124;
19 May 95 19:01 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <SAA05495 at pad-thai.cam.ov.com>; Fri, 19 May 1995 18:28:11 -0400
Received: from koriel.Sun.COM by MIT.EDU with SMTP
id AA16381; Fri, 19 May 95 17:57:33 EDT
Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
id AA24343; Fri, 19 May 95 14:56:45 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-248.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA04985; Fri, 19 May 1995 14:56:42 -0700
Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id OAA00360; Fri, 19 May 1995 14:56:15 -0700
Received: by elrond.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id OAA01584; Fri, 19 May 1995 14:56:09 -0700
Date: Fri, 19 May 1995 14:56:09 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199505192156.OAA01584 at elrond.Eng.Sun.COM>
To: dennis.glatting at cybersafe.com, tytso at mit.edu
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Cc: Danny.Nessett at eng.sun.com, linn at cam.ov.com, cat-ietf at mit.edu,
cadams at bnr.ca
X-Sun-Charset: US-ASCII
Ted,
You're right, I hadn't thought about :
> simply saying that
> applications can "discover at link time" whether or not a mechanism will
> support context externalization doesn't always work when you're dealing
> with shared or dynamically linked libraries. It's much simpler if the
> application can discover whether or not a mechanism supports this
> feature by receiving an error status code after calling
> gss_externalize_context(), or by checking some capabilities flags word.
>
Dan
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13790;
19 May 95 19:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18238;
19 May 95 19:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13738;
19 May 95 19:04 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13598;
19 May 95 19:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18104;
19 May 95 19:00 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13589;
19 May 95 19:00 EDT
To: IETF-Announce: ;
Reply-To: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 2a: INTRO: 17-21 July 1995/Stockholm
Date: Fri, 19 May 95 19:00:22 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9505191900.aa13589 at IETF.CNRI.Reston.VA.US>
Dear IETFers:
Following this message (2a), you will receive four more listed below:
IETF MAILING 1b: HOTEL RESERVATION FORM. This form must be returned via
fax to the GRAND HOTEL by Friday, June 16th in order to
guarantee a room. This form as well as reservation forms
for additional hotels are available via ftp, gopher and www.
DO NOT SEND YOUR FORMS TO THE IETF SECRETARIAT.
IETF MAILING 1c: IETF RSVP FORM. US$300.00 postmarked on or BEFORE Friday,
June 16, 1995. US$320.00 Registration postmarked after
Friday, June 16, 1995. Registration Forms will be
accepted via electronic mail and facsimile until 13:00 ET
on Wednesday, July 12, 1995. Registration and payment
will be accepted on-site. (In remote directories
0mtg-rsvp.txt)
IETF MAILING 1d: DRAFT AT-A-GLANCE. (In remote directories,
0mtg-at-a-glance-95jul.txt)
IETF MAILING 1e: DRAFT AGENDA. Please keep in mind that this is ONLY
a DRAFT and subject to frequent changes. A copy of the
Agenda is also available from the remote on-line
directories, cd ietf, get 0mtg-agenda.txt.
(In remote directories, 0mtg-agenda.txt)
The IETF Social has been scheduled for: Monday Evening
NOTE: WE CANNOT STRESS THIS ENOUGH. Though we'd prefer to have a payment
of the meeting fee as soon as possible, we definitely want immediate
notification that you are planning on coming. So even though you know
that payment will be delayed for one reason or another, SEND THE RSVP
FORM IN ANYWAY.
ACCESS METHODS:
FTP
-----
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
cd ietf
ls *0mtg*
Gopher
-------
Information pertaining to the 32nd IETF is available on the Gopher
Server running on IETF.CNRI.RESTON.VA.US (132.151.1.35) under
"Internet Engineering Task Force / IETF Meetings / Stockholm July 1995".
WWW
-----
<http://www.ietf.cnri.reston.va.us/home.html> Click on the link for
"meetings" and you should find an entry for the Stockholm meeting.
Thank You,
Megan
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13884;
19 May 95 19:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18285;
19 May 95 19:05 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13808;
19 May 95 19:05 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13674;
19 May 95 19:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18152;
19 May 95 19:03 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13662;
19 May 95 19:03 EDT
To: IETF-Announce: ;
Reply-To: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 1b: HOTEL RESERVATION FORM: 17-21 July 1995/Stockholm
Date: Fri, 19 May 95 19:03:13 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9505191903.aa13662 at IETF.CNRI.Reston.VA.US>
Please fax this form no later than Friday, June 16, 1995, to:
The Grand Hotel
Reference: IETF Group
14-23 July 1995
Phone: +46 8 679 3500 FAX: +46 8 611 8686
Roomrates:
Single: SEK 1064
Double: SEK 1565/two twin beds
(all rates are inclusive of tax, service charge and breakfast buffet.)
Arrival Date:_____________________________________________
Departure Date: __________________________________________
Single:________ Rate:_______
Double:________ Rate:_______
Special Requests:__________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Name:______________________________________________________________________
Company:___________________________________________________________________
Address:___________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Telephone:_____________________________ FAX:_______________________________
Credit Card:___________________________________ Exp:_______________________
Reservation must be guaranteed with a credit card (American Express, Visa,
etc.). Should a reservation be cancelled less than 24 hours
prior to arrival, one nights room and tax will be charged to the card.
____________________________________ ________________________________
Signature Date
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13940;
19 May 95 19:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18321;
19 May 95 19:07 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13929;
19 May 95 19:07 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13778;
19 May 95 19:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18236;
19 May 95 19:04 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13758;
19 May 95 19:04 EDT
To: IETF-Announce: ;
REPLY-TO: ietf-rsvp at CNRI.Reston.VA.US
Subject: IETF MAILING 1c: RSVP FORM: 17-21 July 1995/Stockholm
Date: Fri, 19 May 95 19:04:47 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9505191904.aa13758 at IETF.CNRI.Reston.VA.US>
REGISTRATION FORM
33rd Internet Engineering Task Force - Page 1 of 2
17-21 July 1995
Stockholm, Sweden
Please print or type:
Name (Mr/Dr/Ms)__________________________________________________________
Title____________________________________________________________________
Organization_____________________________________________________________
Address__________________________________________________________________
_________________________________________________________________________
City_____________________________State_____________Postal Code___________
Country__________________________________________________________________
Telephone______________________________Fax_______________________________
Email____________________________________________________________________
Do you plan to attend the Sunday, 16 July NEWCOMER'S ORIENTATION at 1630?
YES___ NO___
Do you plan to attend the Sunday, 16 July RECEPTION at 1800?
YES___ NO___
The IETF Proceedings are available electronically. Would you
still like a hard copy?
YES___ NO ___
US$300.00 Registration postmarked on or BEFORE, Friday, 16 June 1995.
US$320.00 (US$300.00 + US$20.00 late fee) Registration postmarked after
Friday, 16 June 1995.
Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check
(U.S. dollars, drawn on a U.S. Bank), payable to:
Corporation for National Research Initiatives
Account No.____________________________ Expiration Date__________________
Cardholder Name__________________________________________________________
Cardholder Signature_____________________________________________________
Registration Forms can be sent via electronic mail, facsimile, or postal mail:
Electronic: ietf-rsvp at cnri.reston.va.us
Facsimile: +1-703-620-0913
Postal: Corporation for National Research Initiatives
Accounting Department - 33rd IETF Meeting
1895 Preston White Drive, Suite 100
Reston, VA 22091-5434 USA
REGISTRATION FORM
33rd Internet Engineering Task Force - Page 2 of 2
17-21 July 1995
Stockholm, Sweden
IMPORTANT:
1. Payment MAY, but does NOT have to, accompany the Form.
2. Register ONE person per form. Substitutions are NOT allowed.
3. Include a completed Registration Form with payment.
4. Purchase orders are NOT accepted.
5. DD Form 1556 IS accepted.
6. We CANNOT invoice for payment.
7. Registration Forms will be accepted via electronic mail and
facsimile until 1300 ET on Tuesday, 11 July 1995.
8. Requests for refunds must be received by Tuesday, 11 July 1995.
9. Refund policy: Refunds are subject to a US$20.00 service charge.
Late fees will not be refunded.
10. Your registration fee includes Sunday evening reception (cash bar),
morning coffee and afternoon refreshment break.
For additional information or assistance, please contact +1-703-620-8990,
+1-703-620-0913 (Fax) or ietf-rsvp at cnri.reston.va.us. Direct all inquiries
to: 33rd IETF Meeting - Stockholm, Sweden.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14060;
19 May 95 19:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18404;
19 May 95 19:10 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14041;
19 May 95 19:10 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13967;
19 May 95 19:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18340;
19 May 95 19:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13958;
19 May 95 19:08 EDT
To: IETF-Announce: ;
Reply-To: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 2d: AT-A-GLANCE: 17-21 July 1995/Stockholm
Date: Fri, 19 May 95 19:08:16 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9505191908.aa13958 at IETF.CNRI.Reston.VA.US>
33rd INTERNET ENGINEERING TASK FORCE Mailing Date : 5/19/95
AT-A-GLANCE Mailing Number: 2d
DATES: July 17-21, 1995 HOST(S):
Bernhard Stockman/Royal Institute
of Technology and NORDUnet
HOTEL/MEETING SITE: Grand Hotel
S.Blasieholmshamnen 8
P.O. Box 164 24
S-103 27 Stockholm Sweden
Send Reservations via FAX {fax:+ 46 8 611 8686}
CI 14:00; CO 12:00
200 Rooms reserved until Friday, June 16, 1995.
SEK$1064/single; SEK$1565/double
(both rates include 12% VAT and continental breakfast)
Specify: IETF Group
ADDITIONAL ACCOM: Berns Hotel
Reisen Hotel
Sheraton Hotel
Strand Hotel
All hotels, including the Grand, prefer faxed registration forms. Forms
are available as follows:
Gopher
======
Gopher Server running on IETF.CNRI.RESTON.VA.US (132.151.1.35) under
"Internet Engineering Task Force / IETF Meetings / Stockholm July 1995".
WWW
======
<http://www.ietf.cnri.reston.va.us/home.html> Click on the link for
"meetings" and you should find an entry for the Stockholm meeting.
NEWCOMER'S Sunday, July 16, 1995
ORIENTATION: 16:30 - 17:30
Room: Royal
PRE-REGISTRATION: Sunday, July 16, 1995
18:00 - 20:00 (reception)
Grand Hotel
Room: Hall of Mirrors
TERMINAL ROOM: Scholanderska, Marten winge, Wernerska, Hanna winge
ATTENDANCE FEE: US$300.00 if registered BEFORE June 16, 1995
US$320.00 if registered AFTER June 16, 1995
PAYMENT BY: Credit Cards (Visa, Master Card, American
Express, Diners Club, and Carte Blanche ONLY). All
credit card payment slips will include the US Dollar
notation.
Checks (amounts written in US Dollars, drawn on US banks).
Traveler's Checks in US Dollar demoninations ONLY.
Cash (US Dollars or Swedish Krona/SEK)
There will be one Krona/US Dollar exchange rate for the
entire week of the IETF meeting. This will be based on
the closing exchange rate on Saturday, July 15th. We
will not adjust the exchange rate on a daily basis. DO
NOTE WRITE THE CHECK UNTIL YOU KNOW THE KRONA/US DOLLAR
EXCHANGE RATE.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14207;
19 May 95 19:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18489;
19 May 95 19:15 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14183;
19 May 95 19:15 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14127;
19 May 95 19:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18431;
19 May 95 19:12 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14117;
19 May 95 19:12 EDT
To: IETF-Announce: ;
Reply-To: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 2e: DRAFT AGENDA: 17-21 July 1995/Stockholm
Date: Fri, 19 May 95 19:12:43 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9505191912.aa14117 at IETF.CNRI.Reston.VA.US>
****33rd IETF: 17-21 July 1995/Stockholm, Sweden****
PLEASE NOTE THE FOLLOWING:
1. NEWCOMER's ORIENTATION: On Sunday, 16 July at 16:30 we will be
holding an orientation session for newcomers (Room: Royal)
ALL FIRST TIME ATTENDEES ARE ENCOURAGED TO RETRIEVE AND READ
RFC 1718 BEFORE ATTENDING THE MEETING.*
Entitled "The Tao of IETF: A Guide for New Attendees of the Internet
Engineering Task Force", this RFC is available by anonymous FTP. Login
with the username "anonymous" and password "guest". After logging in,
Type "cd rfc". "get rfc1718.txt".
2. On Wednesday morning, 19 July at 0800 a Workshop for Working
Group Chairs will be held. Location: TBD
3. The Social Event will take place Monday evening. More information
will be available from the Local Host at a later date.
4. The Agenda below is a DRAFT and therefore subject to frequent changes.
We do not advise you use it to determine travel arrangements.
--------
FYI.....
A reminder that the quality of these meetings (and in
particular the Working Group technical *working* sessions) is
dependent upon the informed, constructive participation of the
individual attendees. Please come prepared.
Information on the current status and progress of the individual
Working Groups can be obtained in several ways:
1. Working Group objectives and notes from previous sessions are
available online (send to ietf-info at cnri.reston.va.us for retrieval
instructions).
2. Working Group objectives and notes from previous meetings are
also reproduced in the hardcopy Proceedings (to order, send to
proceedings at cnri.reston.va.us).
3. Agendas and reading lists for Working Group meetings will also be
posted to the respective Working Group mailing lists. And when
submitted to the Secretariat will be made available via gopher
and the web.
IF YOU HAVE QUESTIONS REGARDING THE SCHEDULING OF A PARTICULAR WORKING
GROUP, PLEASE CONTACT THE CHAIR OF THAT GROUP DIRECTLY. A LISTING OF
WORKING GROUP MAILING LISTS IS AVAILABLE VIA ANONYMOUS FTP, CD IETF,
GET "1wg-summary.txt".
LOOKING AHEAD....
Information on future IETF meetings is available from the FTP Directories.
Look under filename "0mtg-sites.txt".
Draft Agenda of the Thirty-Third IETF - as of 5/18/95 2:13pm
(17-21 July 1995)
MONDAY, 17 July 1995
0800-0900 IETF Registration and Morning Coffee
0900-0930 Introductions
0930-1130 Presentations
Break
1300-1500 Afternoon Sessions I
MGT rmonmib Remote Network Monitoring WG
RTG sdr Source Demand Routing WG
TSV mmusic Multiparty Multimedia Session Control WG
USV uswg User Services Working Group WG
1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
MGT entity Entity MIB BOF
OPS cidrd CIDR Deployment WG
SEC aft Authenticated Firewall Traversal WG
TSV rsvp Resource Reservation Setup Protocol WG
USV run Responsible Use of the Network WG
TUESDAY, 18 July 1995
0830-0900 Morning Coffee
0900-1130 Morning Sessions
IPNG ipngwg IPNG WG
MGT isdnmib ISDN MIB BOF
RTG mobileip IP Routing for Wireless/Mobile Hosts WG
TSV mmusic Multiparty Multimedia Session Control WG
Break
1300-1500 Afternoon Sessions I
MGT atommib AToM MIB WG
RTG mobileip IP Routing for Wireless/Mobile Hosts WG
TSV rsvp Resource Reservation Setup Protocol WG
1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
INT pppext Point-to-Point Protocol Extension WG
MGT rmonmib Remote Network Monitoring WG
TSV tsvng Transport Next Generation BOF
1930-2200 Tuesday, 18 July 1995 - Evening Sessions
MGT ifmib Interfaces MIB BOF
TSV intservt Integrated Services Test BOF
WEDNESDAY, 19 July 1995
0800-0900 Working Group Workshop
0830-0900 Morning Coffee
0900-1130 Morning Sessions
MGT trunkmib DS1/DS3 MIB BOF
RTG rolc Routing over Large Clouds WG
Break
1300-1500 Afternoon Sessions I
MGT atommib AToM MIB WG
RTG nimrod New Internet Routing and Addressing
Architecture WG
SEC cat Common Authentication Technology WG
USV trainmat Network Training Materials WG
1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
MGT nmarea Network Management Area: Open Meeting
TSV rfc1006 RFC1006bis/ISO TP over IPv6 BOF
1930-2200 Wednesday, 19 July 1995 - Evening Session
GEN iab Internet Architecture Board
THURSDAY, 20 July 1995
0830-0900 Morning Coffee
0900-1130 Morning Sessions
MGT rmonmib Remote Network Monitoring WG
RTG nimrod New Internet Routing and Addressing
Architecture WG
SEC cat Common Authentication Technology WG
TSV intserv Integrated Services WG
Break
1300-1500 Afternoon Sessions I
INT ipatm IP Over Asynchronous Transfer Mode WG
MGT ifmib Interfaces MIB BOF
SEC saag Security Area Advisory Group
TSV intserv Integrated Services WG
1500-1530 Break (Refreshments provided)
1530-1630 Technical Presentations
1630-1830 Open Plenary and IESG
FRIDAY, 21 July 1995
0830-0900 Morning Coffee
0900-1130 Technical Presentations
Key to Abbreviations
APP Applications Harald Alvestrand/UNINETT and
John Klensin/MCI
GEN General Interest
INT Internet Frank Kastenholz and Susan Thomson/Bellcore
IPNG IP: Next Generation Scott Bradner/Harvard and
Allison Mankin/ISI
MGT Network Management Deirdre Kostick/AT&T
OPS Operational Requirements Scott Bradner/Harvard and
Michael O'Dell/UUNET Technologies
RTG Routing Joel Halpern/Newbridge Networks
SEC Security Jeff Schiller/MIT
TSV Transport Allison Mankin/ISI
USV User Services Joyce K. Reynolds/ISI
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03314;
20 May 95 12:45 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03310;
20 May 95 12:45 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06885;
20 May 95 12:45 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <MAA28207 at pad-thai.cam.ov.com>; Sat, 20 May 1995 12:11:13 -0400
Received: from inet-gw-1.pa.dec.com by MIT.EDU with SMTP
id AA02788; Sat, 20 May 95 12:10:52 EDT
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95)
id AA21728; Sat, 20 May 95 08:45:47 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA17147; Sat, 20 May 95 11:46:49 -0400
Message-Id: <9505201546.AA17147 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Sat, 20 May 95 11:46:51 EDT
Date: Sat, 20 May 95 11:46:51 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 20-May-1995 1114" <wray at tuxedo.enet.dec.com>
To: linn at cam.ov.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
How about this as a possible compromise:
Define a function that will create an inter-process token for the transfer of a
context betwen processes on a single machine, and a corresponding function that
will convert such a token into a context.
_Don't_ document these functions as externalizing context data. To avoid any
implication that these routines do create a "flattened" externalized structure
containing context data, call them something like
gss_export_local_security_context and gss_import_local_security_context.
Encourage implementations to protect the context data in some way (either by
encryption, or by actually using some IPC mechanism under-the-covers within the
GSSAPI implementation, with the token simply acting as a synchronization
mechanism).
_Don't_ expect such a context token to be portable across GSSAPI implementation
(i.e. if a given implementation creates an inter-process context token, then
only that implementation will be able to import it).
Define an error-status that can be returned by
gss_import_local_security_context that means "Operation forbidden by local
policy". Encourage implementations to adopt a sensible policy on which
processes may accept contexts (e.g. it may make sense to share contexts between
processes that are running under the same UID, or are part of the same job).
Define an additional bit in the context flags that will indicate whether a
given context is exportable. Although I doubt many applications will make
run-time decisions based on this flag, it mirrors what we've done for other
context-level properties. It also allows the transferrability of contexts to
be decided on a per-mechanism basis.
Define an error-status that can be returned by
gss_export_local_security_context that means "Operation not supported".
Document the fact that passing an open context between processes may also
reveal data about the credential that was used to create the context, and that
therefore contexts should only be passed to processes that you wouldn't mind
revealing your authentication data to.
Document that a context, once exported/imported, is fully transferred to the
importing process. After gss_export, the context is closed in the exporting
process. After gss_import, the context is fully owned by the importing process
(in particular, the importing process may refresh the context). Only a single
process may import a given context.
I believe that the above allows for the required functionality, while
emphasizing that context transfer is likely to run into portability problems.
It also allows for a system-specific access-control policy to be enforced by
GSSAPI, in environments where that makes sense.
One thing the above doesn't do is allow the exporting application to specify
the target process, so that the GSSAPI implementation could restrict transfer
to just that one process. This means that the context transfer token must be
protected in transit, which may not be feasible in all OSes and environments.
I'd like to see an input to gss_export_local_security_context that somehow
specifies the target process, so that (if the GSSAPI implementation does
enforce access control) it can also enforce the wishes of the context exporter.
However, I can't think of a sufficiently general way of describing a target
process, although some sort of large integer is probably good enough for a PID
on most OSes.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00848;
22 May 95 6:04 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00844;
22 May 95 6:04 EDT
Received: from [192.231.148.11] by CNRI.Reston.VA.US id aa02519;
22 May 95 6:04 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <FAA23895 at pad-thai.cam.ov.com>; Mon, 22 May 1995 05:05:35 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA01995; Mon, 22 May 95 05:05:09 EDT
Received: from Q.icl.co.uk by flow.pipex.net with SMTP (PP);
Mon, 22 May 1995 10:05:01 +0100
Received: from relay1.pipex.net by Q.icl.co.uk (4.1/icl-2.12-server)
id AB01541; Mon, 22 May 95 10:08:50 BST
Received: from trojan.oasis.icl.co.uk by ming.oasis.icl.co.uk over SMTP
id SAA00920; Fri, 19 May 1995 18:30:18 GMT
Message-Id: <9505191831.AA20278 at getafix.oasis.icl.co.uk>
Date: Fri, 19 May 95 19:31:53 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Re: x/open gss-api v1
To: cat-ietf at mit.edu
> but I'd like to explore whether a consensus exists which would
> enable tighter alignment. Any comments, pro or con, on the prospect
> and value of any of:
>
> (1) requiring, in the RFCs, support for per-message integrity in
> a conformant mechanism?
>
> (2) limiting the base conformance level to a point which is
> satisfied by peer entity authentication only, with per-message
> integrity support as a separate tier?
>
> (3) converging on whether mutual authentication support should
> be required?
The main motivations for the minimum conformance baseline are:
(a) to make it easier for application writers. The fewer exceptions
that an application needs to cope with the better, and if one
can assume a certain basic set of services, then application
writers can expect a consistent functional level from GSS-API
implementations.
(b) reflect the functional capabilities of current mechanisms
back into the standard (or, rather, currently, an adjunct set up
by x/open to the standard) to document what constitutes a reasonable
threshold for mechanisms.
(c) to provide the bare minimum for countering known network
threats common to all applications in the Internet environment
as a default.
This should enable basic users to trust GSS-API to "do the
right thing" - while permitting advanced users to maintain
their finegrained control.
Piers
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04633;
22 May 95 10:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ab07087;
22 May 95 10:39 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04571;
22 May 95 10:38 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03925;
22 May 95 10:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06494;
22 May 95 10:15 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03917;
22 May 95 10:14 EDT
To: IETF-Announce: ;
Subject: WG ACTION: The TCP/UDP Over CLNP-Addressed Networks (tuba) to conclude
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at IETF.CNRI.Reston.VA.US>
Date: Mon, 22 May 95 10:14:58 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221014.aa03917 at IETF.CNRI.Reston.VA.US>
The TCP/UDP Over CLNP-Addressed Networks (tuba) Working Group of the
Internet Area of the IETF has concluded.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04643;
22 May 95 10:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07094;
22 May 95 10:39 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04573;
22 May 95 10:38 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03961;
22 May 95 10:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06514;
22 May 95 10:15 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03943;
22 May 95 10:15 EDT
To: IETF-Announce: ;
Subject: WG ACTION: Common Architecture for Next Generation IP (catnip) to
conclude
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at IETF.CNRI.Reston.VA.US>
Date: Mon, 22 May 95 10:15:26 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221015.aa03943 at IETF.CNRI.Reston.VA.US>
The Common Architecture for Next Generation IP (catnip) Working Group
of the Internet Area of the IETF has concluded.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05138;
22 May 95 11:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07484;
22 May 95 11:00 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05106;
22 May 95 11:00 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05022;
22 May 95 10:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07408;
22 May 95 10:56 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05013;
22 May 95 10:56 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-asid at umich.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: Schema Publishing in X.500 Directory to
Experimental
Date: Mon, 22 May 95 10:56:34 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221056.aa05013 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "Schema Publishing in X.500
Directory" <draft-ietf-asid-schema-02.txt> and recommends that it be
published by the RFC Editor as an Experimental RFC. This document is
the product of the Access, Searching and Indexing of Directories
Working Group. The IESG contact persons are John Klensin and Harald
Alvestrand.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05356;
22 May 95 11:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07582;
22 May 95 11:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05335;
22 May 95 11:04 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05221;
22 May 95 11:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07519;
22 May 95 11:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05206;
22 May 95 11:01 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ids at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: Recommendations for an X.500 Production Directory
Service to Informational
Date: Mon, 22 May 95 11:01:08 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221101.aa05206 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "Recommendations for an X.500
Production Directory Service" <draft-ietf-ids-x500-pds-directory-00.txt>
and recommends that it be published by the RFC Editor as an
Informational RFC. This document is the product of the Integrated
Directory Services Working Group. The IESG contact persons are John
Klensin and Harald Alvestrand.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05535;
22 May 95 11:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07676;
22 May 95 11:07 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05522;
22 May 95 11:07 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05424;
22 May 95 11:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07629;
22 May 95 11:05 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05419;
22 May 95 11:05 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: A Chemical Primary Content Type for Multipurpose
Internet Mail Extensions to Proposed Standard
Date: Mon, 22 May 95 11:05:02 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221105.aa05419 at IETF.CNRI.Reston.VA.US>
The IESG has received a request to consider "A Chemical Primary Content
Type for Multipurpose Internet Mail Extensions"
<draft-rzepa-chemical-mime-type-01.txt> as a Proposed Standard. This is
not the product of an IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by June
15. 1995.
IESG Secretary
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06136;
22 May 95 11:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08219;
22 May 95 11:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06120;
22 May 95 11:36 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05948;
22 May 95 11:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08140;
22 May 95 11:31 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05941;
22 May 95 11:31 EDT
To: IETF-Announce: ;
Subject: WG ACTION: 100VG-AnyLAN MIB (vgmib)
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Date: Mon, 22 May 95 11:31:30 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221131.aa05941 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Network Management
Area of the IETF. For more information, please contact the working
group chair or the Area Director.
100VG-AnyLAN MIB (vgmib)
------------------------
Chair(s):
Jeff Johnson <jjohnson at cisco.com>
Network Management Area Director(s):
Deirdre Kostick <kostick at qsun.att.com>
Area Advisor
Kaj Tesink <kaj at cc.bellcore.com>
Mailing lists:
General Discussion:vgmib at hprnd.rose.hp.com
To Subscribe: vgmib-request at hprnd.rose.hp.com
Archive: ftp://rosegarden.external.hp.com/pub/vgmib
Description of Working Group:
The 100VG-AnyLAN MIB Working Group is chartered to develop a set of
managed objects for IEEE 802.12 network interfaces and repeaters.
These objects will be the minimum necessary to provide the ability to
monitor and control these network interfaces and repeaters, and will be
consistent with the SNMP framework and existing SNMP standards.
The working group will consider as an important input Section 13 (Layer
Management Functions and Services), and Annex E (GDMO Specifications
for Demand Priority Managed Objects) in the current IEEE 802.12 Draft,
and will monitor and track the progress of that draft as it moves
toward IEEE standardization. Furthermore, the working group will follow
the guidelines in the SNMPv2 SMI for mapping GDMO managed objects for
use with the Internet Network Management Framework. In addition, the
working group will solicit vendor-specific MIB modules to use as input
to the working group.
This working group will produce two documents:
Definitions of Managed Objects for IEEE 802.12 Interfaces
Definitions of Managed Objects for IEEE 802.12 Repeater Devices
For the repeater portion of the MIB, the working group will make sure
that its work is aligned with the 802.3 Repeater MIB Working Group to
ensure that the two working groups produce a consistent framework for
the management of repeater devices. As a result, development of the
repeater portion of the MIB will be done concurrently with, but
independently from, the interfaces portion of the MIB. Furthermore, the
goals and milestones associated with the repeater portion of the MIB
are dependent upon the goals and milestones of the 802.3 Repeater MIB
Working Group.
Goals and Milestones:
May 95 Solicit proprietary MIB module submissions.
Jun 95 Post initial Internet-Draft of the 100VG Interfaces MIB.
Jun 95 Post initial Internet-Draft of the 100VG Repeater Devices MIB.
Jul 95 Meet at Stockholm IETF to review MIBs (if warranted).
Aug 95 Post updated Internet-Draft of the 100VG Interfaces MIB and the 100VG
Repeater Devices MIB.
Sep 95 Post final Internet-Draft of the 100VG Interfaces MIB and submit to
Area Director for consideration as a Proposed Standard.
Sep 95 Post final Internet-Draft of the 100VG Repeater Devices MIB and
submit to Area Director for consideration as a Proposed Standard.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06482;
22 May 95 11:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08488;
22 May 95 11:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06429;
22 May 95 11:45 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06321;
22 May 95 11:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08394;
22 May 95 11:42 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06310;
22 May 95 11:42 EDT
To: IETF-Announce: ;
Subject: WG ACTION: ISDN MIB (isdnmib)
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Date: Mon, 22 May 95 11:42:16 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221142.aa06310 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Network Management
Area of the IETF. For more information, please contact the working
group chair or the Area Director.
ISDN MIB (isdnmib)
------------------
Chair(s):
Ed Alcoff <eda at combinet.com>
Network Management Area Director(s):
Deirdre Kostick <kostick at qsun.att.com>
Area Advisor
Fred Baker <fred at cisco.com>
Mailing lists:
General Discussion:isdn-mib at combinet.com
To Subscribe: majordomo at combinet.com
In Body: subscribe isdn-mib your_email_address
Archive: ftp://ftp.combinet.com/pub/isdn-mib/archive
Description of Working Group:
The goal of the working group is to define the minimal set of managed
objects for SNMP- based management of ISDN interfaces. ISDN interfaces
are supported on a variety of equipment (for data and voice) including
terminal adapters, bridges, hosts, and routers. The set of objects will
be consistent with the SNMP framework and existing SNMP standards.
The working group will solicit any existing enterprise-specific MIB
modules to use as input to the standard MIB. The scope of the MIB is to
support remote configuration and administration; support all ISDN
interfaces and switch types; provide statistical information of ISDN
call activity; a table of ISDN call history; and SNMP traps specific to
ISDN call activity. RFC 1573 shall be used to define interface layering
issues.
Goals and Milestones:
Jun 95 Post Internet-Draft for ISDN MIB.
Jul 95 Review Internet-Draft at Stockholm IETF.
Sep 95 Post update to ISDN MIB Internet-Draft.
Dec 95 Meet at Dallas IETF to review updated draft (if warranted).
Dec 95 Submit final Internet-Draft of the ISDN MIB to Area Director for
consideration as a Proposed Standard.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06572;
22 May 95 11:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08539;
22 May 95 11:48 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06549;
22 May 95 11:48 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06436;
22 May 95 11:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08468;
22 May 95 11:45 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06430;
22 May 95 11:45 EDT
To: IETF-Announce: ;
Subject: WG ACTION: Detailed Revision/update of message standards (drums)
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Date: Mon, 22 May 95 11:45:06 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221145.aa06430 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Applications Area of the
IETF.For more information, please contact the working group chair or
the Area Directors.
Detailed Revision/update of message standards (drums)
-----------------------------------------------------
Chair(s):
Keith Moore <moore at cs.utk.edu>
Applications Area Director(s):
John Klensin <Klensin at mail1.reston.mci.net>
Harald Alvestrand <Harald.T.Alvestrand at uninett.no>
Area Advisor
Harald Alvestrand <Harald.T.Alvestrand at uninett.no>
Mailing lists:
General Discussion:drums at cs.utk.edu
To Subscribe: drums-request at cs.utk.edu
Archive:
Description of Working Group:
The goal of this working group is to develop and review revised
versions of RFC 821 and RFC 822, incorporating the revisions in RFC
974, RFC 1123, and RFC 1651.
In addition, the group will review other RFCs related to messaging, and
determine the applicability of each of these to the future direction of
the messaging in the Internet. The group may choose to incorporate,
deprecate, or write applicability statements for such documents, as
necessary to produce a clear statement of requirements for overall
interoperability of Internet electronic mail.
The documents produced by the working group are intended to be
submitted to the IESG for consideration as Internet Standards.
Items appropriate for inclusion in documents produced by the working
group include corrections, clarifications, and amplifications to
reflect existing practice or to address problems which have been
identified through experience with Internet mail protocols. New
functionality is expressly inappropriate.
Goals and Milestones:
Aug 95 Issue one or more internet-drafts which identify problems with
existing messaging documents, and propose solutions to those problems
with solutions can be identified.
Dec 95 Issue a first Internet-Draft of the revised SMTP document.
Mar 96 Issue a first Internet-Draft of the revised message format document.
Issue a second Internet-Draft of the revised SMTP document.
Jul 96 Issue a second Internet-Draft of the revised message format
document.
Issue a third Internet-Draft of the revised SMTP document.
Oct 96 Issue a third Internet-Draft of the revised message format document.
Dec 96 Submit documents to IESG for approval.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06821;
22 May 95 11:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08684;
22 May 95 11:57 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06811;
22 May 95 11:57 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06732;
22 May 95 11:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08640;
22 May 95 11:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06721;
22 May 95 11:54 EDT
To: IETF-Announce: ;
Subject: WG ACTION: Web Transaction Security (wts)
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at IETF.CNRI.Reston.VA.US>
Date: Mon, 22 May 95 11:54:07 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221154.aa06721 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Security Area of the IETF.
For more information, please contact the working group chair or the
Area Director.
Web Transaction Security (wts)
------------------------------
Chair(s):
Charlie Kaufman <charlie_kaufman at iris.com>
Security Area Director(s):
Jeffrey Schiller <jis at mit.edu>
Mailing lists:
General Discussion:www-security at nsmx.rutgers.edu
To Subscribe: www-security-request at nsmx.rutgers.edu
Archive: http://www-ns.rutgers.edu/www-security
Description of Working Group:
The goal of the Web Transaction Security Working Group is to develop
requirements and a specification for the provision of security services
to Web transaction, eg. transactions using HyperText Transport Protocol
(HTTP). This work will proceed in parallel to and independently of the
development of non-security features in the HTTP Working Group. The
working group will prepare two documents for submission as Internet
Drafts; an HTTP Security Requirements Specification, and an HTTP
Security Protocol Specification. The latter will be submitted as a
Standards Track RFC.
Goals and Milestones:
Done HTTP Security Requirements submitted as Internet-Draft.
Jul 95 HTTP Security Requirements finalized at the Stockholm IETF. Submit
HTTP Security Specification proposal(s) as Internet-Drafts.
Dec 95 HTTP Security Specification finalized at the Dallas IETF, submitted
to IESG for Standards Track action.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07351;
22 May 95 12:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09323;
22 May 95 12:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07342;
22 May 95 12:26 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07256;
22 May 95 12:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09205;
22 May 95 12:22 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07248;
22 May 95 12:22 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: rreq at isi.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Requirements for IP Version 4 Routers to Proposed
Standard
Date: Mon, 22 May 95 12:22:45 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221222.aa07248 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Requirements for IP Version 4
Routers" <draft-ietf-rreq-cidr-03.txt> as a Proposed Standard. This
document is the product of the Router Requirements Working Group. The
IESG contact person is Joel Halpern.
Technical Summary
This document describes the requirements routers need to meet in order
to operate safely and effectively in the modern internet. It defines the
necessary behaviors, along with suffient explanation of the whys and
wherefores to provide support for implementors and answers to questions
Working Group Summary
Much discussion went into this work, and it represent the consensus of
the community without dissent.
Protocol Quality
The draft has been reviewed by Joel M. Halpern, the Routing AD, and
Scott Bradner, and is sound and good advice.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07530;
22 May 95 12:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09401;
22 May 95 12:30 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07501;
22 May 95 12:30 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07383;
22 May 95 12:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09331;
22 May 95 12:26 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07378;
22 May 95 12:26 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-osi-ds at cs.ucl.ac.uk
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Connection-less Lightweight Directory Access
Protocol to Proposed Standard
Date: Mon, 22 May 95 12:26:49 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505221226.aa07378 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Connection-less Lightweight
Directory Access Protocol" <draft-ietf-osids-cldap-02.txt> as a
Proposed Standard. This work was initiated in the [now defunct] OSI
Directory Services Working Group and completed by the Access and
Synchronization of the Internet Directories Working Group. The IESG
contact person is Harald Tveit Alvestrand.
Technical Summary
The protocol described in this document is designed to provide access
to the Directory while not incurring the resource requirements of the
Directory Access Protocol (DAP) as specified in X.500. In particular,
it is aimed at avoiding the elapsed time that is associated with
connection-oriented communication and it facilitates use of the
Directory in a manner analagous to the DNS. It is specifically
targeted at simple lookup applications that require to read a small
number of attribute values from a single entry. It is intended to be
a complement to DAP and LDAP (RFC 1487). The protocol specification
draws heavily on that of LDAP (RFC 1487) that has proven to be the
most widely used and implemented access protocol for X.500 to date.
Advice on how to implement a retransmission strategy was added after
the previous IESG review.
Working Group Summary
Most of the debate on CLDAP focused on improvements to LDAP. There
was a clear concensus on the connectionless approach.
Protocol Quality
The specification has been reviewed by a member of the Applications
Area Directorate and by one of the Area Directors.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08694;
22 May 95 13:28 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa08690;
22 May 95 13:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10367;
22 May 95 13:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08673;
22 May 95 13:28 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa08669;
22 May 95 13:28 EDT
Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa10350;
22 May 95 13:27 EDT
Received: from UW-Gateway.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(NX5.67e/UW-NDC Revision: 2.27.MRC ) id AA01849; Mon, 22 May 95 10:27:47 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
(NX5.67e/UW-NDC/Panda Revision: 2.27.MRC ) id AA06678; Mon, 22 May 95 10:27:04 -0700
Date: Mon, 22 May 1995 10:20:26 -0700 (PDT)
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: draft-rzepa-chemical-mime-type-01.txt
To: iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US
Message-Id: <MailManager.801163226.5195.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
This proposal for a "Chemical" primary MIME type is a joke, right?
It's amusing, but putting out an IESG last call message is carrying it just a
little bit too far.
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa09462;
22 May 95 13:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10963;
22 May 95 13:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09436;
22 May 95 13:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09266;
22 May 95 13:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
cc: bgpd at merit.edu, nanog at merit.edu
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-degroot-classless-inaddr-00.txt
Date: Mon, 22 May 95 13:50:59 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9505221351.aa09266 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Classless in-addr.arpa delegation
Author(s) : H. Eidnes, G. de Groot
Filename : draft-degroot-classless-inaddr-00.txt
Pages : 6
Date : 05/19/1995
This document describes a way to do in-addr.arpa delegation on non-octet
boundaries. The proposed method should thus remove one of the objections
to do subnetting on non-octet boundaries but perhaps more significantly,
make it possible to assign IP address space in smaller chunks than 24-bit
prefixes without losing the ability to delegate authority for the
corresponding in-addr.arpa mappings. The proposed method is fully
compatible with the original DNS lookup mechanisms specified in [1], i.e.
there is no need to modify the lookup algorithm used, and there should be
no need to modify any software which does DNS lookups either.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-degroot-classless-inaddr-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-degroot-classless-inaddr-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (192.12.192.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-degroot-classless-inaddr-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950522134401.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-degroot-classless-inaddr-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-degroot-classless-inaddr-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950522134401.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10028;
22 May 95 14:22 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa10021;
22 May 95 14:22 EDT
Received: from [192.231.148.11] by CNRI.Reston.VA.US id aa11545;
22 May 95 14:22 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <NAA08950 at pad-thai.cam.ov.com>; Mon, 22 May 1995 13:40:03 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA21512; Mon, 22 May 95 13:39:41 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <NAA08928 at pad-thai.cam.ov.com>; Mon, 22 May 1995 13:39:59 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id NAA16417; Mon, 22 May 1995 13:39:58 -0400
Message-Id: <199505221739.NAA16417 at winkl.cam.ov.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 20-May-1995 1114" <wray at tuxedo.enet.dec.com>
Cc: linn at cam.ov.com, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
In-Reply-To: Your message of "Sat, 20 May 1995 11:46:51 EDT."
<9505201546.AA17147 at us1rmc.bb.dec.com>
Date: Mon, 22 May 1995 13:39:58 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
John,
Thanks for proposing a reasoned compromise. I'd like to suggest
that we proceed using your suggested approach as a basis. What do
others think?
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10114;
22 May 95 14:25 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa10108;
22 May 95 14:25 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11606;
22 May 95 14:25 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <NAA09277 at pad-thai.cam.ov.com>; Mon, 22 May 1995 13:48:25 -0400
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA22597; Mon, 22 May 95 13:48:04 EDT
Received: from krypton.mcc.com (krypton.mcc.com [128.62.30.63]) by turtle.mcc.com (8.6.10/mcc.8.6.9) with SMTP id MAA06778; Mon, 22 May 1995 12:48:04 -0500
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA22774; Mon, 22 May 95 12:48:03 CDT
Date: Mon, 22 May 95 12:48:03 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9505221748.AA22774 at krypton.mcc.com>
To: linn at cam.ov.com
Cc: cat-ietf at mit.edu
In-Reply-To: <199505221436.KAA16308 at winkl.cam.ov.com> (message from John Linn on Mon, 22 May 1995 10:36:26 -0400)
Subject: Re: Status of GSS issues (was ... context functionality ...)
John> I believe we're awaiting preparation of a draft to specify
John> the negotiated mechanism; perhaps Doug Rosenthal and/or
John> Denis Pinkas can comment on its status. Like the Kerberos
John> and SPKM specs, this will be a separate mechanism document,
John> not part of the GSS-API spec itself, and can (I believe)
John> operate to select a common mechanism without
John> application-provided input about mechanism preferences. I
John> don't believe that we've come to agreement about how to
John> restructure QOP parameters, thereby allowing callers to
John> indicate such preferences.
Doug> Yes, that is the intent. The Internet Draft will cover this.
Sorry for the ambiguity.
The "intent" was wrt it being a separate document, and operating "to
select a common mechanism without application-provided input about
mechanism preferences". This is the simplest case, where the
app. doesn't have to specify any preferences.
Now, wrt the QOP parameter, I assumed the message protection QOP will
remain as is for now, i.e. as per a given mechanism (although I still
like Carlisle's original proposal :-). Wrt a mechanism preference
QOP, this could be specified via a parameter on the
init/accept_context calls, or via separate utility functions, etc.
Also, the notion of preferences has to fit with which "side"
(initiator or target) is given precedence when more than one common
mechanism is available. We hope to address these issues in the
negotiation I-D.
- Doug
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10323;
22 May 95 14:34 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa10319;
22 May 95 14:34 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11740;
22 May 95 14:34 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <NAA09250 at pad-thai.cam.ov.com>; Mon, 22 May 1995 13:46:28 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA22392; Mon, 22 May 95 13:46:06 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <NAA09245 at pad-thai.cam.ov.com>; Mon, 22 May 1995 13:46:25 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id NAA16424; Mon, 22 May 1995 13:46:24 -0400
Message-Id: <199505221746.NAA16424 at winkl.cam.ov.com>
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Name type issues (was Re: Status of GSS issues ...)
In-Reply-To: Your message of "Fri, 19 May 1995 14:26:02 EDT."
<199505191826.OAA15806 at winkl.cam.ov.com>
Date: Mon, 22 May 1995 13:46:23 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Re:
>I have noted, as requiring further discussion and resolution, the 5
>May and subsequent discussion of a proposed GSS_Inquire_name() call; I
>was planning to raise that issue shortly.
I'd like to suggest retitling the proposal in this area to be a
specifically descriptive "GSS_Get_Mechs_for_name()", to reserve the
prospect that it might in future become possible to inquire about
other attributes of a name. I'd also like to suggest that a
GSS_Get_Mechs_for_name() routine should accept as input an internal
name and return an OID set identifying the set of mechanisms on the
local system which can process that name. This recasts the original
proposal, which accepted either an internal name, an external name, or
both, in the interests of simplicity and uniformity with other GSS-API
routines (few of which operate on external names). A holder of an
external name would probably be passing that name (along with its name
type descriptor) to GSS_Import_name() in any event to make use of it
within GSS-API. Therefore, it strikes me the import-related
processing might be performed most efficiently once within
GSS_Import_name() rather than being replicated in
GSS_Get_Mechs_for_name() as well. Questions for the list:
(1) What's the sentiment about whether a routine to identify mechanisms
supporting a particular name should be included in GSS-V2?
(2) If (per (1)) such a routine is desired, is the approach as suggested
above acceptable?
>Also re naming, there's the pending question (Ted Ts'o, 13 April) of
>whether we should define a GSS-level name type for host-based service.
The apparent straightforward means to accomplish this would be to
promote the "Host-Based Service Name Form", as described in
draft-ietf-cat-kerb5gss-02.txt, from something Kerberos-oriented to a
GSS-level construct, to be documented in GSS-V2. Quoting from
draft-ietf-cat-kerb5gss-02.txt:
>2.1.2. Host-Based Service Name Form
>
> This name form shall be represented by the Object Identifier {iso(1)
> member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
> generic(1) service_name(4)}. The recommended symbolic name for this
> type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME".
>
> This name type is used to represent services associated with host
> computers. The two parts of this name form, which is constructed as:
>
> service at hostname
>
> can be supported with Kerberos V5 technology by passing those name
> parts as the first two arguments to the Kerberos V5 library function
> krb5_sname_to_principal, with the type argument set to
> KRB5_NT_SRV_HST. This processing canonicalizes the hostname (by
> attempting a DNS lookup and using the fully-qualified domain name
> returned, or using the name as input should the DNS lookup fail), and
> ensures that its characters are lower case. No facility is currently
> provided for explicit specification of a Kerberos realm.
I think it would be reasonable and useful to document this type (less the
Kerberos-specific commentary in the last paragraph, and with a different
recommended symbolic name) in GSS-V2. Further, it could be convenient
to default the hostname to the local host if no "@" appears; this would
enable, e.g., server executables to pass a canned name into credential
acquisition and receive credentials with a name corresponding to their
service on the local host. What's the sentiment on:
(3) including a host-based service name type at the GSS level?
(4) allowing the host name to be defaulted?
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11535;
22 May 95 15:52 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa11531;
22 May 95 15:52 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13282;
22 May 95 15:52 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <PAA11877 at pad-thai.cam.ov.com>; Mon, 22 May 1995 15:06:29 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA04589; Mon, 22 May 95 15:06:07 EDT
Received: from dun-dun-noodles.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <PAA11873 at pad-thai.cam.ov.com>; Mon, 22 May 1995 15:06:26 -0400
Received: from localhost by dun-dun-noodles.cam.ov.com (8.6.10/4.7) id PAA11975; Mon, 22 May 1995 15:06:24 -0400
Message-Id: <199505221906.PAA11975 at dun-dun-noodles.cam.ov.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 20-May-1995 1114" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
In-Reply-To: Your message of "Sat, 20 May 1995 11:46:51 EDT."
<9505201546.AA17147 at us1rmc.bb.dec.com>
Date: Mon, 22 May 1995 15:06:24 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
In message <9505201546.AA17147 at us1rmc.bb.dec.com>, "John Wray, Digital DPE, (508) 486-5210 20-May-1995 1114" <wray at tuxedo.enet.dec.com> writes:
>> _Don't_ expect such a context token to be portable across GSSAPI
>> implementation (i.e. if a given implementation creates an
>> inter-process context token, then only that implementation will be
>> able to import it).
If you're going to do that, why bother having it in the spec at all?
We're going to have a bear of a time finding independent
interoperating implementations of something which is defined to be
implementation-dependent.
This makes it almost entirely useless, especially since there is no
way to determine at run-time which implementation is in use.
In short, I believe that interoperability between implementations is a
requirement, or the feature is useless. (This statement is pretty
much generalizable to any IETF standard, really.)
>> _Don't_ document these functions as externalizing context data. To
>> avoid any implication that these routines do create a "flattened"
>> externalized structure containing context data, call them something
>> like gss_export_local_security_context and
>> gss_import_local_security_context. Encourage implementations to
>> protect the context data in some way (either by encryption, or by
>> actually using some IPC mechanism under-the-covers within the GSSAPI
>> implementation, with the token simply acting as a synchronization
>> mechanism).
This sort of implementation would make implementation portability
impossible, but since you don't care about that, you're not being
inconsistent. However, again, I think that any solution which doesn't
give interoperability between implementations is not useful.
I also think that the "local" in the function names is redundant. You
aren't going to export a non-local context :-)
All the other requirements you've specified make sense.
At this point, I have a compromise compromize.
Define two context flag bits. The first is set if and only if the
mechanism allows gss_{import,export}_sec_context() at all. The second
is set if and only if the resulting token uses an encoding in the
mechanism specification, making it portable across implementations.
The former would be useful if the two processes had some out-of-band
knowledge that they were both using the same mechanism. For example,
if a process forks, it is safe for the parent to assume the child is
using the same implementation. The second bit would be useful for
applications like Ted's and Danny's, where is is not necessarily the
case that the listener or user-mode process is using the same
implementation as the transaction processor or kernel.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11707;
22 May 95 16:03 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa11703;
22 May 95 16:03 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13548;
22 May 95 16:03 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <PAA12437 at pad-thai.cam.ov.com>; Mon, 22 May 1995 15:21:09 -0400
Received: from koriel.Sun.COM by MIT.EDU with SMTP
id AA06904; Mon, 22 May 95 15:20:46 EDT
Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
id AA29712; Mon, 22 May 95 12:20:44 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-52.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA24723; Mon, 22 May 1995 12:20:42 -0700
Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id MAA29136; Mon, 22 May 1995 12:20:38 -0700
Received: by elrond.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id MAA00561; Mon, 22 May 1995 12:20:27 -0700
Date: Mon, 22 May 1995 12:20:27 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199505221920.MAA00561 at elrond.Eng.Sun.COM>
To: linn at cam.ov.com
Subject: Re: Name type issues (was Re: Status of GSS issues ...)
Cc: cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
>John,
I really have no strong feelings one way or the other about your suggestion :
> I'd like to suggest retitling the proposal in this area to be a
> specifically descriptive "GSS_Get_Mechs_for_name()", to reserve the
> prospect that it might in future become possible to inquire about
> other attributes of a name.
However, I don't quite follow your reasoning. If there might be other attributes
of a name about which an application could inquire, wouldn't you
want a single routine to accomplish this? GSS_Get_Mechs_for_name() would only
be useful for getting the Mechs associated with a name. Why would you want
another routine to get some other attribute of a name? This doesn't seem
to follow existing practice codified in, say, Gss_inquire_cred().
I do disagree with your other point :
> I'd also like to suggest that a
> GSS_Get_Mechs_for_name() routine should accept as input an internal
> name and return an OID set identifying the set of mechanisms on the
> local system which can process that name. This recasts the original
> proposal, which accepted either an internal name, an external name, or
> both, in the interests of simplicity and uniformity with other GSS-API
> routines (few of which operate on external names). A holder of an
> external name would probably be passing that name (along with its name
> type descriptor) to GSS_Import_name() in any event to make use of it
> within GSS-API. Therefore, it strikes me the import-related
> processing might be performed most efficiently once within
> GSS_Import_name() rather than being replicated in
> GSS_Get_Mechs_for_name() as well.
An application may very well want to decide whether to communicate with a
named entity based on which mechanisms allow its use. In order to discover
this under the above proposal, it would first have to import the name,
then call GSS_Get_Mechs_for_name() and examine the OIDs. While this is
certainly possible, it does introduce an inefficiency that seems gratuitous.
Dan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13105;
22 May 95 16:50 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa13101;
22 May 95 16:50 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14560;
22 May 95 16:50 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <QAA14055 at pad-thai.cam.ov.com>; Mon, 22 May 1995 16:05:19 -0400
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA13420; Mon, 22 May 95 16:04:47 EDT
Received: from sickly.cybersafe.com (sickly.cybersafe.com [192.156.168.11]) by kerby.ocsg.com (8.6.12/8.6.11, dpg hack 11mar95) with SMTP id NAA13832; Mon, 22 May 1995 13:04:42 -0700
Received: by sickly.cybersafe.com (NX5.67d/NX3.0S)
id AA20661; Mon, 22 May 95 13:04:40 -0700
Date: Mon, 22 May 95 13:04:40 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <dennisg at sickly.cybersafe.com>
Message-Id: <9505222004.AA20661 at sickly.cybersafe.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: "John Wray, Digital DPE,\
(508) 486-5210 20-May-1995 1114" <wray at tuxedo.enet.dec.com>
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Cc: linn at cam.ov.com, cat-ietf at mit.edu
Reply-To: dennis.glatting at cybersafe.com
> Date: Sat, 20 May 95 11:46:51 EDT
> From: "John Wray, Digital DPE, (508) 486-5210 20-May-1995 1114"
<wray at tuxedo.enet.dec.com>
>
> How about this as a possible compromise:
>
The compromises seem reasonable to me. Your proposal
gives CAT members time to acquire real-life
implementation experience and to share those
experiences without being locked into a less than
satisfactory interface.
I don't know of an instance where someone is using
different GSS-API implementations on the same host so I
don't believe export/import interoperability is
important at this time.
I like the idea of documentating the pitfalls, areas of
non-portability, and non-interoperable areas. It is
very up-front.
> One thing the above doesn't do is allow the exporting
> application to specify the target process, so that the
> GSSAPI implementation could restrict transfer to just
> that one process. This means that the context transfer
> token must be protected in transit, which may not be
> feasible in all OSes and environments. I'd like to see an
> input to gss_export_local_security_context that
> somehow specifies the target process, so that (if the
> GSSAPI implementation does enforce access control) it
> can also enforce the wishes of the context exporter.
> However, I can't think of a sufficiently general way of
> describing a target process, although some sort of large
> integer is probably good enough for a PID on most OSes.
>
Perhaps implementation of an input to the export
function could be postponed until authorization
progresses?
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13930;
22 May 95 17:36 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa13926;
22 May 95 17:36 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15463;
22 May 95 17:36 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <RAA16099 at pad-thai.cam.ov.com>; Mon, 22 May 1995 17:02:03 -0400
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA25213; Mon, 22 May 95 17:01:41 EDT
Received: by dcl.MIT.EDU (5.0/4.7) id AA20436; Mon, 22 May 1995 17:01:41 +0500
Date: Mon, 22 May 1995 17:01:41 +0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9505222101.AA20436 at dcl.MIT.EDU>
To: "John Wray, Digital DPE, 486-5210 20-May-1995 1114" <wray at tuxedo.enet.dec.com>
Cc: linn at cam.ov.com, cat-ietf at mit.edu, wray at tuxedo.enet.dec.com
In-Reply-To: John Wray, Digital DPE, (508) 486-5210 20-May-1995 1114's message of Sat, 20 May 95 11:46:51 EDT,
<9505201546.AA17147 at us1rmc.bb.dec.com>
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 2726
(My apologies for sending this twice. The dec.com mailer mangled the
cat-ietf mailing address, and I forgot to unmangle it before sending my
reply.)
Date: Sat, 20 May 95 11:46:51 EDT
From: "John Wray, Digital DPE, (508) 486-5210 20-May-1995 1114" <wray at tuxedo.enet.dec.com>
_Don't_ document these functions as externalizing context data. To
avoid any implication that these routines do create a "flattened"
externalized structure containing context data, call them something
like gss_export_local_security_context and
gss_import_local_security_context. Encourage implementations to
protect the context data in some way (either by encryption, or by
actually using some IPC mechanism under-the-covers within the GSSAPI
implementation, with the token simply acting as a synchronization
mechanism).
This sounds like it's merely a naming issue; if
"gss_export_local_security_context" makes people feel better than
"gss_externalize_context", that's fine with me. The conditions you
listed (not portable across different implementations of the same GSS
mechanism, not portable to different hosts, can only be imported once
and can not be used by the exporting process after it has been exported,
etc) are pretty much the ones I described for gss_externalize_context().
As far as allocating an additional bit in the context flags and new
error-statuses to mean "operation not supported" and "local policy
violated" that sounds fine to me.
One thing the above doesn't do is allow the exporting application to
specify the target process, so that the GSSAPI implementation could
restrict transfer to just that one process. This means that the
context transfer token must be protected in transit, which may not be
feasible in all OSes and environments. I'd like to see an input to
gss_export_local_security_context that somehow specifies the target
process, so that (if the GSSAPI implementation does enforce access
control) it can also enforce the wishes of the context exporter.
However, I can't think of a sufficiently general way of describing a
target process, although some sort of large integer is probably good
enough for a PID on most OSes.
As you point out, this is inherently OS specific. I'm not sure it's
really necessary, because in the worst case, OS's that have no means of
transfering the context can simply establish their own GSS context
between the two processes and call gss_seal on the exported context.
I'm not sure that there really are that many OS's where you two
communicating processes on the same host have no way of securely
exchange data via some sort of IPC process, anyway. What examples did
you have in mind?
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14024;
22 May 95 17:48 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa14020;
22 May 95 17:48 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15684;
22 May 95 17:48 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <RAA16479 at pad-thai.cam.ov.com>; Mon, 22 May 1995 17:12:21 -0400
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA25924; Mon, 22 May 95 17:10:37 EDT
Received: by dcl.MIT.EDU (5.0/4.7) id AA20442; Mon, 22 May 1995 17:10:38 +0500
Date: Mon, 22 May 1995 17:10:38 +0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9505222110.AA20442 at dcl.MIT.EDU>
To: Marc Horowitz <marc at cam.ov.com>
Cc: "John Wray, Digital DPE, 486-5210 20-May-1995 1114" <wray at tuxedo.enet.dec.com>,
cat-ietf at mit.edu
In-Reply-To: Marc Horowitz's message of Mon, 22 May 1995 15:06:24 -0400,
<199505221906.PAA11975 at dun-dun-noodles.cam.ov.com>
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 2627
Date: Mon, 22 May 1995 15:06:24 -0400
From: Marc Horowitz <marc at cam.ov.com>
In message <9505201546.AA17147 at us1rmc.bb.dec.com>, "John Wray, Digital DPE, (508) 486-5210 20-May-1995 1114" <wray at tuxedo.enet.dec.com> writes:
>> _Don't_ expect such a context token to be portable across GSSAPI
>> implementation (i.e. if a given implementation creates an
>> inter-process context token, then only that implementation will be
>> able to import it).
If you're going to do that, why bother having it in the spec at all?
We're going to have a bear of a time finding independent
interoperating implementations of something which is defined to be
implementation-dependent.
This makes it almost entirely useless, especially since there is no
way to determine at run-time which implementation is in use.
In short, I believe that interoperability between implementations is a
requirement, or the feature is useless. (This statement is pretty
much generalizable to any IETF standard, really.)
We need it in the spec because we want the *API* to be standardized, so
that client applications can be written in a standard way. If the
externalized context isn't allowed to leave the host on which it was
generated, it seems at least somewhat reasonable to me to say that the
exact format of the externalized context is implementation dependent.
After all, the exact internals of a context structure of two
implementations of the Kerberos V5 mechanism might be quite different
--- why should we constrain the format of the externalized context?
It might be possible that two processes on the same host might be using
different implementations of the same mechanism, but to constrain the
problem by requiring that two co-operating processes on the same host
that want to pass contexts back and forth have to use the same
implementation doesn't seem unduly restrictive. Do you really believe
we need a more general solution?
This sort of implementation would make implementation portability
impossible, but since you don't care about that, you're not being
inconsistent. However, again, I think that any solution which doesn't
give interoperability between implementations is not useful.
I assumed from John's description that while a particular implementation
might use IPC "under the covers", from the application's perspective,
all it needs to do is to securely transfer the block of memory returned
from gss_externalize_context() to the new process, which calls
gss_internalized_context() on it. If IPC is being used internally, the
application won't care.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14561;
22 May 95 18:42 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa14557;
22 May 95 18:42 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16581;
22 May 95 18:42 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <SAA18453 at pad-thai.cam.ov.com>; Mon, 22 May 1995 18:17:00 -0400
Received: from koriel.Sun.COM by MIT.EDU with SMTP
id AA00540; Mon, 22 May 95 18:16:31 EDT
Received: from Eng.Sun.COM ([129.146.1.13]) by Sun.COM (koriel.Sun.COM)
id AA08431; Mon, 22 May 95 11:00:59 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-52.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA13050; Mon, 22 May 1995 10:57:37 -0700
Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id KAA23941; Mon, 22 May 1995 10:57:35 -0700
Received: by elrond.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id KAA00531; Mon, 22 May 1995 10:57:24 -0700
Date: Mon, 22 May 1995 10:57:24 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199505221757.KAA00531 at elrond.Eng.Sun.COM>
To: wray at tuxedo.enet.dec.com
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Cc: cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
John,
Your proposal works for my application (user-level support of gssapi for kernel
OS services).
However, let me comment on one thing :
>
> One thing the above doesn't do is allow the exporting application to specify
> the target process, so that the GSSAPI implementation could restrict transfer
> to just that one process. This means that the context transfer token must be
> protected in transit, which may not be feasible in all OSes and environments.
> I'd like to see an input to gss_export_local_security_context that somehow
> specifies the target process, so that (if the GSSAPI implementation does
> enforce access control) it can also enforce the wishes of the context exporter.
> However, I can't think of a sufficiently general way of describing a target
> process, although some sort of large integer is probably good enough for a PID
> on most OSes.
For user-level to kernel, specifying a uid will work. Howerver, the only way
I see to enforce user-level to user-level target access control, unless some
sort of page memory mapping is set up as Dennis Gladding suggested, is by
flattening the context data, encrypting it using a separate gssapi security
context associated with that uid (is a uid->principal_name mapping required
here?) and handing it off to the target. The target will only be able to
decrypt it if it can access the uid security context that the initiator
used to protect the flattened context. This, of course, raises the issue of
how the uid security context is established and accessed by all processes
operating on the uid's behalf and that want to transfer security contexts
between them.
Dan
Dan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00861;
23 May 95 5:24 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00856;
23 May 95 5:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01950;
23 May 95 5:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00847;
23 May 95 5:24 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00843;
23 May 95 5:24 EDT
Received: from domen.uninett.no by CNRI.Reston.VA.US id aa01945;
23 May 95 5:24 EDT
Received: from dale.uninett.no by domen.uninett.no with SMTP (PP)
id <21919-0 at domen.uninett.no>; Tue, 23 May 1995 11:25:03 +0200
Received: from dale.uninett.no (localhost [127.0.0.1])
by dale.uninett.no (8.6.9/8.6.9) with ESMTP id LAA11221;
Tue, 23 May 1995 11:25:00 +0200
Message-Id: <199505230925.LAA11221 at dale.uninett.no>
X-Mailer: exmh version 1.5.3 12/28/94
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Harald.T.Alvestrand at uninett.no
To: Mark Crispin <MRC at panda.com>
cc: iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
In-reply-to: Your message of "Mon, 22 May 1995 10:20:26 PDT." <MailManager.801163226.5195.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 23 May 1995 11:24:59 +0200
X-Orig-Sender: hta at dale.uninett.no
Mark,
I'm going to take the discussion on the ietf-types list.
No, it's not a joke. Yes, it's got a 4-week last call because it
is not uncontroversial.
Harald A
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03649;
23 May 95 10:33 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03645;
23 May 95 10:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06866;
23 May 95 10:33 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03635;
23 May 95 10:33 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03631;
23 May 95 10:33 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa06861; 23 May 95 10:33 EDT
Received: from ftp.com by ftp.com ; Tue, 23 May 1995 10:26:27 -0400
Received: from mailserv-D.ftp.com by ftp.com ; Tue, 23 May 1995 10:26:27 -0400
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA25391; Tue, 23 May 95 10:23:38 EDT
Date: Tue, 23 May 95 10:23:38 EDT
Message-Id: <9505231423.AA25391 at mailserv-D.ftp.com>
To: Harald.T.Alvestrand at uninett.no
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stev at ftp.com
Cc: MRC at panda.com, iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US
X-Orig-Sender: stev at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Tue May 23 10:23:15 1995]
Originating-Client: d-cell.ftp.com
Content-Length: 1803
Mark,
I'm going to take the discussion on the ietf-types list.
No, it's not a joke. Yes, it's got a 4-week last call because it
is not uncontroversial.
this presents us with a classic example, in my mind, of a flaw in our
current system.
we have some technology, like the chemical MIME type, that, while
useful to a smaller community, is not something that the general
Internet user will need. by the way, smaller, in this context, may
refer to thousands of users. something like a MIME chemical type
may allow chemical researchers to send chemical descriptions between
each other with Mail Enabled Applications.
the problem this produces is that the IETF community, and the people
who actually make the standards process work, need to spend a certain
large amount of effort with every document that enters the standards
track. it matters not if this effects 10 users or 10 million users.
we have evolved into a Standards Organization, while at the same
time, we have lost control of what we make a standard. while it may
be reasonable to have some seal stuck on a given RFC, to indicate
that "hey, if you are going to use the MIME chemical type, please do
it this way so that we all interoperate.", it may not be a wise use
of scarce resources to put these documents through the standards track.
it seems to *me*, having been on both sides of this fence, that we need
something, well, like a corss between a copyright and a standard that
freezes a specification and defines a complete protocol, but doesnt
have the "expense" of a full standard, in either person-time, or
diluting the title Standard.
when we have that, we need to educate some of our WG's that they can
produce worthwhile output without necessarily producing a Standard,
let alone alot of Standards . . .
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05453;
23 May 95 12:55 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05449;
23 May 95 12:55 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10156;
23 May 95 12:55 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <LAA12951 at pad-thai.cam.ov.com>; Tue, 23 May 1995 11:29:06 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA16197; Tue, 23 May 95 11:28:40 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <LAA12946 at pad-thai.cam.ov.com>; Tue, 23 May 1995 11:28:59 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id LAA16738; Tue, 23 May 1995 11:28:58 -0400
Message-Id: <199505231528.LAA16738 at winkl.cam.ov.com>
To: Dan Nessett <Danny.Nessett at eng.sun.com>
Cc: linn at cam.ov.com, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Name type issues (was Re: Status of GSS issues ...)
In-Reply-To: Your message of "Mon, 22 May 1995 12:20:27 PDT."
<199505221920.MAA00561 at elrond.Eng.Sun.COM>
Date: Tue, 23 May 1995 11:28:56 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Dan writes:
>I really have no strong feelings one way or the other about your suggestion :
>
>> I'd like to suggest retitling the proposal in this area to be a
>> specifically descriptive "GSS_Get_Mechs_for_name()", to reserve the
>> prospect that it might in future become possible to inquire about
>> other attributes of a name.
>
>However, I don't quite follow your reasoning. If there might be other attributes
>of a name about which an application could inquire, wouldn't you
>want a single routine to accomplish this? GSS_Get_Mechs_for_name() would only
>be useful for getting the Mechs associated with a name. Why would you want
>another routine to get some other attribute of a name? This doesn't seem
>to follow existing practice codified in, say, Gss_inquire_cred().
I'm trying to learn from experience gained in the interim since the
pre-existing practice in, e.g., GSS_Inquire_cred(), was
documented. At the moment, the mechanism set is the specific name-related
attribute which we're considering the need to extract. In the interest
of concrete progress, I'd prefer not to open a general discussion trying
to anticipate what other attributes might be desired at some point in
the future, and wouldn't be confident that such a discussion could
and would yield a list complete for perpetuity in any case. If we
call the routine GSS_Inquire_name(), implying that it returns all
name-related attributes a caller might inquire about, we'd be faced
in future with the need to break its function signature (likely
breaking backward compatibility) to add new attributes to its list.
If we constrain the currently-defined routine to the currently-scoped
function, new functions serving different purposes can be added later
alongside.
>I do disagree with your other point :
>
>> I'd also like to suggest that a
>> GSS_Get_Mechs_for_name() routine should accept as input an internal
>> name and return an OID set identifying the set of mechanisms on the
>> local system which can process that name. This recasts the original
>> proposal, which accepted either an internal name, an external name, or
>> both, in the interests of simplicity and uniformity with other GSS-API
>> routines (few of which operate on external names). A holder of an
>> external name would probably be passing that name (along with its name
>> type descriptor) to GSS_Import_name() in any event to make use of it
>> within GSS-API. Therefore, it strikes me the import-related
>> processing might be performed most efficiently once within
>> GSS_Import_name() rather than being replicated in
>> GSS_Get_Mechs_for_name() as well.
>
>An application may very well want to decide whether to communicate with a
>named entity based on which mechanisms allow its use. In order to discover
>this under the above proposal, it would first have to import the name,
>then call GSS_Get_Mechs_for_name() and examine the OIDs. While this is
>certainly possible, it does introduce an inefficiency that seems gratuitous.
I don't think the cost of GSS_Import_name()'s processing is likely
to go away in either case. If GSS_Get_mechs_for_name() accepted an
external name, it would probably itself call GSS_Import_name() directly
or at least invoke many of the same underlying modules which support
GSS_Import_name(). While this introduces an extra caller-visible
step, it probably doesn't devolve into many extra processing cycles.
Use of an internal name does make it easier to check the mechanism set
for a name received as output from GSS_Accept_sec_context(), which
could potentially be useful in a scenario where a context target
wants, for some reason, to establish a separate context back to
the initiator using a different mechanism.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05746;
23 May 95 13:26 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05740;
23 May 95 13:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10659;
23 May 95 13:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05726;
23 May 95 13:26 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05661;
23 May 95 13:20 EDT
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa10569;
23 May 95 13:20 EDT
Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.6.11/8.6.10) with ESMTP id MAA18862; Tue, 23 May 1995 12:55:46 -0400
Message-Id: <199505231655.MAA18862 at black-ice.cc.vt.edu>
To: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
cc: ietf-822 at dimacs.rutgers.edu, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: A Chemical Primary Content Type for Multipurpose Internet Mail Extensions to Proposed Standard
In-reply-to: Your message of "Mon, 22 May 1995 11:05:02 EDT."
<9505221105.aa05419 at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Valdis.Kletnieks at vt.edu
Date: Tue, 23 May 1995 12:55:46 -0400
On Mon, 22 May 1995 11:05:02 EDT, you said:
> The IESG has received a request to consider "A Chemical Primary Content
> Type for Multipurpose Internet Mail Extensions"
> <draft-rzepa-chemical-mime-type-01.txt> as a Proposed Standard. This is
> not the product of an IETF Working Group.
Ahh.. A controversial proposal indeed. On the one hand, the draft makes
a good case of why it should not be under application/. On the other hand,
there is the desire to restrict the number of different top-level types.
If we allow chemical/, we will then get to go through this again for each
new structured datatype - and as noted, this would apply whether the
user community numbered 10,000 or 10,000,000.
I hereby propose that a better way to address this issue would be as follows:
1) Create a new primary content-type 'Structured/'. This would be a
generic category, similar to Application/, but with a few minor
distinctions. The Application/ tree does not specify a structure, but
the subtype specifies what you feed the file to. Structured/ would
specify a structure, but not any specific program. For instance,
Postscript only really makes sense if fed to a Postscript interpreter,
whereas the various 'chemical' types could be fed into a wide array of
different processing programs.
2) Register a set of subtypes under the Structured/ tree, such as
Structured/Chemical-cxf, Structured/chemical-mif, Structured/Renderman,
and so on..
This would give the Chemical/ people essentially what they wanted, and
only require one more top-level type. The semantics of dealing with
unrecognized Structured/Wombat types is well understood, so that part
is not a major issue - only the addition of Structured/ once, after which
we can all go out for a <insert beverage here>...
Comments? Counter-proposals?
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06647;
23 May 95 13:57 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06641;
23 May 95 13:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11170;
23 May 95 13:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06608;
23 May 95 13:57 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06482;
23 May 95 13:54 EDT
Received: from sg543689.eng.chrysler.com by CNRI.Reston.VA.US id aa11114;
23 May 95 13:54 EDT
Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id NAA16210; Tue, 23 May 1995 13:54:53 -0400
Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id OAA28712; Tue, 23 May 1995 14:09:42 -0400
Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1)
id AA22220; Tue, 23 May 95 13:59:15 EDT
Message-Id: <9505231759.AA22220 at clncrdv1.is.chrysler.com>
X-Sender: t3125rm at clncrdv1.is.chrysler.com
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 23 May 1995 13:54:41 -0400
To: iesg-secretary at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Robert Moskowitz <rgm3 at is.chrysler.com>
Subject: Re: Last Call: A Chemical Primary Content Type for Multipurpose Internet Mail Extensions to Proposed Standard
Cc: ietf-822 at dimacs.rutgers.edu, ietf at CNRI.Reston.VA.US
At 12:55 PM 5/23/95 -0400, Valdis.Kletnieks at vt.edu wrote:
>On Mon, 22 May 1995 11:05:02 EDT, you said:
>> The IESG has received a request to consider "A Chemical Primary Content
>> Type for Multipurpose Internet Mail Extensions"
>> <draft-rzepa-chemical-mime-type-01.txt> as a Proposed Standard. This is
>> not the product of an IETF Working Group.
>
>I hereby propose that a better way to address this issue would be as follows:
>
>1) Create a new primary content-type 'Structured/'. This would be a
>generic category, similar to Application/, but with a few minor
>distinctions. The Application/ tree does not specify a structure, but
>the subtype specifies what you feed the file to. Structured/ would
>specify a structure, but not any specific program. For instance,
>Postscript only really makes sense if fed to a Postscript interpreter,
>whereas the various 'chemical' types could be fed into a wide array of
>different processing programs.
>
>2) Register a set of subtypes under the Structured/ tree, such as
>Structured/Chemical-cxf, Structured/chemical-mif, Structured/Renderman,
>and so on..
>
>This would give the Chemical/ people essentially what they wanted, and
>only require one more top-level type. The semantics of dealing with
>unrecognized Structured/Wombat types is well understood, so that part
>is not a major issue - only the addition of Structured/ once, after which
>we can all go out for a <insert beverage here>...
>
>Comments? Counter-proposals?
It would seem to me that if Structured/chemical-mif were created then
Application/EDIFACT|x12 should be changed to Structured//EDIFACT|x12
So what makes the chemical people different from the EDI people. I don't
see it.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06926;
23 May 95 14:09 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06918;
23 May 95 14:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11402;
23 May 95 14:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06880;
23 May 95 14:09 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06814;
23 May 95 14:07 EDT
Received: from tipper.oit.unc.edu by CNRI.Reston.VA.US id aa11362;
23 May 95 14:07 EDT
Received: from chivalry (chivalry.eit.COM) by tipper.oit.unc.edu (SMI4.1/FvK 1.02)
id AA25117; Tue, 23 May 95 14:06:56 EDT
Date: Tue, 23 May 1995 11:08:52 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon Spero <ses at tipper.oit.unc.edu>
X-Sender: ses at chivalry
To: Valdis.Kletnieks at vt.edu
Cc: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>,
ietf-822 at dimacs.rutgers.edu, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: A Chemical Primary Content Type for Multipurpose Internet Mail Extensions to Proposed Standard
In-Reply-To: <199505231655.MAA18862 at black-ice.cc.vt.edu>
Message-Id: <Pine.SOL.3.91.950523105358.18695A-100000 at chivalry>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
[I think there's enough bickering going on about standardising mime-types
to make it worth a Last Call. If the IESG had gone ahead without one,
and decided to either accept or reject on their one there would have
been enough people annoyed be the decision to start another round of
mass executions, and it's a lot harder to get bullets in Stockholm]
Personally, I don't have any problems with having a plethora of top-level
types for cases such as this. Apart from the meta-types 'multipart' and
'application', I always thought that the first part of the type name was
meant to distinguish between major 'media' types - text, image, audio,
etc- in general, it's pretty easy to negotiate and convert between
subtypes of a top level type, but much harder to convert at the higher
level.
This distinction is useful, and necessarily implies a top level type for
each major semantic group capable of multiple concrete representations.
Forcing all possible structured types under a single top level simply to
try and impose a pattern of order over an essentially chaotic world is
the Geneva way.
LET A THOUSAND MIME TYPES BLOOM!
Simon
-----
April 19th == 4/19. 4+19 = 23. Any Questions?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07146;
23 May 95 14:19 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07140;
23 May 95 14:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11709;
23 May 95 14:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07129;
23 May 95 14:19 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07075;
23 May 95 14:17 EDT
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa11654;
23 May 95 14:17 EDT
Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.6.11/8.6.10) with ESMTP id OAA11960; Tue, 23 May 1995 14:18:23 -0400
Message-Id: <199505231818.OAA11960 at black-ice.cc.vt.edu>
To: Robert Moskowitz <rgm3 at is.chrysler.com>
cc: ietf-822 at dimacs.rutgers.edu, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: A Chemical Primary Content Type for Multipurpose Internet Mail Extensions to Proposed Standard
In-reply-to: Your message of "Tue, 23 May 1995 13:54:41 EDT."
<9505231759.AA22220 at clncrdv1.is.chrysler.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Valdis.Kletnieks at vt.edu
Date: Tue, 23 May 1995 14:18:23 -0400
On Tue, 23 May 1995 13:54:41 EDT, Robert Moskowitz said:
> It would seem to me that if Structured/chemical-mif were created then
> Application/EDIFACT|x12 should be changed to Structured//EDIFACT|x12
That would seem reasonable to me. In fact, EDI is the sort of thing that
I feel 'Structured/' is more reasonable a place than 'Application/'.
> So what makes the chemical people different from the EDI people. I don't
> see it.
Umm.. Application/EDIFACT was proposed before I proposed Structured/? ;)
/Valdis
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07490;
23 May 95 14:29 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07486;
23 May 95 14:29 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11921;
23 May 95 14:29 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <NAA17357 at pad-thai.cam.ov.com>; Tue, 23 May 1995 13:43:06 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA05487; Tue, 23 May 95 13:42:44 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <NAA17352 at pad-thai.cam.ov.com>; Tue, 23 May 1995 13:43:04 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id NAA16863; Tue, 23 May 1995 13:43:02 -0400
Message-Id: <199505231743.NAA16863 at winkl.cam.ov.com>
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: CAT WG LAST CALL: draft-ietf-cat-spkmgss-03.txt
In-Reply-To: Your message of "Wed, 17 May 1995 11:13:22 EDT."
<199505171513.LAA14801 at winkl.cam.ov.com>
Date: Tue, 23 May 1995 13:43:01 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
I have a specific comment to make on draft-ietf-cat-spkmgss-03.txt,
which I believe warrants a specific correction. The -03 draft
cites RFC-1508, but (unlike draft-ietf-cat-spkmgss-02.txt) defines
InitialContextToken as a SEQUENCE, rather than (per RFC-1508,
Appendix B) as [APPLICATION 0] IMPLICIT SEQUENCE. For purposes
of token demultiplexing in a multi-mechanism environment, the
syntax from 1508 should be used for token framing.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07677;
23 May 95 14:35 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07669;
23 May 95 14:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12047;
23 May 95 14:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07653;
23 May 95 14:35 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07583;
23 May 95 14:32 EDT
Received: from sg543689.eng.chrysler.com by CNRI.Reston.VA.US id aa11992;
23 May 95 14:32 EDT
Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id OAA22938 for <ietf at cnri.reston.va.us>; Tue, 23 May 1995 14:32:52 -0400
Received: from sg543689.eng.chrysler.com (sg543689.eng.chrysler.com [152.116.1.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id OAA28888 for <ietf at cnri.reston.va.us>; Tue, 23 May 1995 14:47:44 -0400
Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id OAA22935 for <ietf at cnri.reston.va.us>; Tue, 23 May 1995 14:32:45 -0400
Received: from sg543689.eng.chrysler.com (sg543689.eng.chrysler.com [152.116.1.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id OAA28885 for <ietf at cnri.reston.va.us>; Tue, 23 May 1995 14:47:37 -0400
Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id OAA22929 for <ietf at cnri.reston.va.us>; Tue, 23 May 1995 14:32:38 -0400
Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id OAA28881 for <ietf at cnri.reston.va.us>; Tue, 23 May 1995 14:47:29 -0400
Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1)
id AA22628; Tue, 23 May 95 14:36:37 EDT
Message-Id: <9505231836.AA22628 at clncrdv1.is.chrysler.com>
X-Sender: t3125rm at clncrdv1.is.chrysler.com
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 23 May 1995 14:32:03 -0400
To: Valdis.Kletnieks at vt.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Robert Moskowitz <rgm3 at is.chrysler.com>
Subject: Re: Last Call: A Chemical Primary Content Type for Multipurpose Internet Mail Extensions to Proposed Standard
Cc: ietf-822 at dimacs.rutgers.edu, ietf at CNRI.Reston.VA.US
At 02:18 PM 5/23/95 -0400, Valdis.Kletnieks at vt.edu wrote:
>On Tue, 23 May 1995 13:54:41 EDT, Robert Moskowitz said:
>> It would seem to me that if Structured/chemical-mif were created then
>> Application/EDIFACT|x12 should be changed to Structured//EDIFACT|x12
>
>That would seem reasonable to me. In fact, EDI is the sort of thing that
>I feel 'Structured/' is more reasonable a place than 'Application/'.
>
>> So what makes the chemical people different from the EDI people. I don't
>> see it.
>
>Umm.. Application/EDIFACT was proposed before I proposed Structured/? ;)
RFC 1767
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07966;
23 May 95 14:43 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07962;
23 May 95 14:43 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa12279; 23 May 95 14:43 EDT
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.12/merit-2.0) with SMTP id OAA14676 for <bgpd at merit.edu>; Tue, 23 May 1995 14:36:06 -0400
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06772;
23 May 95 14:05 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgpd at merit.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-cidrd-classa-00.txt
Date: Tue, 23 May 95 14:05:56 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9505231405.aa06772 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the CIDR Deployment Working Group
of the IETF.
Title : Observations on the use of Components of the Class A
Address Space within the Internet
Author(s) : G. Huston
Filename : draft-ietf-cidrd-classa-00.txt
Pages : 9
Date : 05/22/1995
This document is a commentary on the recommendation that IANA commence
allocation of the presently unallocated components of the Class A address
space to registries, for deployment within the Internet as class-less
address blocks.
The document examines the implications for service providers and end
clients within this environment. The document notes the major conclusion
that widespread adoption of class-less routing protocols is required,
within a relatively rapid timeframe for this recommendation to be
effective.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-cidrd-classa-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cidrd-classa-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (192.12.192.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cidrd-classa-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950522105237.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-cidrd-classa-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cidrd-classa-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950522105237.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08198;
23 May 95 14:54 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08194;
23 May 95 14:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12558;
23 May 95 14:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08182;
23 May 95 14:54 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08178;
23 May 95 14:54 EDT
Received: from potomac.wash.inmet.com by CNRI.Reston.VA.US id aa12548;
23 May 95 14:54 EDT
Received: by potomac.wash.inmet.com (4.1/SMI-4.1)
id AA23471; Tue, 23 May 95 14:48:26 EDT
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Al Gilman <asg at potomac.wash.inmet.com>
Message-Id: <9505231848.AA23471 at potomac.wash.inmet.com>
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
To: stev at ftp.com
Date: Tue, 23 May 1995 14:48:24 -0400 (EDT)
Cc: Harald.T.Alvestrand at uninett.no, MRC at panda.com, iesg at CNRI.Reston.VA.US,
ietf at CNRI.Reston.VA.US
In-Reply-To: <9505231423.AA25391 at mailserv-D.ftp.com> from "stev at ftp.com" at May 23, 95 10:23:38 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1334
To follow up on what stev at ftp.com said ...
the problem this produces is that the IETF community, and the people
who actually make the standards process work, need to spend a certain
large amount of effort with every document that enters the standards
track. it matters not if this effects 10 users or 10 million users.
What you seem to be asking for is a [meta-protocol supporting]
the _registration of application protocols_ for domains which are
closely-clustered sets of [e.g. email enabled] applications
dealing with a recognizable knowledge domain.
You have precedents for registration. The class definition for
what would constitute a "complete protocol" is to my knowledge
fluid, and not a subject of consensus. But that is what the
public angst of a [standard/registration] process is for: make it
reasonable casewise.
The radical option is that the Chemical community may feel the
need of a standard even in the case that the Internet community
does not need the pain of a standardization process. This is
where subclasses and multiple heredity come in. The protocol
could be simultaneously be a standard for chemical documents and
a registered content type as regards MIME. Of course, if the
chemicals can live with a registered type, we should KISS all
round.
Al Gilman
gilman at wash.inmet.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08842;
23 May 95 15:18 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08836;
23 May 95 15:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13054;
23 May 95 15:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08827;
23 May 95 15:18 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08765;
23 May 95 15:16 EDT
Received: from WILMA.CS.UTK.EDU by CNRI.Reston.VA.US id aa12997;
23 May 95 15:16 EDT
Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (cf v2.11c-UTK)
id PAA05208; Tue, 23 May 1995 15:13:31 -0400
Message-Id: <199505231913.PAA05208 at wilma.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Keith Moore <moore at cs.utk.edu>
To: Simon Spero <ses at tipper.oit.unc.edu>
cc: ietf-822 at dimacs.rutgers.edu, ietf at CNRI.Reston.VA.US,
ietf-types at uninett.no
reply-to: ietf-types at uninett.no
Subject: Re: Last Call: A Chemical Primary Content Type for Multipurpose Internet Mail Extensions to Proposed Standard
In-reply-to: Your message of "Tue, 23 May 1995 11:08:52 PDT."
<Pine.SOL.3.91.950523105358.18695A-100000 at chivalry>
Date: Tue, 23 May 1995 15:13:24 -0400
X-Orig-Sender: moore at cs.utk.edu
[for the 822-impaired, please send replies to ietf-types at uninett.no]
> Personally, I don't have any problems with having a plethora of
> top-level types for cases such as this. Apart from the meta-types
> 'multipart' and 'application', I always thought that the first part
> of the type name was meant to distinguish between major 'media'
> types - text, image, audio, etc-
The top level is supposed to give a clue to MTAs, gateways, etc.,
about the kind of media is being transmitted, so that it can choose an
appropriate encoding (say when translating from 8-bit transparent to
7-bit SMTP) or perform filtering based on the capabilities of the
destination environment, without knowledge of the specific type.
This is why chemical/* doesn't cut it -- because it doesn't seem to
require significantly different capabilities from the transmission
media or the destination environment than other top-level MIME types.
There needs to be a way to sub-delegate parts of the type space, but
this is best done by dividing the second part of the MIME type.
"application/chemical.foo" would be just fine.
Keith Moore
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09047;
23 May 95 15:25 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09041;
23 May 95 15:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13238;
23 May 95 15:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09032;
23 May 95 15:25 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08964;
23 May 95 15:23 EDT
Received: from [128.95.135.58] by CNRI.Reston.VA.US id aa13152;
23 May 95 15:23 EDT
Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU
(NX5.67e/UW-NDC Revision: 2.27.MRC ) id AA03498; Tue, 23 May 95 12:23:49 -0700
Date: Tue, 23 May 1995 11:45:32 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Crispin <MRC at cac.washington.edu>
X-Orig-Sender: Mark Crispin <mrc at tomobiki-cho.cac.washington.edu>
Subject: Re: Last Call: A Chemical Primary Content Type for Multipurpose Internet Mail Extensions to Proposed Standard
To: Valdis.Kletnieks at vt.edu
Cc: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>,
ietf-822 at dimacs.rutgers.edu, ietf at CNRI.Reston.VA.US
In-Reply-To: <199505231655.MAA18862 at black-ice.cc.vt.edu>
Message-Id: <MailManager.801254732.3081.mrc at Tomobiki-Cho.CAC.Washington.EDU>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
On Tue, 23 May 1995 12:55:46 -0400, Valdis.Kletnieks at vt.edu wrote:
> On the one hand, the draft makes
> a good case of why it should not be under application/.
I don't think that this case has been made. The counter-example of EDI has
been given. No *technical* benefit is accrued from a "chemical/cxf" as
opposed to "application/chemical-cxf" or "application/chemical;chemtype=cxf".
However, a technical *cost* is paid by adding a new top-level type. Every
MIME application needs to be taught about top-level types. The authors of the
draft seem to think this is necessary and desirable: [page 5]
The over-riding concern is to
preserve this semantic interpretation of the presentation in any
default treatment of the message body.
In other words, no, you can't just ignore CHEMICAL or pretend it's an "other";
you have to read the CHEMICAL spec and implement its defined default action.
I read the arguments in the draft for why APPLICATION could not be used, and
remain unconvinced. The issue appears to be more of esthetics rather than
technical need (unless you want to be paranoid and take the quoted text as
saying that they seriously want to force everybody to implement their type).
The information can be carried in the subtype; furthermore the availability of
parameters provides abundant extension mechanisms.
> 1) Create a new primary content-type 'Structured/'.
> 2) Register a set of subtypes under the Structured/ tree
The problem with STRUCTURED is that there are already some forms under the
APPLICATION tree, such as EDI (and maybe POSTSCRIPT) that would have to be
moved. Nor am I sure this would necessarily satisfy the claimed benefit of a
specific CHEMICAL top-level type in terms of establishing default treatments.
It's possible to argue that this type of data could be a top-level class
called MODEL, but it's still not clear to me that that is needed. If it's
program-readable data (albeit perhaps textual in nature), it can go under
APPLICATION; if it's primarily human-readable, it can go under TEXT.
Other details:
Audeience. CHEMICAL seems to support a very limited audience (although
doubtless it is important to that audience). Contrary to its name, it is not
actually transmitting a chemical, and there is some question as to whether
there is sufficient information in the data to fabricate the chemical in the
absence of external information.
Implementation Cost. There is a significant implementation cost associated
with the addition of a primary type that is *NOT* incurred by secondary types
or by parameters. As was discussed in great detail in the IETF-822 list, it
is desirable to have a small, tightly bounded set of top-level data types that
permit classification and default handling in a very coarse and general
fashion. It is attractive, for example, to represent a primary data type as a
small integer rather than doing innumerable string comparisons; particularly
in distinguishing between TEXT, MULTIPART, MESSAGE, APPLICATION, and
AUDIO/VIDEO/IMAGE. Does CHEMICAL really add another such class, and if so,
can't the class be of wider range than "CHEMICAL"?
Precedent. Contrary to the claims of some, others have admitted that this
will open the floodgates to a plethora of new top level types. The purpose of
subtypes (refer to the IETF-822 archives) was to avoid this consequence.
Conclusion:
The road to hell is paved with good attentions.
The CHEMICAL community has a clearly defined need, and that need must be
addressed. However, they have not made the case that their suggested solution
is necessary, compared to alternatives which would impose a reduced burden
upon other communities. Nor have they made the case that they would have a
higher burden with an alternative solution.
I would prefer to nip all new top-level types in the bud; in fact, given my
druthers I would move AUDIO/VIDEO/IMAGE to be under APPLICATION. But if there
must be a new top-level type, a general class like STRUCTURED or MODEL which
has applicability to other communities is preferable to a special-purpose
class like CHEMICAL.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00505;
24 May 95 4:16 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00501;
24 May 95 4:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01171;
24 May 95 4:16 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00492;
24 May 95 4:16 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00488;
24 May 95 4:16 EDT
Received: from domen.uninett.no by CNRI.Reston.VA.US id aa01166;
24 May 95 4:16 EDT
Received: from dale.uninett.no by domen.uninett.no with SMTP (PP)
id <04910-0 at domen.uninett.no>; Wed, 24 May 1995 10:16:46 +0200
Received: from dale.uninett.no (localhost [127.0.0.1])
by dale.uninett.no (8.6.9/8.6.9) with ESMTP id KAA13804;
Wed, 24 May 1995 10:16:38 +0200
Message-Id: <199505240816.KAA13804 at dale.uninett.no>
X-Mailer: exmh version 1.5.3 12/28/94
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Harald.T.Alvestrand at uninett.no
To: Al Gilman <asg at potomac.wash.inmet.com>
cc: stev at ftp.com, MRC at panda.com, iesg at CNRI.Reston.VA.US,
ietf at CNRI.Reston.VA.US
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
In-reply-to: Your message of "Tue, 23 May 1995 14:48:24 EDT." <9505231848.AA23471 at potomac.wash.inmet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 24 May 1995 10:16:35 +0200
X-Orig-Sender: hta at dale.uninett.no
Stev,
the facts of this particular case were that:
- We had written down rules saying that if you need a top level type, you must
do it standards track. (MIME spec, RFC 1590)
- The chemical guys had successfully argued the case with the ADs that a top
level chemical type was a Good thing, according to the criteria that were set
down for such beasts (draft-rzepa-.....)
We could then make one of two choices:
- Change the rules
- Follow the rules
In this case, we (John and I) wanted to try following the rules. If we are
convinced that the rules are wrong, we can change them, but I think we should
make at least one attempt at following a rule before we conclude that the rule
is broken.
Harald A
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01201;
24 May 95 6:26 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01195;
24 May 95 6:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02940;
24 May 95 6:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01185;
24 May 95 6:26 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01154;
24 May 95 6:24 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa02904;
24 May 95 6:24 EDT
Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <14514(4)>; Wed, 24 May 1995 03:24:51 PDT
Received: by golden.parc.xerox.com id <2761>; Wed, 24 May 1995 03:24:40 -0700
To: ietf-822 at dimacs.rutgers.edu, ietf at CNRI.Reston.VA.US
In-reply-to: Valdis.Kletnieks at vt.edu's message of Tue, 23 May 1995 11:18:23 -0700 <199505231818.OAA11960 at black-ice.cc.vt.edu>
Subject: Re: Last Call: A Chemical Primary Content Type for Multipurpose Internet Mail Extensions to Proposed Standard
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Larry Masinter <masinter at parc.xerox.com>
X-Orig-Sender: Larry Masinter <masinter at parc.xerox.com>
Fake-Sender: masinter at parc.xerox.com
Message-Id: <95May24.032440pdt.2761 at golden.parc.xerox.com>
Date: Wed, 24 May 1995 03:24:26 PDT
In general, the utility of the top level classification of MIME types
is limited.
However, the gross characteristics of image/ audio/ text/ video/ are
useful as far as classification of remote device networks (can you
print it, can you hear it, can you read it as ascii, can you view
moving devices).
Certainly, if we stick to that general justification of top level
types, there is no place at all for 'chemical/'. Or 'structured/'.
I'd like to see if we can avoid having two types registered that
differ only by the top-level type, e.g., don't register image/frob and
application/frob; in particular, this will allow reorganization of the
types into categories, or even making the categorization optional.
There are arguments that at some point we might want application/html
(this is exactly html, except that it allows charset parameters that
aren't allowed by text/*) or image/postscript (this is postscript
that only contains images).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04207;
24 May 95 11:33 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04201;
24 May 95 11:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08542;
24 May 95 11:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04186;
24 May 95 11:32 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03992;
24 May 95 11:25 EDT
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa08410; 24 May 95 11:25 EDT
Received: from ftp.com by ftp.com ; Wed, 24 May 1995 11:26:07 -0400
Received: from mailserv-D.ftp.com by ftp.com ; Wed, 24 May 1995 11:26:07 -0400
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA08557; Wed, 24 May 95 11:23:25 EDT
Date: Wed, 24 May 95 11:23:25 EDT
Message-Id: <9505241523.AA08557 at mailserv-D.ftp.com>
To: asg at potomac.wash.inmet.com
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stev at ftp.com
Cc: ietf at CNRI.Reston.VA.US
X-Orig-Sender: stev at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Wed May 24 11:23:14 1995]
Originating-Client: d-cell.ftp.com
Content-Length: 1810
To follow up on what stev at ftp.com said ...
the problem this produces is that the IETF community, and the people
who actually make the standards process work, need to spend a certain
large amount of effort with every document that enters the standards
track. it matters not if this effects 10 users or 10 million users.
What you seem to be asking for is a [meta-protocol supporting]
the _registration of application protocols_ for domains which are
closely-clustered sets of [e.g. email enabled] applications
dealing with a recognizable knowledge domain.
what i am asking for is a way to define a subset of actions and
definitions, called a protocol, and create a definitive specification
for it. ideally, this document will convey to the reader that this
is the standard way one does Foo, but since the applicability of Foo
is not widespread, the specification does has not been given the
rigid attention that, say, Router Requirements was given:).
an example of this woudl be if i, as a community member, decided to
take the SUPDUP RFC's, clean them up, define some new features (in a
backwards compatible way, ofcourse, i dont want all the supdup users
in the world to have to dead with non-compatible servers), and issue
the specification as a new SUPDUP Standard. ideally, since the target
audience for this is small, i wont have to waste the IESG's most
limited resource (their time).
the big arguement with Chemical, as i understand it, is where it fits
in the MIME tree. while this is an intellectually interesting
arguement, i would prefer they do something like, oh, play a game of
pool to decide it, or have an "egg race" (where you run back and
forth with eggs in spoons), and the winner, well, wins the arguement,
i suppose.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04791;
24 May 95 12:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09563;
24 May 95 12:22 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04723;
24 May 95 12:22 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04590;
24 May 95 12:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09352;
24 May 95 12:09 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04583;
24 May 95 12:09 EDT
To: IETF-Announce: ;
Subject: WG ACTION: Router Requirements (rreq) to conclude
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: The IESG <iesg-secretary at IETF.CNRI.Reston.VA.US>
Date: Wed, 24 May 95 12:09:45 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9505241209.aa04583 at IETF.CNRI.Reston.VA.US>
With the approval of Requirements for IP Version 4 Routers as a
Proposed Standard, the Router Requirements Working Group of the
Internet Area of the IETF has concluded. The mailing list will remain
active.
The IESG contact person is Joel Halpern.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05196;
24 May 95 12:45 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05190;
24 May 95 12:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09995;
24 May 95 12:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05146;
24 May 95 12:45 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05109;
24 May 95 12:43 EDT
Received: from info.cren.net by CNRI.Reston.VA.US id aa09959;
24 May 95 12:43 EDT
Received: from [192.52.179.87] ([192.52.179.87]) by info.cren.net (8.6.10/8.6.4 (CREN)) with SMTP id MAA15884; Wed, 24 May 1995 12:43:27 -0400
Message-Id: <199505241643.MAA15884 at info.cren.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 24 May 1995 12:45:20 -0500
To: Mark Crispin <MRC at cac.washington.edu>, Valdis.Kletnieks at vt.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jim Conklin <conklin at info.cren.net>
Subject: Re: Last Call: A Chemical Primary Content Type for Multipurpose Internet Mail Extensions to Proposed Standard
Cc: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>,
ietf-822 at dimacs.rutgers.edu, ietf at CNRI.Reston.VA.US
I find the case made by Mark and others for NOT adding
discipline-specific top-level types and for severely restricting top-level
types to be a very compelling one.
The approach of using something like "application/chemical;chemtype=cxf"
which he suggests appears to me to be the right one for meeting the
legitimate needs of this community, because I can envision many other
specialized types even within the chemistry community.
jim
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06813;
24 May 95 13:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11601;
24 May 95 13:51 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06799;
24 May 95 13:51 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06636;
24 May 95 13:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-katsube-flow-mapping-dl-conn-00.txt
Date: Wed, 24 May 95 13:46:17 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9505241346.aa06636 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Mapping of IP Flow to Datalink Layer Connection
Author(s) : Y. Katsube, K. Nagami
Filename : draft-katsube-flow-mapping-dl-conn-00.txt
Pages : 14
Date : 05/23/1995
This memo describes an information exchange protocol which enables IP nodes
(hosts or routers) to associate various kinds of "flow" with "datalink
connections". By performing such an information exchange between adjacent
nodes, some of functions performed in the routers (e.g., classification of
datagrams with regard to output interface and/or requesting service class)
would be able to be carried out without (or before) analyzing each datagram
but by referring to a datalink connection ID which conveys the datagram.
This facilitates the routers to provide high-throughput and QoS-supported
services much more efficiently.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-katsube-flow-mapping-dl-conn-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-katsube-flow-mapping-dl-conn-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (192.12.192.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-katsube-flow-mapping-dl-conn-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950523184951.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-katsube-flow-mapping-dl-conn-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-katsube-flow-mapping-dl-conn-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950523184951.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08810;
24 May 95 15:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08804;
24 May 95 15:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14418;
24 May 95 15:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08789;
24 May 95 15:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08655;
24 May 95 15:47 EDT
Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa14324;
24 May 95 15:47 EDT
Received: from UW-Gateway.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(NX5.67e/UW-NDC Revision: 2.27.MRC ) id AA05099; Wed, 24 May 95 12:48:06 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
(NX5.67e/UW-NDC/Panda Revision: 2.27.MRC ) id AA15532; Wed, 24 May 95 12:47:57 -0700
Date: Wed, 24 May 1995 12:29:51 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
To: stev at ftp.com
Cc: asg at potomac.wash.inmet.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <9505241523.AA08557 at mailserv-D.ftp.com>
Message-Id: <MailManager.801343791.13214.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
On Wed, 24 May 95 11:23:25 EDT, stev at ftp.com wrote:
> an example of this woudl be if i, as a community member, decided to
> take the SUPDUP RFC's, clean them up, define some new features (in a
> backwards compatible way, ofcourse, i dont want all the supdup users
> in the world to have to dead with non-compatible servers), and issue
> the specification as a new SUPDUP Standard. ideally, since the target
> audience for this is small, i wont have to waste the IESG's most
> limited resource (their time).
But, one would assume that, as a courtesy, there would be at least a brief
note to the author of the old SUPDUP RFCs informing him of the project, and
soliciting his cooperation. The chance is high (near 100% in this particular
case) that the author would say "That's great! I'm not working on it any
more, so consider me to be out of the loop. But for my historical interest,
let me know what you end up with." But sometimes, the old author may have
some useful insights or memories that may be useful in guiding a revision, as
in avoiding a repeat of the same mistakes or discussions.
So there are unwritten rules. We follow them without really thinking about
them; they just seem to be common sense. But notice how bent out of shape
this community gets when they are not followed!
> the big arguement with Chemical, as i understand it, is where it fits
> in the MIME tree. while this is an intellectually interesting
> arguement, i would prefer they do something like, oh, play a game of
> pool to decide it, or have an "egg race" (where you run back and
> forth with eggs in spoons), and the winner, well, wins the arguement,
> i suppose.
I think that the matter is more significant than this. No one disputes the
utility of the proposal, or the need. However, the "where it fits in the MIME
tree" question decides whether this proposal fits it smoothly with the rest of
the community or not.
A new top-level MIME type is a troublesome burden to (at least some of) us. I
feel that there is no technical reason for CHEMICAL to be top-level (esthetic
considerations notwithstanding), but there are good technical reasons why it
should not.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10722;
24 May 95 17:16 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10716;
24 May 95 17:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16387;
24 May 95 17:16 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10707;
24 May 95 17:15 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10640;
24 May 95 17:12 EDT
Received: from [192.103.3.10] by CNRI.Reston.VA.US id aa16312;
24 May 95 17:12 EDT
Received: from relay.imsi.com by wintermute.imsi.com
id RAA23438 for <ietf at CNRI.Reston.VA.US>; Wed, 24 May 1995 17:12:41 -0400
Received: from snark.imsi.com by relay.imsi.com
id RAA06908 for <ietf at CNRI.Reston.VA.US>; Wed, 24 May 1995 17:12:40 -0400
Received: by snark.imsi.com (4.1/SMI-4.1)
id AA05578; Wed, 24 May 95 17:12:39 EDT
Message-Id: <9505242112.AA05578 at snark.imsi.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
In-Reply-To: Your message of "Wed, 24 May 1995 12:29:51 PDT."
<MailManager.801343791.13214.mrc at Ikkoku-Kan.Panda.COM>
Reply-To: perry at imsi.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 24 May 1995 17:12:38 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Perry E. Metzger" <perry at imsi.com>
On Wed, 24 May 95 11:23:25 EDT, stev at ftp.com wrote:
> an example of this woudl be if i, as a community member, decided to
> take the SUPDUP RFC's, clean them up, define some new features (in a
> backwards compatible way, ofcourse, i dont want all the supdup users
> in the world to have to dead with non-compatible servers), and issue
> the specification as a new SUPDUP Standard. ideally, since the target
> audience for this is small, i wont have to waste the IESG's most
> limited resource (their time).
In the SUPDUP case, however, and in the case of many other similar
efforts, I don't understand why an internet standard is needed in the
first place. Wouldn't publishing the RFC as experimental until such
time as enough users appeared to make the protocol significant be "the
right thing to do"?
Perry
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03036;
25 May 95 10:31 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03030;
25 May 95 10:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09220;
25 May 95 10:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02998;
25 May 95 10:31 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02898;
25 May 95 10:16 EDT
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa08906; 25 May 95 10:16 EDT
Received: from ftp.com by ftp.com ; Thu, 25 May 1995 10:17:06 -0400
Received: from mailserv-D.ftp.com by ftp.com ; Thu, 25 May 1995 10:17:06 -0400
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA02559; Thu, 25 May 95 10:14:21 EDT
Date: Thu, 25 May 95 10:14:21 EDT
Message-Id: <9505251414.AA02559 at mailserv-D.ftp.com>
To: perry at imsi.com
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stev at ftp.com
Cc: ietf at CNRI.Reston.VA.US
X-Orig-Sender: stev at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Thu May 25 10:14:18 1995]
Originating-Client: d-cell.ftp.com
Content-Length: 688
In the SUPDUP case, however, and in the case of many other similar
efforts, I don't understand why an internet standard is needed in the
first place. Wouldn't publishing the RFC as experimental until such
time as enough users appeared to make the protocol significant be "the
right thing to do"?
Perry
you are correct. the problem arises from the fact that, given a few people
who are interested, i could form a working group, take up a meeting slot or
two at a few IETF meetings, and publish a full internet standard.
now, this would be stupid. i know that, you seem to know that. there
are 80+ IETF working groups. how many of *them* understand this?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04246;
25 May 95 12:03 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04240;
25 May 95 12:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11832;
25 May 95 12:03 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04231;
25 May 95 12:03 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04152;
25 May 95 12:00 EDT
Received: from tipper.oit.unc.edu by CNRI.Reston.VA.US id aa11739;
25 May 95 12:00 EDT
Received: by tipper.oit.unc.edu (SMI4.1/FvK 1.02)
id AA02432; Thu, 25 May 95 12:00:59 EDT
Date: Thu, 25 May 1995 12:00:58 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon Spero <ses at tipper.oit.unc.edu>
To: stev at ftp.com
Cc: perry at imsi.com, ietf at CNRI.Reston.VA.US
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
In-Reply-To: <9505251414.AA02559 at mailserv-D.ftp.com>
Message-Id: <Pine.SUN.3.91.950525115145.2412A-100000 at tipper.oit.unc.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 25 May 1995 stev at ftp.com wrote:
>
> you are correct. the problem arises from the fact that, given a few people
> who are interested, i could form a working group, take up a meeting slot or
> two at a few IETF meetings, and publish a full internet standard.
>
> now, this would be stupid. i know that, you seem to know that. there
> are 80+ IETF working groups. how many of *them* understand this?
>
Getting back to the case in point- given that MIME types are really the
concern of domain specific groups, should the IETF cede _full_ control
over _all_ the namespace to the IANA, who can then 'sub-let' authority to
the appropriate people/bodies without the IETF having to get involved?
I.E. no need for last call, or for a working group _within the IETF_
before standardisation. Remember, email is not the most common use for
the MIME type-space anymore.
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04915;
25 May 95 12:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04909;
25 May 95 12:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13232;
25 May 95 12:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04898;
25 May 95 12:50 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04860;
25 May 95 12:48 EDT
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa13173;
25 May 95 12:48 EDT
Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.6.11/8.6.10) with ESMTP id MAA14330; Thu, 25 May 1995 12:49:17 -0400
Message-Id: <199505251649.MAA14330 at black-ice.cc.vt.edu>
To: Simon Spero <ses at tipper.oit.unc.edu>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
In-reply-to: Your message of "Thu, 25 May 1995 12:00:58 EDT."
<Pine.SUN.3.91.950525115145.2412A-100000 at tipper.oit.unc.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Valdis.Kletnieks at vt.edu
Date: Thu, 25 May 1995 12:49:17 -0400
On Thu, 25 May 1995 12:00:58 EDT, Simon Spero said:
> Getting back to the case in point- given that MIME types are really the
> concern of domain specific groups, should the IETF cede _full_ control
> over _all_ the namespace to the IANA, who can then 'sub-let' authority to
> the appropriate people/bodies without the IETF having to get involved?
> I.E. no need for last call, or for a working group _within the IETF_
> before standardisation. Remember, email is not the most common use for
> the MIME type-space anymore.
A total non-starter for top-level types (such as the proposed chemical/).
As has been pointed out, such a change would potentially impact *every*
MIME handler in existence.
I'm not sure if it's even acceptable for subtypes - we're not talking about
delegating OID or domain names or networks numbers, where the semantics are
already understood. Remember, if somebody proposes an 'application/wombat',
there is a requirement that I as the author/maintainer of a MIME-capable
application be able to *implement* application/wombat. This implies that
there exists a specification that I can read and understand.
And the purpose of a Last Call is to give everybody a chance to read the
spec and decide if it's implementable.
Consider the counter-example: How would you feel if you went to implement
an 'Application/Cyberspace', and found out that it had already been
quietly registered, and that the specification was so brain-dead to be
unusable?
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05804;
25 May 95 14:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05797;
25 May 95 14:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15383;
25 May 95 14:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05784;
25 May 95 14:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05654;
25 May 95 13:58 EDT
Received: from WILMA.CS.UTK.EDU by CNRI.Reston.VA.US id aa15310;
25 May 95 13:58 EDT
Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (cf v2.11c-UTK)
id NAA17474; Thu, 25 May 1995 13:58:55 -0400
Message-Id: <199505251758.NAA17474 at wilma.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Keith Moore <moore at cs.utk.edu>
To: Valdis.Kletnieks at vt.edu
cc: Simon Spero <ses at tipper.oit.unc.edu>, ietf at CNRI.Reston.VA.US,
moore at cs.utk.edu
reply-to: ietf-types at uninett.no
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
In-reply-to: Your message of "Thu, 25 May 1995 12:49:17 EDT."
<199505251649.MAA14330 at black-ice.cc.vt.edu>
Date: Thu, 25 May 1995 13:58:46 -0400
X-Orig-Sender: moore at cs.utk.edu
> > Getting back to the case in point- given that MIME types are really the
> > concern of domain specific groups, should the IETF cede _full_ control
> > over _all_ the namespace to the IANA, who can then 'sub-let' authority to
> > the appropriate people/bodies without the IETF having to get involved?
> > I.E. no need for last call, or for a working group _within the IETF_
> > before standardisation. Remember, email is not the most common use for
> > the MIME type-space anymore.
>
> A total non-starter for top-level types (such as the proposed chemical/).
> As has been pointed out, such a change would potentially impact *every*
> MIME handler in existence.
Agreed.
> I'm not sure if it's even acceptable for subtypes - we're not talking about
> delegating OID or domain names or networks numbers, where the semantics are
> already understood.
Actually, I think we need to be able to find a way to sub-delegate
parts of the subtype space to appropriate domain-specific groups.
> Remember, if somebody proposes an 'application/wombat',
> there is a requirement that I as the author/maintainer of a MIME-capable
> application be able to *implement* application/wombat. This implies that
> there exists a specification that I can read and understand.
This is not the case. We do allow MIME types to be defined for
proprietary application-specific formats.
Of course, for types which do have publically available
specifications, we'd like them to be specifications you can implement
from. But even that's not a strict requirement.
> And the purpose of a Last Call is to give everybody a chance to read the
> spec and decide if it's implementable.
Not for MIME types. The purpose of the review is to see whether the
type itself (not the specification for the type) is correctly defined.
(e.g. Is the name reasonable? Is it in the right category? Have the
security considerations been properly examined?)
This discussion should be on the ietf-types at uninett.no list.
Please send replies there.
Keith
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06560;
25 May 95 14:47 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06554;
25 May 95 14:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16370;
25 May 95 14:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06543;
25 May 95 14:46 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06499;
25 May 95 14:44 EDT
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa16299; 25 May 95 14:44 EDT
Received: from ftp.com by ftp.com ; Thu, 25 May 1995 14:45:20 -0400
Received: from mailserv-D.ftp.com by ftp.com ; Thu, 25 May 1995 14:45:20 -0400
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA07008; Thu, 25 May 95 14:42:36 EDT
Date: Thu, 25 May 95 14:42:36 EDT
Message-Id: <9505251842.AA07008 at mailserv-D.ftp.com>
To: Valdis.Kletnieks at vt.edu
Subject: Re: draft-rzepa-chemical-mime-type-01.txt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stev at ftp.com
Cc: ses at tipper.oit.unc.edu, ietf at CNRI.Reston.VA.US
X-Orig-Sender: stev at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Thu May 25 14:42:12 1995]
Originating-Client: d-cell.ftp.com
Content-Length: 800
And the purpose of a Last Call is to give everybody a chance to read the
spec and decide if it's implementable.
no, the purpose of the last call is to let the community voice their
opinion one more time. in theory, the standards track process will
either kick the document out or fix it if it is found to be
lacking in implementability. . . .(nice word, huh?)
Consider the counter-example: How would you feel if you went to implement
an 'Application/Cyberspace', and found out that it had already been
quietly registered, and that the specification was so brain-dead to be
unusable?
as opposed to someone grabbing the Domain, and not using it, and
offering to sell you the right to use it? i would imagine that something
like a MIME tag should not be a big deal.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08079;
25 May 95 16:38 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08075;
25 May 95 16:38 EDT
Received: from [192.231.148.11] by CNRI.Reston.VA.US id aa19547;
25 May 95 16:38 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <PAA11611 at pad-thai.cam.ov.com>; Thu, 25 May 1995 15:47:52 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA05572; Thu, 25 May 95 15:47:29 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <PAA11607 at pad-thai.cam.ov.com>; Thu, 25 May 1995 15:47:50 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id PAA17885; Thu, 25 May 1995 15:47:48 -0400
Message-Id: <199505251947.PAA17885 at winkl.cam.ov.com>
To: Dan Nessett <Danny.Nessett at eng.sun.com>
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
In-Reply-To: Your message of "Mon, 22 May 1995 10:57:24 PDT."
<199505221757.KAA00531 at elrond.Eng.Sun.COM>
Date: Thu, 25 May 1995 15:47:47 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
CAT transferable context fanciers (actually, all CAT fanciers, since
we're discussing routines which all GSS-V2 implementations will be
expected to implement, at least as stubs which can say they don't
support the requested function):
My sense of the discussion on context transfer is that we've reached
rough consensus on John Wray's proposal (as attached) for
GSS_Export_local_security_context() and
GSS_Import_local_security_context(), with restrictions and assumptions
as described in John's message. I propose to reflect these routines in
GSS-V2 as described.
The only open sub-issue based on subsequent discussion seems to be
whether or not to include an input parameter to the export function to
identify the intended target process and, if included, what the format
of that parameter should be. Our available choices appear to be to
omit the parameter entirely, or to state that its type is integer and
its interpretation-defined. Preferences on this point, anyone?
--jl
(Message cat:874)
Received: from inet-gw-1.pa.dec.com by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <MAA28209 at pad-thai.cam.ov.com>; Sat, 20 May 1995 12:11:14 -0400
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95)
id AA21728; Sat, 20 May 95 08:45:47 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA17147; Sat, 20 May 95 11:46:49 -0400
Message-Id: <9505201546.AA17147 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Sat, 20 May 95 11:46:51 EDT
Date: Sat, 20 May 95 11:46:51 EDT
From: "John Wray, Digital DPE, (508) 486-5210 20-May-1995 1114" <wray at tuxedo.enet.dec.com>
To: linn at cam.ov.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
How about this as a possible compromise:
Define a function that will create an inter-process token for the
transfer of a context betwen processes on a single machine, and a
corresponding function that will convert such a token into a context.
_Don't_ document these functions as externalizing context data. To
avoid any implication that these routines do create a "flattened"
externalized structure containing context data, call them something
like gss_export_local_security_context and
gss_import_local_security_context. Encourage implementations to
protect the context data in some way (either by encryption, or by
actually using some IPC mechanism under-the-covers within the GSSAPI
implementation, with the token simply acting as a synchronization
mechanism).
_Don't_ expect such a context token to be portable across GSSAPI
implementation (i.e. if a given implementation creates an
inter-process context token, then only that implementation will be
able to import it).
Define an error-status that can be returned by
gss_import_local_security_context that means "Operation forbidden by
local policy". Encourage implementations to adopt a sensible policy
on which processes may accept contexts (e.g. it may make sense to
share contexts between processes that are running under the same UID,
or are part of the same job).
Define an additional bit in the context flags that will indicate
whether a given context is exportable. Although I doubt many
applications will make run-time decisions based on this flag, it
mirrors what we've done for other context-level properties. It also
allows the transferrability of contexts to be decided on a
per-mechanism basis.
Define an error-status that can be returned by
gss_export_local_security_context that means "Operation not
supported".
Document the fact that passing an open context between processes may
also reveal data about the credential that was used to create the
context, and that therefore contexts should only be passed to
processes that you wouldn't mind revealing your authentication data
to.
Document that a context, once exported/imported, is fully transferred
to the importing process. After gss_export, the context is closed in
the exporting process. After gss_import, the context is fully owned
by the importing process (in particular, the importing process may
refresh the context). Only a single process may import a given
context.
I believe that the above allows for the required functionality, while
emphasizing that context transfer is likely to run into portability
problems. It also allows for a system-specific access-control policy
to be enforced by GSSAPI, in environments where that makes sense.
One thing the above doesn't do is allow the exporting application to
specify the target process, so that the GSSAPI implementation could
restrict transfer to just that one process. This means that the
context transfer token must be protected in transit, which may not be
feasible in all OSes and environments. I'd like to see an input to
gss_export_local_security_context that somehow specifies the target
process, so that (if the GSSAPI implementation does enforce access
control) it can also enforce the wishes of the context exporter.
However, I can't think of a sufficiently general way of describing a
target process, although some sort of large integer is probably good
enough for a PID on most OSes.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08129;
25 May 95 16:43 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08124;
25 May 95 16:43 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19658;
25 May 95 16:43 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <PAA11752 at pad-thai.cam.ov.com>; Thu, 25 May 1995 15:53:07 -0400
Received: from koriel.Sun.COM by MIT.EDU with SMTP
id AB06157; Thu, 25 May 95 15:52:38 EDT
Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
id AA29730; Thu, 25 May 95 12:52:37 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-52.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA23951; Thu, 25 May 1995 12:52:17 -0700
Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id MAA06371; Thu, 25 May 1995 12:52:15 -0700
Received: by elrond.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id MAA00736; Thu, 25 May 1995 12:52:00 -0700
Date: Thu, 25 May 1995 12:52:00 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199505251952.MAA00736 at elrond.Eng.Sun.COM>
To: linn at cam.ov.com
Subject: Re: Name type issues (was Re: Status of GSS issues ...)
Cc: cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
John,
One comment and a question on your reply :
>
> I don't think the cost of GSS_Import_name()'s processing is likely
> to go away in either case. If GSS_Get_mechs_for_name() accepted an
> external name, it would probably itself call GSS_Import_name() directly
> or at least invoke many of the same underlying modules which support
> GSS_Import_name(). While this introduces an extra caller-visible
> step, it probably doesn't devolve into many extra processing cycles.
> Use of an internal name does make it easier to check the mechanism set
> for a name received as output from GSS_Accept_sec_context(), which
> could potentially be useful in a scenario where a context target
> wants, for some reason, to establish a separate context back to
> the initiator using a different mechanism.
>
My choice of the term "inefficiency" led to an ambiguous meaning of my previous
comment. I am not so much concerned with the underlying computer cycles
expended as with requiring the application programmer to go through still
one more multi procedure call sequence in order to accomplish a simple task.
GSSAPI already has many such sequences, which has led to a great deal of
criticism by my colleagues in regards to its complexity. I believe it will
be very common for an application operating in a multi-mechanism environment
to want to determine which mechanisms support a given external name.
Consequently, I think a single call in which an app can give either an internal
or external name is the best choice.
The question I have is the following. Since multi-mechanism libraries will
be implemented by different vendors, won't the naming sub-syntax that a
particular mechanism supports for a given name type have to be defined
somewhere? If so, wouldn't the mechanism document be the most logical place?
Dan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08230;
25 May 95 16:53 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08226;
25 May 95 16:53 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19834;
25 May 95 16:53 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <QAA12367 at pad-thai.cam.ov.com>; Thu, 25 May 1995 16:09:51 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA08284; Thu, 25 May 95 16:09:27 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <QAA12362 at pad-thai.cam.ov.com>; Thu, 25 May 1995 16:09:48 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id QAA17908; Thu, 25 May 1995 16:09:46 -0400
Message-Id: <199505252009.QAA17908 at winkl.cam.ov.com>
To: Dan Nessett <Danny.Nessett at eng.sun.com>
Cc: linn at cam.ov.com, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Name type issues (was Re: Status of GSS issues ...)
In-Reply-To: Your message of "Thu, 25 May 1995 12:52:00 PDT."
<199505251952.MAA00736 at elrond.Eng.Sun.COM>
Date: Thu, 25 May 1995 16:09:46 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Dan,
>My choice of the term "inefficiency" led to an ambiguous meaning of my previous
>comment. I am not so much concerned with the underlying computer cycles
>expended as with requiring the application programmer to go through still
>one more multi procedure call sequence in order to accomplish a simple task.
>GSSAPI already has many such sequences, which has led to a great deal of
>criticism by my colleagues in regards to its complexity. I believe it will
>be very common for an application operating in a multi-mechanism environment
>to want to determine which mechanisms support a given external name.
>Consequently, I think a single call in which an app can give either an internal
>or external name is the best choice.
I'll accept the idea of a routine which would accept either an external
name or an internal name (but not both) if this is an important issue
for integrators. Does anyone else have a strong opinion one way or
the other?
>The question I have is the following. Since multi-mechanism libraries will
>be implemented by different vendors, won't the naming sub-syntax that a
>particular mechanism supports for a given name type have to be defined
>somewhere? If so, wouldn't the mechanism document be the most logical place?
I'm not sure exactly what you mean by "sub-syntax", but a mechanism
document is indeed the appropriate place for mechanisms to define
the external-form structure of the names they can import; both the
Kerberos and SPKM mechanism specifications do this. It's also possible
that name structure definitions may occur elsewhere (e.g., if we
decide to "promote" the host-based service name construct from
the Kerberos spec to mechanism-independent inclusion in GSS-V2,
as is being discussed), or that one mechanism may elect to support
name types as defined by another mechanism. There is, however,
no current requirement that all implementations of a particular
mechanism need represent a given external name in the same internal
form.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08244;
25 May 95 16:54 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08240;
25 May 95 16:54 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19858;
25 May 95 16:54 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <QAA12431 at pad-thai.cam.ov.com>; Thu, 25 May 1995 16:10:26 -0400
Received: from koriel.Sun.COM by MIT.EDU with SMTP
id AA08337; Thu, 25 May 95 16:10:00 EDT
Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
id AA04320; Thu, 25 May 95 13:09:56 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-52.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA26135; Thu, 25 May 1995 13:09:54 -0700
Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id NAA07121; Thu, 25 May 1995 13:09:37 -0700
Received: by elrond.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id NAA00744; Thu, 25 May 1995 13:09:22 -0700
Date: Thu, 25 May 1995 13:09:22 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199505252009.NAA00744 at elrond.Eng.Sun.COM>
To: linn at cam.ov.com
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
John,
It wasn't clear from your message :
>
> My sense of the discussion on context transfer is that we've reached
> rough consensus on John Wray's proposal (as attached) for
> GSS_Export_local_security_context() and
> GSS_Import_local_security_context(), with restrictions and assumptions
> as described in John's message. I propose to reflect these routines in
> GSS-V2 as described.
>
> The only open sub-issue based on subsequent discussion seems to be
> whether or not to include an input parameter to the export function to
> identify the intended target process and, if included, what the format
> of that parameter should be. Our available choices appear to be to
> omit the parameter entirely, or to state that its type is integer and
> its interpretation-defined. Preferences on this point, anyone?
what the exact routine syntax might be. John Wray's message (which you attached)
didn't suggest a syntax, only a different name and explicit semanitics.
Ted's proposal (as forwarded by Marc) was :
OM_uint32 gss_externalize_context (
OM_uint32 * minor_status,
gss_ctx_id_t context_handle,
gss_buffer_t * output_buffer)
OM_uint32 gss_internalize_context (
OM_uint32 * minor_status,
gss_buffer_t input_buffer,
gss_ctx_id_t * context_handle)
Other than the issue of whether an extra argument might be added to identify
the target, should we assume these routines will look like the following ?
OM_uint32 GSS_Export_local_security_context (
OM_uint32 * minor_status,
gss_ctx_id_t context_handle,
gss_buffer_t * output_buffer)
OM_uint32 GSS_Import_local_security_context (
OM_uint32 * minor_status,
gss_buffer_t input_buffer,
gss_ctx_id_t * context_handle)
Dan
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09306;
25 May 95 18:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21809;
25 May 95 18:20 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09291;
25 May 95 18:20 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09085;
25 May 95 18:06 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-armitage-ipatm-encaps-01.txt
Date: Thu, 25 May 95 18:06:53 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9505251806.aa09085 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Issues surrounding a new encapsulation for IP over ATM.
Author(s) : B. Gleeson, G. Armitage
Filename : draft-armitage-ipatm-encaps-01.txt
Pages : 6
Date : 04/24/1995
The Internet Draft draft-ietf-ipatm-ipmc-04.txt ("Support for Multicast
over UNI 3.1 based ATM Networks") describes a mechanism for handling IP
multicast over ATM. In doing so it notes two different mechanisms for
actually achieving the multicasting of packet traffic at the ATM level.
These are meshes of point to multipoint VCs, or ATM level multicast
servers. If a multicast server is in use a host or router may receive a
transmitted packet back on the same interface it was originally sent on.
It is necessary for IP hosts and routers to be able to distinguish and
discard these packets which are reflected back. This memo describes the
issue in greater detail, and suggests a range of new encapsulation options.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-armitage-ipatm-encaps-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-armitage-ipatm-encaps-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (192.12.192.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-armitage-ipatm-encaps-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950524173622.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-armitage-ipatm-encaps-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-armitage-ipatm-encaps-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950524173622.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15264;
25 May 95 23:36 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15260;
25 May 95 23:36 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26685;
25 May 95 23:36 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <WAA23748 at pad-thai.cam.ov.com>; Thu, 25 May 1995 22:57:16 -0400
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA09169; Thu, 25 May 95 22:55:31 EDT
Received: by dcl.MIT.EDU (5.0/4.7) id AA10248; Thu, 25 May 1995 22:55:30 +0500
Date: Thu, 25 May 1995 22:55:30 +0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9505260255.AA10248 at dcl.MIT.EDU>
To: John Linn <linn at cam.ov.com>
Cc: Danny.Nessett at eng.sun.com, wray at tuxedo.enet.dec.com, cat-ietf at mit.edu,
linn at cam.ov.com
In-Reply-To: John Linn's message of Thu, 25 May 1995 15:47:47 -0400,
<199505251947.PAA17885 at winkl.cam.ov.com>
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 322
I'd prefer "gss_export_security_context" and
"gss_import_security_context", as I don't think the word local adds any
value. (What's a remote security context?) But whatever.....
I'd suggest omitting the target of the process, since I suspect it won't
be well secified enough in the general case to matter.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03343;
26 May 95 10:07 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03338;
26 May 95 10:07 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06655;
26 May 95 10:07 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <JAA06319 at pad-thai.cam.ov.com>; Fri, 26 May 1995 09:22:19 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA18951; Fri, 26 May 95 09:21:50 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <JAA06314 at pad-thai.cam.ov.com>; Fri, 26 May 1995 09:22:12 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id JAA18031; Fri, 26 May 1995 09:22:10 -0400
Message-Id: <199505261322.JAA18031 at winkl.cam.ov.com>
To: Theodore Ts'o <tytso at mit.edu>
Cc: John Linn <linn at cam.ov.com>, Danny.Nessett at eng.sun.com,
wray at tuxedo.enet.dec.com, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
In-Reply-To: Your message of "Thu, 25 May 1995 22:55:30 +0500."
<9505260255.AA10248 at dcl.MIT.EDU>
Date: Fri, 26 May 1995 09:22:09 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Here's my proposed text for the high-level spec; in addition to the
attached sections, I've also added the "trans_state" flag value to be
returned by those routines which return context flags. Liking Ted's
idea of shortening the names, I shortened them by a few more letters
:-). Comments, anyone?
--jl
2.2.8: GSS_Export_sec_context call
Inputs:
o context_handle INTEGER
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o interprocess_token OCTET STRING
Return major_status codes:
o GSS_S_COMPLETE indicates that the referenced context has been
successfully exported to a representation in the interprocess_token,
and is no longer available for use by the caller.
o GSS_S_UNAVAILABLE indicates that the context export facility
is not available for use on the referenced context. (This status
should occur only for contexts for which the trans_state value is
FALSE.) Return values other than major_status and minor_status are
undefined.
o GSS_S_CONTEXT_EXPIRED indicates that the provided input context_handle
is recognized, but that the referenced context has expired. Return
values other than major_status and minor_status are undefined.
o GSS_S_NO_CONTEXT indicates that no valid context was recognized
for the input context_handle provided. Return values other than
major_status and minor_status are undefined.
o GSS_S_FAILURE indicates that the requested operation failed for
reasons unspecified at the GSS-API level. Return values other than
major_status and minor_status are undefined.
This call generates an interprocess token for transfer to another
process within an end system, in order to transfer control of a
security context to that process. The recipient of the interprocess
token will call GSS_Import_sec_context() to accept the transfer.
The internal representation contained within the interprocess token
is an implementation-defined local matter. Interprocess tokens
cannot be assumed to be transferable across different GSS-API
implementations. It is recommended that implementations supporting
context transfer protect the transferred context data, either by
using cryptography to protect data within the tokens or by using
interprocess tokens as a means to reference local interprocess
communication facilities (protected by other means) rather than
storing the context data directly within the tokens.
Transfer of an open context may, for certain mechanisms and
implementations, reveal data about the credential which was used to
establish the context. Callers should, therefore, be cautious about
the trustworthiness of processes to which they transfer contexts.
2.2.9: GSS_Import_sec_context call
Inputs:
o interprocess_token OCTET STRING
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o context_handle CONTEXT HANDLE
Return major_status codes:
o GSS_S_COMPLETE indicates that the context represented by the
input interprocess_token has been successfully transferred to
the caller, and is available for future use via the output
context_handle.
o GSS_S_CONTEXT_EXPIRED indicates that the context represented by
the input interprocess_token has expired. Return values other
than major_status and minor_status are undefined.
o GSS_S_NO_CONTEXT indicates that the context represented by the
input interprocess_token was invalid. Return values other than
major_status and minor_status are undefined.
o GSS_S_DEFECTIVE_TOKEN indicates that the input interprocess_token
was defective. Return values other than major_status and minor_status
are undefined.
o GSS_S_UNAUTHORIZED indicates that the context represented by
the input interprocess_token is unauthorized for transfer to the
caller. Return values other than major_status and minor_status
are undefined.
o GSS_S_FAILURE indicates that the requested operation failed for
reasons unspecified at the GSS-API level. Return values other than
major_status and minor_status are undefined.
This call processes an interprocess token generated by
GSS_Export_sec_context(), making the transferred context available
for use by the caller. After a successful GSS_Import_sec_context()
operation, the imported context is fully and exclusively owned by the
importing process.
It is recommended that GSS-API implementations adopt policies suited
to their operational environments in order to define the set of
processes eligible to import a context, but specific constraints in
this area are local matters. Candidate examples include transfers
between processes operating on behalf of the same user identity, or
processes comprising a common job.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04861;
26 May 95 11:17 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04857;
26 May 95 11:17 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08495;
26 May 95 11:17 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <KAA08735 at pad-thai.cam.ov.com>; Fri, 26 May 1995 10:34:02 -0400
Received: from x400gate.bnr.ca by MIT.EDU with SMTP
id AA28176; Fri, 26 May 95 10:33:34 EDT
X400-Received:
by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 26 May 1995 10:31:48 -0400
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 26 May 1995 10:29:17 -0400
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 26 May 1995 10:24:00 -0400
Date: Fri, 26 May 1995 10:24:00 -0400
X400-Originator: /dd.id=1651623/g=carlisle/i=cm/s=adams/@bnr.ca
X400-Mts-Identifier:
[/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.976:26.04.95.14.29.17]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: Theodore ...
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "carlisle (c.m.) adams" <cadams at bnr.ca>
X-Orig-Sender: "carlisle (c.m.) adams" <cadams at bnr.ca>
Message-Id: <"1982 Fri May 26 10:29:30 1995"@bnr.ca>
To: linn at cam.ov.com
Cc: cat-ietf at mit.edu
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality
in GSS-API
Hi John,
>
>Here's my proposed text for the high-level spec; in addition to the
>attached sections, I've also added the "trans_state" flag value to be
>returned by those routines which return context flags. Liking Ted's
>idea of shortening the names, I shortened them by a few more letters
>:-). Comments, anyone?
>
>--jl
The proposal looks good to me. One comment, though: I'm wondering if
the GSS_S_UNAVAILABLE return code should be allowed for
GSS_Import_sec_context as well as GSS_Export_sec_context. It seems to
me that both routines ought to be able to return this...
Carlisle.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05205;
26 May 95 11:30 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05201;
26 May 95 11:30 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08811;
26 May 95 11:30 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <KAA09744 at pad-thai.cam.ov.com>; Fri, 26 May 1995 10:55:11 -0400
Received: from koriel.Sun.COM by MIT.EDU with SMTP
id AA00976; Fri, 26 May 95 10:54:46 EDT
Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
id AA24350; Fri, 26 May 95 07:54:45 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-52.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA14702; Fri, 26 May 1995 07:54:41 -0700
Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id HAA06368; Fri, 26 May 1995 07:54:32 -0700
Received: by elrond.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id HAA01499; Fri, 26 May 1995 07:54:17 -0700
Date: Fri, 26 May 1995 07:54:17 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199505261454.HAA01499 at elrond.Eng.Sun.COM>
To: tytso at mit.edu, linn at cam.ov.com
Subject: Re: Theodore Ts'o: Proposed new externalize context functionality in GSS-API
Cc: cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
John,
The proposed syntax and semantics look good to me.
Dan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06399;
26 May 95 13:09 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06395;
26 May 95 13:09 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11012;
26 May 95 13:09 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <MAA12777 at pad-thai.cam.ov.com>; Fri, 26 May 1995 12:30:26 -0400
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA13349; Fri, 26 May 95 12:30:03 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.12/) with ESMTP
id <MAA12770 at pad-thai.cam.ov.com>; Fri, 26 May 1995 12:30:23 -0400
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id MAA18087; Fri, 26 May 1995 12:30:22 -0400
Message-Id: <199505261630.MAA18087 at winkl.cam.ov.com>
To: John Linn <linn at cam.ov.com>
Cc: Dan Nessett <Danny.Nessett at eng.sun.com>, cat-ietf at mit.edu,
linn at cam.ov.com
Subject: Re: Name type issues (was Re: Status of GSS issues ...)
In-Reply-To: Your message of "Thu, 25 May 1995 16:09:46 EDT."
<199505252009.QAA17908 at winkl.cam.ov.com>
Date: Fri, 26 May 1995 12:30:21 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
How about this for the call to find out what mechanisms can support
a name?
--jl
2.4.17: GSS_Get_mechs_for_name call
Inputs:
o input_is_external BOOLEAN, -- TRUE if input is external name
-- FALSE if input is internal name
o input_name_string OCTET STRING, -- for external name
o input_name_type OBJECT IDENTIFIER, -- type for external name
o input_int_name INTERNAL NAME -- if providing internal name
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o oid_set SET OF OBJECT IDENTIFIER
Return major_status codes:
o GSS_S_COMPLETE indicates that the output oid_set contains
a list of locally supported mechanisms capable of supporting
the input name.
o GSS_S_BAD_NAMETYPE indicates (when an external name is
provided) that the input_name_type is unsupported
by the GSS-API implementation, so the operation could not be
completed. Return values other than major_status and
minor_status are undefined.
o GSS_S_BAD_NAME indicates (when an external name is provided)
that the provided input_name_string is ill-formed in terms
of the input_name_type, so the operation could not be completed.
Return values other than major_status and minor_status are
undefined.
o GSS_S_FAILURE indicates that the requested operation could not
be performed for reasons unspecified at the GSS-API level.
Allows callers to determine the set of locally supported mechanisms
capable of supporting a name. Callers may use the input_is_external
flag as a means to indicate that they are providing either an
external name and type specifier, as would be provided to
GSS_Import_name(), or an internal name as would be provided to
GSS_Init_sec_context().
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab06538;
26 May 95 13:26 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06534;
26 May 95 13:26 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11328;
26 May 95 13:26 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <MAA13131 at pad-thai.cam.ov.com>; Fri, 26 May 1995 12:41:33 -0400
Received: from koriel.Sun.COM by MIT.EDU with SMTP
id AA14736; Fri, 26 May 95 12:41:02 EDT
Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM)
id AA20098; Fri, 26 May 95 09:40:58 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-52.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA25924; Fri, 26 May 1995 09:40:51 -0700
Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id JAA10161; Fri, 26 May 1995 09:40:49 -0700
Received: by elrond.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id JAA01750; Fri, 26 May 1995 09:40:32 -0700
Date: Fri, 26 May 1995 09:40:32 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199505261640.JAA01750 at elrond.Eng.Sun.COM>
To: linn at cam.ov.com
Subject: Re: Name type issues (was Re: Status of GSS issues ...)
Cc: cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
John,
Your proposal for GSS_Get_mechs_for_name() looks good to me.
Dan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06676;
26 May 95 13:32 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06672;
26 May 95 13:32 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11493;
26 May 95 13:32 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP
id <MAA13714 at pad-thai.cam.ov.com>; Fri, 26 May 1995 12:55:21 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: blakley at vnet.ibm.com
Received: from vnet.ibm.com by MIT.EDU with SMTP
id AA16325; Fri, 26 May 95 12:54:57 EDT
Message-Id: <9505261654.AA16325 at MIT.EDU>
Received: from AUSVM1.VNET.IBM.COM by VNET.IBM.COM (IBM VM SMTP V2R3)
with BSMTP id 2464; Fri, 26 May 95 12:54:53 EDT
Date: Fri, 26 May 95 12:54:53 EDT
To: cat-ietf at mit.edu,
================================================== at vnet.ibm.com,
.BITNET at vnet.ibm.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: Name type issues (was Re: Status of GSS issues ...)
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
