Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20000;
16 May 96 13:49 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19995;
16 May 96 13:49 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa03296;
16 May 96 13:49 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa13356;
16 May 96 13:28 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa13342; 16 May 96 13:20 EDT
Received: by relay.tis.com; id NAA25114; Thu, 16 May 1996 13:21:42 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma025108; Thu, 16 May 96 13:21:13 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA01284; Thu, 16 May 96 13:21:26 EDT
Received: by relay.tis.com; id NAA25101; Thu, 16 May 1996 13:21:12 -0400
Received: from rosetta.verisign.com(204.162.64.10) by relay.tis.com via smap (V3.1)
id xma025095; Thu, 16 May 96 13:21:10 -0400
Received: from dustin.verisign.com (Gateway-Outside.Verisign.COM [204.162.64.20]) by rosetta.verisign.com (8.7.4/8.6.12) with ESMTP id KAA21545 for ; Thu, 16 May 1996 10:23:48 -0700 (PDT)
Received: from peter (Peter.verisign.com [192.42.157.77]) by dustin.verisign.com (8.7.4/8.6.12) with SMTP id KAA05893 for ; Thu, 16 May 1996 10:12:28 -0700 (PDT)
Message-Id: <319B576C.AD7@verisign.com>
Date: Thu, 16 May 1996 09:27:24 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Williams
Reply-To: peter@verisign.com
Organization: VeriSign, Inc
X-Mailer: Mozilla 3.0b3 (Win16; I)
Mime-Version: 1.0
To: pem-dev@tis.com
Subject: Public Key Infrastructure
Content-Type: multipart/mixed; boundary="------------17F55BC7423"
X-Orig-Sender: pem-dev-approval@neptune.tis.com
Precedence: bulk
This is a multi-part message in MIME format.
--------------17F55BC7423
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Folks interested in a public source
of information about the concept, nature,
and policies of an X.509 authentication domain (PKI) might wish
to see and understand the civilian activities of the
US Federal Govt: http://csrc.ncsl.nist.gov/pki/
--------------17F55BC7423
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Public Key Infrastructure
Computer Security Resource Clearinghouse WWW Server
Public Key Infrastructure
Pardon our mess.
This page is under construction. Additional files, and additional
formats, will be added in the near future. Your patience is appreciated!
The following documents are products of the Federal PKI Steering Committee's
Technical Working Group. Together, they comprise Version 1 of the Technical
Specifications for the Federal PKI.
This is
Part D: of the Technical Specifications,
Draft Interoperability Profiles for
the Federal PKI.
Contractor Reports: the following reports were developed by contractors
for NIST. These reports do not constitute government positions, but rather
detail the advice and guidance provided to
the government regarding public key infrastructure.
This 1995 report
describes a federal PKI based on a network architecture using the
X.509 version 3 certificate.
--------------17F55BC7423--
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22093;
16 May 96 15:09 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22086;
16 May 96 15:09 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa00879;
16 May 96 15:09 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 11:45:25 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 11:45:23 -0700
Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 11:45:22 -0700
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id LAA10115; Thu, 16 May 1996 11:45:03 -0700
X-Sender: fred@stilton.cisco.com
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 May 1996 11:45:06 -0700
To: braden@isi.edu
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker
Subject: Re: musings
Cc: rreq@isi.edu, braden@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
At 3:30 PM 5/15/96, braden@ISI.EDU wrote:
>The Internet has succeeded because its gurus were willing to be
>pragmatic, doing what worked. You have to balance the (probably
>significant) benefits in the real world of making rreq a full Standard
>against the improvements in it that may result from holding out for
>interoperable implementations.
>
>But it is not clear to me that there is a
>non-trivial content in DEMONSTRATING interoperability of two
>rreq-conformant routers.
My problem is finding rreq-conformant routers. I don't think anything
should be a full standard that doesn't at least have one fully conformant
implementation for each thing that it specifies.
I will have to go through my router and 1812 side by side to answer my own
question thoroughly, but off-hand I can tell you that Cisco does not and
cannot claim full compliance (and depending on how you read the following
paragraph, may not be able to claim conditional compliance) because the
consensus of the working group that went into the document was
non-pragmatic in some respects. Specifically, the spec says
PPP MUST be supported on all general purpose serial interfaces on a
router. The router MAY allow the line to be configured to use point
to point line protocols other than PPP. Point to point interfaces
SHOULD either default to using PPP when enabled or require
configuration of the link layer protocol before being enabled.
General purpose serial interfaces SHOULD require configuration of the
link layer protocol before being enabled.
This is toned down from RFC 1716, the historical predecessor to 1812; that
document said:
PPP MUST be supported on all general purpose serial interfaces on
a router. The router MAY allow the line to be configured to use
serial line protocols other than PPP, all general purpose serial
interfaces MUST default to using PPP.
Cisco routers, if you enable point to point interface and don't specify an
encapsulation, use a proprietary protocol that predates PPP. If we change
that default, we unilaterally change the configuration of our customer's
routers. Guess what, they would report that as a bug.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Meddle not in the affairs of dragons, for you are crunchy and taste
good with ketchup.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22275;
16 May 96 15:14 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22271;
16 May 96 15:14 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa00998;
16 May 96 15:14 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 11:54:55 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 11:54:54 -0700
Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 11:54:53 -0700
Received: from can.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 11:54:53 -0700
Date: Thu, 16 May 96 11:54:57 PDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: braden@isi.edu
Posted-Date: Thu, 16 May 96 11:54:57 PDT
Message-Id: <9605161854.AA25129@can.isi.edu>
Received: by can.isi.edu (4.1/4.0.3-6)
id ; Thu, 16 May 96 11:54:57 PDT
To: braden@isi.edu, fred@cisco.com
Subject: Re: musings
Cc: rreq@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
Fred,
The dilemma that you describe is exactly the reason why one has to
be somewhat philosophical about standardizing comprehensive AS's
like HR and rreq.
It is important to have a requirements spec as a shining
city on the hill, an Ideal towards which all strive, even if the
pragmatics of the real-world prevent absolute full compliance.
I think in retrospect that the HR RFCs did a great deal of good,
even though few if any vendors ever followed ALL its requirements
strictly. I also think that real-world forces make it important for
such a document to be a full standard; otherwise, it is too easy for
non-technical people to dismiss it.
So, my personal recommendation would be to back off from your
(laudable) desire for demonstrated interoperability for
rreq, and GET ON WITH IT.
Bob
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23195;
16 May 96 15:47 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23191;
16 May 96 15:47 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa01626;
16 May 96 15:47 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 12:27:49 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 12:27:48 -0700
Received: from Precision.Guesswork.Com ([204.17.152.100]) by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 12:27:46 -0700
Received: from Precision.Guesswork.Com by Precision.Guesswork.Com ; Thu, 16 May 96 15:27:06 EDT
Received: from woburn ([206.34.72.126]) by Precision.Guesswork.Com ; Thu, 16 May 96 15:27:06 EDT
Message-Id: <2.2.32.19960516152952.002c8814@mail.guesswork.com>
X-Sender: stev@mail.guesswork.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 May 1996 15:29:52 +0000
To: Fred Baker , braden@isi.edu
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: stev knowles
Subject: Re: musings
Cc: rreq@isi.edu, braden@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
sometime around 11:45 AM 5/16/1996 -0700, Fred Baker wrote us a message
containing:
> PPP MUST be supported on all general purpose serial interfaces on a
> router. The router MAY allow the line to be configured to use point
> to point line protocols other than PPP. Point to point interfaces
> SHOULD either default to using PPP when enabled or require
> configuration of the link layer protocol before being enabled.
> General purpose serial interfaces SHOULD require configuration of the
> link layer protocol before being enabled.
>Cisco routers, if you enable point to point interface and don't specify an
>encapsulation, use a proprietary protocol that predates PPP. If we change
>that default, we unilaterally change the configuration of our customer's
>routers. Guess what, they would report that as a bug.
if i bring up a cisco router, and attach a serial line to it, with another
router on the end, who will *only* do PPP, will the Cisco router figure that
out automatically, and DTRT? if two cisco' s connect, that will do either
protocol, woudl they default to PPP? if the remote end only did the
proprietary protocol can the local router figure that out, and DTRT?
if so, i feel that you are certainly within the spirit of the above text. i
woudl imagine that, even if in the second instance, with two newer ciscos,
and having them default to the proprietary protocol, would still conform.
the point of it all was to make it easier on the users . . . .
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23294;
16 May 96 15:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23290;
16 May 96 15:51 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa01758;
16 May 96 15:51 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 12:31:17 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 12:31:16 -0700
Received: from Precision.Guesswork.Com ([204.17.152.100]) by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 12:31:12 -0700
Received: from Precision.Guesswork.Com by Precision.Guesswork.Com ; Thu, 16 May 96 15:31:15 EDT
Received: from woburn ([206.34.72.126]) by Precision.Guesswork.Com ; Thu, 16 May 96 15:31:15 EDT
Message-Id: <2.2.32.19960516153401.002c92b0@mail.guesswork.com>
X-Sender: stev@mail.guesswork.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 May 1996 15:34:01 +0000
To: braden@isi.edu, braden@isi.edu, fred@cisco.com
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: stev knowles
Subject: Re: musings
Cc: rreq@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
sometime around 11:54 AM 5/16/1996 PDT, braden@ISI.EDU wrote us a message
containing:
>So, my personal recommendation would be to back off from your
>(laudable) desire for demonstrated interoperability for
>rreq, and GET ON WITH IT.
it is not clear to me that, based on the current rules, he *can* get on with it.
at some point, as i understand them, the standardization rules require the
document to be revised to remove everything that has not been implemented in
*one* implementation. this does not mean *any* implementation. one was
required to hopefully catch any race conditions . . . . .
it seems to me that *i* dont want the IESG ignoring the rules of the game,
it is a dangerous path to go down. now, if you want to try and change the
rules, i wish you luck, they are meant to be changed . . . .
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27050;
16 May 96 18:38 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27046;
16 May 96 18:38 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa05468;
16 May 96 18:38 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 15:21:00 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 15:20:59 -0700
Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 15:20:58 -0700
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id PAA23060; Thu, 16 May 1996 15:20:51 -0700
X-Sender: fred@stilton.cisco.com
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 May 1996 15:20:53 -0700
To: Robert Elz
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker
Subject: Re: musings
Cc: rreq@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
At 7:36 AM 5/17/96, Robert Elz wrote:
>If one did feel the need to find an implementation of rreq, I'm
>not sure I'd be looking inside routers anyway - in there I'd
>find implementations of BCP, PPP, OSPF, IP TCP, ... For rreq
>I think I'd look in the tender or RFP docs, see whether rreq has
>been specified, and used - that's probably what is an implementation
>of 1812, if anything is.
Oh, it's used. They ask "do you conform?". We say "no." They send money.
Since it was pointed out to me that we can't use path mtu with
PIM/DVMRP/etc because 1812 says "don't do path mtu on multicast packets," I
think that if we're going to go to BCP we should change that first.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Meddle not in the affairs of dragons, for you are crunchy and taste
good with ketchup.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27344;
16 May 96 19:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27340;
16 May 96 19:01 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa05790;
16 May 96 19:01 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 15:45:07 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 15:45:06 -0700
Received: from puli.cisco.com by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 15:45:05 -0700
Received: (billw@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA16694; Thu, 16 May 1996 15:45:01 -0700
Date: Thu, 16 May 96 15:45:00 PDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: William Chops Westfield
To: Fred Baker
Cc: Robert Elz , rreq@isi.edu
Subject: Re: musings
In-Reply-To: Your message of Thu, 16 May 1996 15:20:53 -0700
Message-Id:
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
Of course, RFC1122/23 weren't an unqualified success either. It's shown up
in RFPs, but you can still find plenty of implementations that are broken in
serious ways (according to RFC1122/23) that the vendors seem to have little
interest in correcting.
BillW
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27896;
16 May 96 19:46 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27892;
16 May 96 19:46 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa06338;
16 May 96 19:46 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 16:31:08 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 16:31:07 -0700
Received: from aland.bbn.com by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 16:31:06 -0700
Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id QAA17268; Thu, 16 May 1996 16:29:01 -0700 (PDT)
Message-Id: <199605162329.QAA17268@aland.bbn.com>
To: William Chops Westfield
Cc: Fred Baker , Robert Elz ,
rreq@isi.edu
Subject: Re: musings
In-Reply-To: Your message of Thu, 16 May 96 15:45:00 -0700.
Date: Thu, 16 May 96 16:29:00 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Craig Partridge
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
Of course, RFC1122/23 weren't an unqualified success either. It's shown up
in RFPs, but you can still find plenty of implementations that are broken i
n
serious ways (according to RFC1122/23) that the vendors seem to have little
interest in correcting.
Yep, but also a bunch of changes that RFC 1122/23 required have been made.
I'd say six of one, half dozen of another, except I think more changes were
made than not.
Another note about RFC 1122/23 and this BCP idea for rreq. RFC 1122/23
*amended* the standards. They're the documents that, for instance, are
the standards that say use slow start etc. So BCP wouldn't be right
for RFC 1122/23 and, I believe, wouldn't be right for rreq either.
Craig
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27916;
16 May 96 19:48 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27912;
16 May 96 19:48 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa06367;
16 May 96 19:48 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa19326;
16 May 96 19:13 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa19309; 16 May 96 19:09 EDT
Received: by relay.tis.com; id TAA03679; Thu, 16 May 1996 19:10:43 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma003675; Thu, 16 May 96 19:10:14 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA14857; Thu, 16 May 96 19:10:26 EDT
Received: by relay.tis.com; id TAA03672; Thu, 16 May 1996 19:10:13 -0400
Received: from rosetta.verisign.com(204.162.64.10) by relay.tis.com via smap (V3.1)
id xma003669; Thu, 16 May 96 19:09:54 -0400
Received: from dustin.verisign.com (Gateway-Outside.Verisign.COM [204.162.64.20]) by rosetta.verisign.com (8.7.4/8.6.12) with ESMTP id QAA23439 for ; Thu, 16 May 1996 16:12:33 -0700 (PDT)
Received: from peter (Peter.verisign.com [192.42.157.77]) by dustin.verisign.com (8.7.4/8.6.12) with SMTP id QAA11459 for ; Thu, 16 May 1996 16:01:15 -0700 (PDT)
Message-Id: <319BA92B.49C5@verisign.com>
Date: Thu, 16 May 1996 15:16:11 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Williams
Reply-To: peter@verisign.com
Organization: VeriSign, Inc
X-Mailer: Mozilla 3.0b3 (Win16; I)
Mime-Version: 1.0
To: pem-dev@tis.com
Subject: criticality conformance
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig-Sender: pem-dev-approval@neptune.tis.com
Precedence: bulk
Re: criticality conformance (Peter Williams , 15:13)
To: Mark S Feldman
CC: solo@bbn.com, hoa@rsa.com, pem-dev@tandem.com
Mark,
Ive moved the conversation to a non-work list: on the matter of
conformance to v3 extensions in X.509 certificates, and
a bigger picture discussion of how to organize
extensions to reflect the needs of multiple applications,
consider this memo, brought about by your comment:
> Consenting applications should be able to do what they want. Specific
> applications may restrict the usage of otherwise valid certificates
> based on many criteria, including, but not limited to, extensions.
> The only proprietary, vendor-specific information I've seen pre-loaded
> or hard-coded into applications are vendor-specific "root" keys.
Perhaps you live in a different, safe and secure R&D/defense world to me.
I see
hard-nosed, commercially-driven proliferation of application-defined
extensions;
and proprietary key management (PKI) extensions, used to hook users. The
only
company I have seen which has sought to (a) cater for this inevitable
market-based
reality (b) create a largely application-independent certificate
platform, is, believe it or not, Microsoft.
Extension contents has become the battleground in the certificate-based
application market. Whose definitions will win is...a platform war
prediction. However there may be a technology solution available. At
this stage in the game, however, too much is being earned by
having the proprietary extensions war; so its unlikely to see light of
day! Such is
the nature of open standards; they intefere with profit!
A solution is to have a cert contain [a] content schema rule[s], in which
for each supported object class (where the class notion is applied to
cert extn
types), the various extensions pertaining to that class are
flagged - madatory/optional/required as appropriate to the application
which
will use these extensions, for some purpose. The application will choose
which object
classes it wishes to process from those present in the cert (ignoring
others
classes, with their critical or otherwise extension values).
This notion replaces the criticality notion; which turns out
to be effectively useless, as we have now seen 3 experts say
in ietf-pkix. (It also makes the cert an effective application
enabling capability versus a mere digital id.)
What we did several months ago in the lab was place a schema rule
instance
in the policy qualifier, which noted which extensions in
the extn sequence were mandatory, optional etc. Microsoft extended
this simple idea nicely, by allowing certain policy elements
to have an association with just a *subset* of present
extensions, whose particular identitying & governing content rule is
present - for application
evaluation - in the particular qualifier. You might want to have a look
at the
Microsoft PKI for software licensing and code signing; very well
thoughtout
as a basis for a multi-application "certificate-platform".
Obviously one of the objects represented in the ceriifcate
extention set was intended to be the PKIX-like object, covering
application-independent processing, and general-purpose
key distibution support, which has proven itself on the whole to
be largely application-independent for public networks.
see http://www.microsoft.com/intdev/sdk/safe.htm
et al, perhaps for some context, etc.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28543;
16 May 96 20:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa28539;
16 May 96 20:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa06907;
16 May 96 20:34 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 17:04:15 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 17:04:14 -0700
Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 17:04:13 -0700
Received: from can.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 17:04:13 -0700
Date: Thu, 16 May 96 17:04:11 PDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: braden@isi.edu
Posted-Date: Thu, 16 May 96 17:04:11 PDT
Message-Id: <9605170004.AA25767@can.isi.edu>
Received: by can.isi.edu (4.1/4.0.3-6)
id ; Thu, 16 May 96 17:04:11 PDT
To: billw@cisco.com, craig@aland.bbn.com
Subject: Re: musings
Cc: fred@cisco.com, kre@munnari.oz.au, rreq@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
*>
*> Another note about RFC 1122/23 and this BCP idea for rreq. RFC 1122/23
*> *amended* the standards. They're the documents that, for instance, are
*> the standards that say use slow start etc. So BCP wouldn't be right
*> for RFC 1122/23 and, I believe, wouldn't be right for rreq either.
*>
*> Craig
*>
Craig,
It would not be a difficult exercise to construct a standards-track
document that simply compiled the amendments from 1122/23, and let the
document as a whole be a BCP. There were not very many amendments,
and I think they were clearly indicated.
Bob
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28943;
16 May 96 20:57 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa28937;
16 May 96 20:57 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa07158;
16 May 96 20:57 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 17:37:10 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 17:37:08 -0700
Received: from aland.bbn.com by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 17:37:07 -0700
Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id RAA17719; Thu, 16 May 1996 17:35:09 -0700 (PDT)
Message-Id: <199605170035.RAA17719@aland.bbn.com>
To: braden@isi.edu
Cc: billw@cisco.com, craig@aland.bbn.com, fred@cisco.com, kre@munnari.oz.au,
rreq@isi.edu
Subject: Re: musings
In-Reply-To: Your message of Thu, 16 May 96 17:04:11 -0700.
<9605170004.AA25767@can.isi.edu>
Date: Thu, 16 May 96 17:35:08 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Craig Partridge
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
It would not be a difficult exercise to construct a standards-track
document that simply compiled the amendments from 1122/23, and let the
document as a whole be a BCP. There were not very many amendments,
and I think they were clearly indicated.
Bob:
Thanks for that useful bit (it was precisely that sort of information
I was hoping to winkle out).
Craig
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29679;
16 May 96 21:57 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa29675;
16 May 96 21:57 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa07766;
16 May 96 21:57 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 18:44:18 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 18:44:12 -0700
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 18:44:10 -0700
Received: from localhost by rodan.UU.NET with SMTP
(peer crosschecked as: mo@localhost)
id QQaqag01205; Thu, 16 May 1996 21:44:09 -0400 (EDT)
Message-Id:
To: braden@isi.edu
Cc: fred@cisco.com, rreq@isi.edu
Subject: Re: musings
In-Reply-To: Your message of "Thu, 16 May 1996 11:54:57 PDT."
<9605161854.AA25129@can.isi.edu>
Date: Thu, 16 May 1996 21:44:09 -0400
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mike O'Dell
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
the concept of "interoperable implementations of a requirements
document" is curious to think about. there is no such thing
as an "implementation" of a requirements spec. there can be an
implementation of a system which is believed to meet the requirements
in the spec, and that system could be interoperable with another
system which claimed to meet the requirements, but "interoperability"
has nothing to do with the spec in any real sense because that is
a characteristic of the protocols in the system.
so one can have good interoperability (PPP on cisco talks to PPP
on 3com talks to PPP on Bay talks to PPP on Ascend etc etc) without
any notion of whether the box completely satisfies the requirements.
bottom line: the notion of "two interoperable implementations" as applied to
requirements documents makes no sense in general.
-mo
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06165;
17 May 96 0:27 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06161;
17 May 96 0:27 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa01183;
17 May 96 0:27 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 21:11:33 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 21:11:31 -0700
Received: from Precision.Guesswork.Com ([204.17.152.100]) by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 16 May 1996 21:11:28 -0700
Received: from Precision.Guesswork.Com by Precision.Guesswork.Com ; Fri, 17 May 96 00:10:45 EDT
Received: from edward-bear (Edward-Bear.GUESSWORK.Com) by Precision.Guesswork.Com ; Fri, 17 May 96 00:10:45 EDT
Message-Id: <2.2.32.19960517040300.002d4a2c@mail.guesswork.com>
X-Sender: stev@mail.guesswork.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 17 May 1996 00:03:00 -0400
To: Fred Baker
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: stev knowles
Subject: Re: musings
Cc: braden@isi.edu, rreq@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
sometime around 13:27 5/16/96 -0700, Fred Baker wrote us a message containing:
>Cisco routers do the protocol they're told to. If you don't tell them
>anything, they do the proprietary one. If you tell them to do PPP, they do
>PPP.
>
>Which is to say, they always DTRT, as long as their configuration agrees
>with that of the guy at the other end. :^)
in my opinion, cisco routers fail the test. forgetting RREQ, cisco routers
shoudl be smart enough to DTRT no matter what encapsulation it finds the
other end trying to use, assuming they understand how to deal with it.
sorry, i expected more from CISCO . . . . .
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14641;
17 May 96 10:21 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14637;
17 May 96 10:21 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa07951;
17 May 96 10:21 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Fri, 17 May 1996 07:06:56 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Fri, 17 May 1996 07:06:53 -0700
Received: from Precision.Guesswork.Com ([204.17.152.100]) by venera.isi.edu (5.65c/5.61+local-23)
id ; Fri, 17 May 1996 07:06:50 -0700
Received: from Precision.Guesswork.Com by Precision.Guesswork.Com ; Fri, 17 May 96 10:05:43 EDT
Received: from woburn ([206.34.72.126]) by Precision.Guesswork.Com ; Fri, 17 May 96 10:05:43 EDT
Message-Id: <2.2.32.19960517100753.002b4848@mail.guesswork.com>
X-Sender: stev@mail.guesswork.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 17 May 1996 10:07:53 +0000
To: Mike O'Dell
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: stev knowles
Subject: Re: musings
Cc: Fred Baker , braden@isi.edu, rreq@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
sometime around 08:50 AM 5/17/1996 -0400, Mike O'Dell wrote us a message
containing:
>
>And if I got a box from ANYONE which did what you propose,
>I would not only report it as a bug, but insist they rip it out.
>
> -mo
let me see, if you got a box that just plugged in, and managed to connect to
the other end without you having to figure out what line protocol the other
end was running, you woudl rip it out.
can you explain to me why this is so evil?
i mean, i understand the desire to keep things hard to use, keeps the
children from playing with them, protects our jobs, all that, but . . . . .:)
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17451;
17 May 96 12:20 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17447;
17 May 96 12:20 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa10613;
17 May 96 12:20 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Fri, 17 May 1996 09:01:05 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Fri, 17 May 1996 09:01:03 -0700
Received: from Precision.Guesswork.Com ([204.17.152.100]) by venera.isi.edu (5.65c/5.61+local-23)
id ; Fri, 17 May 1996 09:00:39 -0700
Received: from Precision.Guesswork.Com by Precision.Guesswork.Com ; Fri, 17 May 96 11:59:22 EDT
Received: from woburn ([206.34.72.126]) by Precision.Guesswork.Com ; Fri, 17 May 96 11:59:22 EDT
Message-Id: <2.2.32.19960517120136.002de000@mail.guesswork.com>
X-Sender: stev@mail.guesswork.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 17 May 1996 12:01:36 +0000
To: Mike O'Dell
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: stev knowles
Subject: Re: musings
Cc: Mike O'Dell , Fred Baker ,
braden@isi.edu, rreq@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
sometime around 11:20 AM 5/17/1996 -0400, Mike O'Dell wrote us a message
containing:
>in complex environments, however, you don't want boxes deciding
>things on their own because you have no way of knowing what
>all it decided. and if it decides to listen to and repeat RIP,
>or pick its own address, or any of a few dozen other terrifying things
>I've *seen* boxes try to do to "help" you, you can be very truly
>screwed in a BIG way and it can take many hundred hours to locate.
while i agree with you about it helping with routing protocols (RIP is not
the only one, i probably dont want it peering with anyone else, either. on
the other hand, i would like it to tell me about what it sees)
>the example you cite could be because one end of the line is
>actually mis-configured, but yet it would still start working
>and the error would not be discovered for some time. that is
>very bad.
hey, if you assume everything is OK just because the line comes up, you
deserve to lose. the line coming up at least lets you see what is going on,
and then you can go in and decide that you actually wanted the CISCO
protocol rather than PPP.
when UUNET is installing routers, i imagine that they are first unpacked,
and then configured, before being deployed. if uunet is connecting other
people's routers, i would *imagine* that getting the line up *at all* would
be a big win. it has got to be easier to fix problems when you can talk to
the remote end directly, rather than having to *believe* what that voice on
the other end is telling you.
>so there *does* need to be ONE switch with two positions on the
>outside:
>
> "Zealous Mode" and "Obedient Mode"
>
>you can even ship it with the switch clearly in Zealous Mode, but
>I will change it to "Obedient Mode" when I install it.
so, since you are going over the boxes before anyway, i am sure you will get
all the configuration set correctly before it ever sees a production wire,
so why the flame?
>As Rob Pike once said,
>
> "Most (terminals) which are described as *intellegent*
> are actually just smartass."
>
>same goes for network elements in my book.
well, i believe that the network should be as self configuring as possible .
. . i suppose that is just something we will have to disagree on forever. . . .
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18985;
17 May 96 13:07 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18980;
17 May 96 13:07 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa11746;
17 May 96 13:07 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa03286;
17 May 96 12:46 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa03240; 17 May 96 12:35 EDT
Received: by relay.tis.com; id MAA14245; Fri, 17 May 1996 12:37:14 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma014232; Fri, 17 May 96 12:36:52 -0400
Received: from pulsar.tis.com by tis.com (4.1/SUN-5.64)
id AA08176; Fri, 17 May 96 12:37:04 EDT
Message-Id: <9605171637.AA08176@tis.com>
To: peter@verisign.com
Cc: pem-dev@tis.com, feldman@tis.com, solo@bbn.com, hoa@rsa.com
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Subject: Re: criticality conformance
In-Reply-To: Your message of "Thu, 16 May 1996 15:16:11 PDT."
<319BA92B.49C5@verisign.com>
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/moss-signature";
micalg="md5"; boundary="----- =_aaaaaaaaaa0"
Date: Fri, 17 May 1996 12:39:28 -0400
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark S Feldman
X-Orig-Sender: pem-dev-approval@neptune.tis.com
Precedence: bulk
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2548.832351149.2@tis.com>
...
> Perhaps you live in a different, safe and secure R&D/defense world to me.
No, I think we all pretty much live in the same world:-)
...
> Extension contents has become the battleground in the
> certificate-based application market. Whose definitions will win
> is...a platform war prediction. However there may be a technology
> solution available. At this stage in the game, however, too much is
> being earned by having the proprietary extensions war; so its unlikely
> to see light of day! Such is the nature of open standards; they
> intefere with profit!
I see no problem with application-specific extensions, even
proprietary ones, as long as they do not make the certificates
unusable for other purposes. In the end, and it may take some time,
if vendors make incompatible changes to what they advertised as X.509
certificates to "hook" users, the users will revolt. Making a profit
with open standards is a different game, but it is still winnable.
I see two uses of certificates evolving:
1) Application-specific certificates. They may be perfectly valid
X.509v3, but they are linked back to a special, limited purpose root
or they have special extensions, perhaps carrying information not
available elsewhere. These certificates are proprietary black boxes.
They could just as well be something other than X.509 certificates,
but the application authors chose X.509 as an expedient, marketing
ploy, what have you.
2) Identity certificates that are of general use. More or less the
original PEM model. The problem here is the lack of infrastructure.
This has largely been bypassed in the rush for (1) above. Separate
mechanisms will map identity to authority, privilege, etc.
> A solution is to have a cert contain [a] content schema rule[s], in
> which for each supported object class (where the class notion is
> applied to cert extn types), the various extensions pertaining to that
> class are flagged - madatory/optional/required as appropriate to the
> application which will use these extensions, for some purpose. The
> application will choose which object classes it wishes to process from
> those present in the cert (ignoring others classes, with their
> critical or otherwise extension values).
In the end, isn't the application granting a privilege the sole
arbiter of the validity of a certificate? Maybe, as I said
previously, "validity" is the wrong word. A certificate may be
perfectly valid in the X.509 sense, but it may not be "valid for a
particular purpose."
I may use VeriSign as my root and I may be able to validate your
certificate back to VeriSign, but that does not mean that you may log
into my computer. The certificate-based challenge-response login in
my computer is basing its decision on the validity of the certificate
in the X.509 sense and the distinguished name, issuername/serial
number, or some such. Such a decision could also be made based on
non-critical extensions. Should there be a "valid for login to TIS
systems" extension and should I believe it if I find it in your
otherwise valid certificate? My responses is "No and no."
> This notion replaces the criticality notion; which turns out to be
> effectively useless, as we have now seen 3 experts say in ietf-pkix.
> (It also makes the cert an effective application enabling capability
> versus a mere digital id.)
A specific extensions can easily be critical or non-critical in all
cases. Being able to say otherwise in the certificate with the
criticality flag creates confusion (I think this is similar to your
original question). It is a shame that the OID space for extensions
can't be divided into critical and non-critical (say, even and odd),
creating an atomic bond between the extension and its criticality -- no
need for external, possibly ambiguous, rules identifying extensions as
critical or not.
Mark
====
Trusted Information Systems, Inc. Phone: +1 301 854 6889
3060 Washington Road Direct: +1 301 854 5704
Glenwood, Maryland 21738 FAX: +1 301 854 5363
------- =_aaaaaaaaaa0
Content-Type: application/moss-signature
Content-ID: <2548.832351149.1@tis.com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID: PK,MHcwCgYEVQgBAQICAwADaQAwZgJhAKJzafITUAG5mJfm5I2TPHzYFvzW=
X6VjoFu6n3IWeFdIkw6F1mcJuGrMiASE26EbgO47WImp4CJiRiocwoPb5upi9G2znfUvgigvXD=
IG08D6t6NC5gmWJ7Pvfm00PZx8YQIBAw=3D=3D,EN,1,feldman@tis.com
MIC-Info: RSA-MD5,RSA,d/Yj/vcj81XC8tTeQrfAtuwoScRmiHhxSepNHnpRepeTbPMNwkEa=
IIu/Y4bwECuE/ew4U/T+Xdk+f9B1nnSV5k6LIjKLg7bZBaO1LveRGyZC3ZM0kO3qgrXDeA6GuI=
ag
------- =_aaaaaaaaaa0--
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19997;
17 May 96 13:43 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19992;
17 May 96 13:42 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa12571;
17 May 96 13:42 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa03935;
17 May 96 13:20 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa03921; 17 May 96 13:13 EDT
Received: by relay.tis.com; id NAA15818; Fri, 17 May 1996 13:15:22 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma015804; Fri, 17 May 96 13:14:58 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA10473; Fri, 17 May 96 13:15:06 EDT
Received: by relay.tis.com; id NAA15797; Fri, 17 May 1996 13:14:52 -0400
Received: from rosetta.verisign.com(204.162.64.10) by relay.tis.com via smap (V3.1)
id xma015789; Fri, 17 May 96 13:14:44 -0400
Received: from dustin.verisign.com (Gateway-Outside.Verisign.COM [204.162.64.20]) by rosetta.verisign.com (8.7.4/8.6.12) with ESMTP id KAA26941; Fri, 17 May 1996 10:17:17 -0700 (PDT)
Received: from peter (Peter.verisign.com [192.42.157.77]) by dustin.verisign.com (8.7.4/8.6.12) with SMTP id KAA21082; Fri, 17 May 1996 10:05:57 -0700 (PDT)
Message-Id: <319CA766.27E3@verisign.com>
Date: Fri, 17 May 1996 09:20:54 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Williams
Reply-To: peter@verisign.com
Organization: VeriSign, Inc
X-Mailer: Mozilla 3.0b3 (Win16; I)
Mime-Version: 1.0
To: Mark S Feldman
Cc: pem-dev@tis.com, solo@bbn.com, hoa@rsa.com
Subject: Re: criticality conformance
References: <9605171637.AA08176@tis.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig-Sender: pem-dev-approval@neptune.tis.com
Precedence: bulk
>
> I see two uses of certificates evolving:
>
> 1) Application-specific certificates. They may be perfectly valid
> X.509v3, but they are linked back to a special, limited purpose root
> or they have special extensions, perhaps carrying information not
> available elsewhere. These certificates are proprietary black boxes.
> They could just as well be something other than X.509 certificates,
> but the application authors chose X.509 as an expedient, marketing
> ploy, what have you.
>
> 2) Identity certificates that are of general use. More or less the
> original PEM model. The problem here is the lack of infrastructure.
> This has largely been bypassed in the rush for (1) above. Separate
> mechanisms will map identity to authority, privilege, etc.
The rush is the fact that certificates now solve
an important problem to users - key distribution
supporting a modicum of end-end privacy.
Steve Crocker trained you well in constantly saying (so that
people might eventually believe you) X.509 cannot occur
as there is no infrastructure.
Turns out (now there is money flowing the certs business)
the infrastructure was there all along. D&B have
huge organizational dbs, suitable for auth managament,
and Equifax have huge residential dbs suitable for...
The directory problem has been solved by the Web;
see several directory services now available at
URLs, and cert distribution within those only
required a mime-type...
With refienement, LDAP may well be integrated into
the Web as a locator protocol for more refined
service access, but its immaterial functionally.
> In the end, isn't the application granting a privilege the sole
> arbiter of the validity of a certificate? Maybe, as I said
> previously, "validity" is the wrong word. A certificate may be
> perfectly valid in the X.509 sense, but it may not be "valid for a
> particular purpose."
Of course. certs only perform key distirbution. That key
may be obtained over such a channel which allows the
applciation to assume the properties are suitable
for a given use. In practice such properties
come down to a policy oid, which the app can select on,
and know represent an authenicated channel of authoitative
keying. Subscriber agreement during certiifcate management then
allows consumers to decide whether the policies are suitable
for use in support of purpose A or B, or none. The cert
is itself immaterial; what matters is its background
management procedures embodied in the policy id.
> A specific extensions can easily be critical or non-critical in all
> cases. Being able to say otherwise in the certificate with the
> criticality flag creates confusion (I think this is similar to your
> original question). It is a shame that the OID space for extensions
> can't be divided into critical and non-critical (say, even and odd),
> creating an atomic bond between the extension and its criticality -- no
> need for external, possibly ambiguous, rules identifying extensions as
> critical or not.
We can do this. IETF PKIX creates a pkix oid in the internet space,
and has two subtrees. Into one or the other it reassigns the numbers
of the ISO oids, and all IETF people use the IANA versions. Its
only a number, but with pkix-profiled criticality specialization
suggested by TIS. This is exactly how IETF needs to add
value to the raw ISO work, to make it practicable.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23673;
17 May 96 15:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23669;
17 May 96 15:34 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa14968;
17 May 96 15:34 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa06341;
17 May 96 15:03 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa06322; 17 May 96 14:58 EDT
Received: by relay.tis.com; id OAA19302; Fri, 17 May 1996 14:59:53 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma019296; Fri, 17 May 96 14:59:23 -0400
Received: from pulsar.tis.com by tis.com (4.1/SUN-5.64)
id AA15847; Fri, 17 May 96 14:59:35 EDT
Message-Id: <9605171859.AA15847@tis.com>
To: peter@verisign.com
Cc: Mark S Feldman , pem-dev@tis.com, solo@bbn.com,
hoa@rsa.com
Subject: Re: criticality conformance
In-Reply-To: Your message of "Fri, 17 May 1996 09:20:54 PDT."
<319CA766.27E3@verisign.com> --------
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/moss-signature";
micalg="md5"; boundary="----- =_aaaaaaaaaa0"
Date: Fri, 17 May 1996 15:01:59 -0400
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark S Feldman
X-Orig-Sender: pem-dev-approval@neptune.tis.com
Precedence: bulk
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2713.832359691.2@tis.com>
...
> Steve Crocker trained you well in constantly saying (so that people
> might eventually believe you) X.509 cannot occur as there is no
> infrastructure.
Steve Crocker aside, I believe that X.509 can occur and hope that it
does.
> Turns out (now there is money flowing the certs business) the
> infrastructure was there all along.
I'll grant you that there are communities using certificates and some
of those communities are large, but that's not the same as an
infrastructure. The communities using certificates are doing so for
their own purposes and their certificates are not necessarily used or
accepted by others. It's a start. It's better than what we had
before (nothing), but still has a way to go before it reaches
infrasturture status.
> D&B have huge organizational dbs, suitable for auth managament, and
> Equifax have huge residential dbs suitable for...
Yes, D&B, Equifax, TRW and the like *could* cache such information and
make it available, which is pretty much what they do now with credit
information. They may be part of the solution in the future, but
they're not right now.
> The directory problem has been solved by the Web; see several
> directory services now available at URLs, and cert distribution within
> those only required a mime-type...
Solved? No, Making progress? Yes.
> With refienement, LDAP may well be integrated into the Web as a
> locator protocol for more refined service access, but its immaterial
> functionally.
>
> > In the end, isn't the application granting a privilege the sole
> > arbiter of the validity of a certificate? Maybe, as I said
> > previously, "validity" is the wrong word. A certificate may be
> > perfectly valid in the X.509 sense, but it may not be "valid for a
> > particular purpose."
>
> Of course. certs only perform key distirbution. That key may be
> obtained over such a channel which allows the applciation to assume
> the properties are suitable for a given use. In practice such
> properties come down to a policy oid, which the app can select on, and
> know represent an authenicated channel of authoitative keying.
> Subscriber agreement during certiifcate management then allows
> consumers to decide whether the policies are suitable for use in
> support of purpose A or B, or none. The cert is itself immaterial;
> what matters is its background management procedures embodied in the
> policy id.
I would argue that some (many?) decisions are going to be made
out-of-band, without the aid of policy ids. If you want to put more
information in a certificate so that an application has more
information on which to base a decision, great, but applications need
not act on any particular information in that certificate.
> > A specific extensions can easily be critical or non-critical in all
> > cases. Being able to say otherwise in the certificate with the
> > criticality flag creates confusion (I think this is similar to your
> > original question). It is a shame that the OID space for extensions
> > can't be divided into critical and non-critical (say, even and odd),
> > creating an atomic bond between the extension and its criticality -- no
> > need for external, possibly ambiguous, rules identifying extensions as
> > critical or not.
>
> We can do this. IETF PKIX creates a pkix oid in the internet space,
> and has two subtrees. Into one or the other it reassigns the numbers
> of the ISO oids, and all IETF people use the IANA versions. Its only a
> number, but with pkix-profiled criticality specialization suggested by
> TIS. This is exactly how IETF needs to add value to the raw ISO work,
> to make it practicable.
Sounds good to me. Would be nice if such basic changes could be
folded back into the ISO standard so that there would be fewer
differences between pure ISO and the IETF defined use.
Mark
------- =_aaaaaaaaaa0
Content-Type: application/moss-signature
Content-ID: <2713.832359691.1@tis.com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID: PK,MHcwCgYEVQgBAQICAwADaQAwZgJhAKJzafITUAG5mJfm5I2TPHzYFvzW=
X6VjoFu6n3IWeFdIkw6F1mcJuGrMiASE26EbgO47WImp4CJiRiocwoPb5upi9G2znfUvgigvXD=
IG08D6t6NC5gmWJ7Pvfm00PZx8YQIBAw=3D=3D,EN,1,feldman@tis.com
MIC-Info: RSA-MD5,RSA,fCQzOrOWpNyIAnfTRi5ywnq2t6xk/ki27Kb7qmCg2jHbWfQvaWNE=
6UEV0QkEDNPQIQyOm6uO0mpSbteg/PQjz2N6bbqPbTrc+FPvUJVY/9i5ssumIfoPkD+n/IUX66=
JG
------- =_aaaaaaaaaa0--
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08274;
20 May 96 5:18 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08269;
20 May 96 5:18 EDT
Received: from mustang.via.net by CNRI.Reston.VA.US id aa03924;
20 May 96 5:18 EDT
Received: from Pbagnslr (pm1-10.vannuys.netvoyage.net [205.163.99.20]) by mustang.via.net (8.6.9/8.6.9) with SMTP id CAA01015; Mon, 20 May 1996 02:02:40 -0700
Message-Id: <199605200902.CAA01015@mustang.via.net>
Comments: Authenticated sender is
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Capital Surplus
To: ltrbox@mustang.via.net
Date: Sat, 18 May 1996 19:40:14 +0000
Subject: Free Merchandise Bulletin
Reply-to: ltrbox@via.net
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.10)
Our research of member interests and your directory referred us to
you. We believe that you will be interested in information on how
to receive FREE Merchandise and Cash. If we are mistaken and you
are not interested in any Free Business Information, then simply
hit REPLY and type the word REMOVE in the subject area to be
automatically removed from our lists. Our technology will remove
your name and you will not be contacted again, and we apologize
profusely for any inconvenience.
..................................................................
Initially, we want you to know that we are actively involved in
the merchandise & cash business on a full time basis. Every day
our office phones ring off the wall, our fax machine hums and
companies beg us to take merchandise from them that we can keep
and use for profit.
And we frequently are asked to advise newcomers and professionals
alike on new and innovative techniques for making more money and
receiving more merchandise.
Unlike those who would pretend to insult you and tell you that
they are providing this information to you because it is time to
"Give something back" we will tell you the truth. Just like you,
we want to make more money. We have powerful and exciting
information that is as good as hard cash and by revealing the
secret techniques that we have developed we can make even more
money. We are not concerned that by telling you we will cut
ourselves out. There is a mega amount of money and merchandise
available that will never dry up!
These secret techniques have been developed and can now be
revealed to you showing you how you can select the category of
merchandise you want. Then, by using the special sources that
we give you- anyone can access all the merchandise imaginable
in a matter of a few minutes!!!!
That's right.....spend less than 5 minutes and get FREE
ELECTRONICS, CLOTHES, CAMERAS and SUPPLIES, COMPUTERS, FOOD
- you name it.
You simply pick the category that you and your family desire.
Then you use the secret sources...
Spend a few minutes of time and zappo--you're done for the day.
Then sit back and wait for the delivery man to bring the cases
of merchandise to your door.
(By the way-you can select as many categories as you wish!!!!)
NOW...get ready for the CASH.
By following our special methods you can make $2,000.00 a week
or more expending less than 8 hours of time.
And as a built in bonus....you can;
KEEP ALL THE MERCHANDISE! (that's right...you can keep it &
that's not all.)
It gets even better. You will learn in a matter of minutes how to
pocket several hundred dollars more every week in cold hard
cash..........and all of this extra "pocket money" just keeps on
coming week after week after week.
What does all of this take to put into action?
Just imagine this.......You can officially--
Stay at home.
Start applying our secret techniques 5 minutes after you get
the booklet.
Start making a list of who is sending FREE merchandise to you
immediately.
Decide how much extra cash you want.
Apply our special cash techniques and start to make plans for
the use of this money.
How does this work?
Let's say the category of merchandise that you want is children's
clothes. Every time you go to the store to buy your son or
daughter a pair of tennis shoes and some jeans your checking
account has an average $75.00 sucked out of it and you get one
pair of footwear and one pair of jeans. And maybe you want a new
camera bag, so you trot down to the local discount outlet and hand
over $50.00 for a new one. And on the way home you stop at the
grocery store, buy your favorite soft drink, some canned goods
and oh yes, remember the shampoo, hair spray and little Susie
needs a new hairbrush. So you pull out the ATM card and hand
over another $25.00 dollars to the smiling cashier who will enjoy
your hard earned cash. After all, you didn't want it...You
want to pay retail don't you? Better yet, you want to pay for
everything you need right?
On the way home Tommy tells you his puppy needs some dog food and
a new leash. So you stop at the pet supply store and out comes
the last $20.00.
Oh well, you really didn't want to go to a movie this weekend did you?
Well, that's all over now. With out booklet you can have
everything you just bought and still have ALL THE CASH IN YOUR
POCKET and BANK ACCOUNT!!
You can:
SAVE IT
INVEST IT
SPEND IT
OR JUST WATCH IT PILE UP ON THE TABLE AND IN THE BANK
--IT'S UP TO YOU.
THERE IS ONE CATCH THOUGH. THE TECHNIQUES IN THIS BOOKLET WILL
SOON BE AVAILABLE ONLY BY BUYING OUR COMPLETE MANUAL, THE COST
OF WHICH WILL BE AT LEAST $39.95 or BY ORDERING THE $99. GLOSSY
VERSION . Our intent is to increase our share of the market.
Whichever form of reading and business reference material is
best for you is the one to buy. The information in the current
offering is for the person who is ready to work and
doesn't need lots of bells and whistles. It's up to you.
And, if you want one of the more expensive versions it is still
quite a bargain. We know of other companies that charge hundreds
of dollars just to be part of their team. And they will never
provide the level of support and help you to succeed like we will.
Just listen to what one of of our associates recently wrote:
"Capital Surplus is a company based on honesty and integrity.
They are supportive in their dealing with their associates
and their customers...a valuable service...for which you
will get paid." Dan D. Tenn (original on file)
And there's more. At the end of this information look for even
more proof from another associate of just how powerful these
techniques are!
This is not a get rich quick scheme or MLM. It is the excess
merchandise business.
It is a real and honest opportunity to work and achieve
substantial success, part time using the booklet, or full time
...and you can do it with us or using the techniques, you can
easily do it on your own and make even greater profits.
We are printing a finite number of booklets to help you get
started right away for less than the cost of a movie date.
And this booklet will give you valuable information in an easy
to understand format-that you can apply immediately. The main
difference is that it is not as glossy, graphics filled and
frankly pretty as out fancy national versions will be. It is a
down to earth guide on how to get started RIGHT NOW!
Our goal is to build a broker network of independent people,
like yourselves to help us find even more merchandise. There is
virtually an endless supply. By reading the booklet you will
have the option of using our resources and abilities to help you,
or you can apply the knowledge we will provide and do it on your
own. The market is immense and we are not concerned about the
competition. In fact, some of our best friends are competitors.
If you want to get all the free stuff and cash - we can send you
a copy for $12.95.. This is the only time we will contact you
about this. It's not hard to see that you could start saving
hundreds or thousands of dollars right away and the profits and
cash are a nice addition to any income. (We know some people
who make a small fortune doing this part time.)
If you want one of these once in a lifetime copies - Send
$12.95 +2.00 S/H to
CAPITAL SURPLUS
1125 N. LINDERO CANYON RD
SUITE A8-241
WESTLAKE VILLAGE, CA 91362
International Orders -Please add $2.00 - thank you
All orders received within 7 days will be shipped immediately.
PLUS: The first 20 orders will receive FREE PERSONAL
BUSINESS CONSULTATION by E-mail for a FULL WEEK! !
Any orders received after the supply runs out will be
returned uncashed.
Thank you
Capital Surplus
GUARANTEE- WE want you to know that we back up everything we
say 100%. If you order the booklet and for any reason it is
not what we say it is, send it back within 30 days. We will
immediately issue a FULL REFUND - no questions asked.
P.S. For even more proof, here's an exact reprint of another
letter from one of our associates. (The original is on file
in our offices.)
*************************************************************
"I just wanted to take this opporunity to say what a refreshing
experience it has been for me to work with your company. I've
been involved in several businesses, and I can honestly say
that it is rare to find a company as responsive as yours.
I'm still new to this business, but am always treated with great
respect by everyone there. As I learn the ropes, I've counted
on you for guidance and have never been made to feel that any of
my questions were "stupid" ones, although I'm sure many of them
are very basic.
Your written materials are very informative, and they certainly
reflect reality! I've made lots of contacts in only a few weeks
just by following the instructions in your book. On one day I
found 1,000 cases of Snapple and some table lamps. My last
conversation was almost an "instant replay" of the sample script
you provided. i've now got lots of prospects for future deals.
As I told you, this business is really almost addictive. I love
the flexibility and the fact that I'm working with such a
dedicated team. It's great to be a name and not a number, and to
know that your staff members are working as hard as they can to
make every deal a reality! It's wonderful to know that if I ask
a question, I'll get an answer, and a quick one, too! You've
really made me feel like part of the team!
I'm so glad I answered your ad! My husband and kids are excited
too. They all know who the people at Capital Surplus are by name.
I'm looking forward to a rewarding and prosperous relationship
with your company.
Best wishes,
C.M. -- Conn."
*****************************************************************
Now it's up to you....
You can start receiving all the free merchandise and cash you ever
wanted in a matter of days. Simply send your order for $12.95 plus
$2.00 S/H (int'l add $2.) and we will SHIP YOUR COPY WITHIN 24 HRS
of receiving your order.
Thank you for your interest and we look forward to welcoming you!
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16549;
20 May 96 11:46 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16545;
20 May 96 11:46 EDT
Received: from norn.mailbase.ac.uk by CNRI.Reston.VA.US id aa08716;
20 May 96 11:46 EDT
Received: by norn.mailbase.ac.uk id
(8.6.12/ for mailbase.ac.uk); Mon, 20 May 1996 13:33:04 +0100
Received: from cheviot.ncl.ac.uk by norn.mailbase.ac.uk id
(8.6.12/ for mailbase.ac.uk) with ESMTP; Mon, 20 May 1996 12:36:18 +0100
Received: from gull.ncl.ac.uk by cheviot.ncl.ac.uk id
(8.6.12/ for ncl.ac.uk) with SMTP; Mon, 20 May 1996 12:36:18 +0100
Received: (ndrh4@localhost) by gull.ncl.ac.uk (8.6.12/8.6.x-cf revision 3 for Solaris 2.x) id MAA00474; Mon, 20 May 1996 12:33:45 +0100
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Donal Hanna
Message-Id: <199605201133.MAA00474@gull.ncl.ac.uk>
Subject: IETF Report Abstract
To: web-support@mailbase.ac.uk, lis-elib@mailbase.ac.uk,
lis-link@mailbase.ac.uk, nir@mailbase.ac.uk
Date: Mon, 20 May 1996 12:33:45 +0100 (BST)
Organisation: Netskills
Address: University Computing Service, University of Newcastle upon Tyne,
Newcastle upon Tyne NE1 7RU U.K.
Phone: +44 191 222 5003 Fax: +44 191 222 5001
URL: http://www.netskills.ac.uk/
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1063
X-List: nir@mailbase.ac.uk
X-Unsub: To leave, send text 'leave nir'
to mailbase@mailbase.ac.uk
Reply-To: Donal Hanna
X-Orig-Sender: nir-request@mailbase.ac.uk
Precedence: list
Apologies if you receive more than one copy of this message.
IETF - Los Angeles: March 4th - 8th 1996
Trip Report:
Donal Hanna - Newcastle University
Netskills Programmer
Jill Foster - Newcastle University
Mailbase Director
Netskills Director
Abstract:
The IETF (Internet Engineering Task Force) met for a week in L.A. in
March. A wide range of working group sessions which took place are
covered in the report, including:
HyperText Markup Language
Applications/Transport Joint Session BOF
User Services Working Group
Applications Area Open Meeting
Multiparty Multimedia Session Control WG
HTTP Working Group
IPNG Transition
Integrated Directory Services
Network Training Materials
Access, Searching and Indexing of Directories WG
Technical Session
The report is available from:
http://www.netskills.ac.uk/staff/hanna/confs/IETF-Mar96.html
--
Donal Hanna, Netskills Programmer, University Computing Service,
Newcastle University, Newcastle upon Tyne, UK, NE1 7RU
Tel: +44 191 222 5003 URL: http://www.netskills.ac.uk/
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25857;
20 May 96 17:05 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25853;
20 May 96 17:05 EDT
Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa13403;
20 May 96 17:05 EDT
Received: by mx2.cac.washington.edu
(5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA04146;
Mon, 20 May 96 13:17:32 -0700
Errors-To: owner-imap@cac.washington.edu
X-Orig-Sender: owner-imap@cac.washington.edu
Received: from eamail1.unisys.com by mx2.cac.washington.edu
(5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA04139;
Mon, 20 May 96 13:17:29 -0700
Received: from mvdns1.mv.unisys.com (mvdns1.mv.unisys.com [192.59.253.100]) by eamail1.unisys.com (8.7.3/8.6.12) with SMTP id UAA25102; Mon, 20 May 1996 20:17:31 GMT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: RANDY@mpa15ab.mv.unisys.com
Received: from eamail1.unisys.com by mvdns1.mv.unisys.com (4.1/SMI-4.1-1.8)
id AB27931; Mon, 20 May 96 20:28:25 GMT
Date: 20 MAY 96 13:16
To: imap%cac.washington.edu@mvdns1.mv.unisys.com,
treister%Beadle.Stanford.EDU@mvdns1.mv.unisys.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: Handling large attachments
In-Reply-To: Your message of "20 May 96 10:37:47 -0700"
References:
Message-Id:
On 20 May 96 10:37:47 -0700, Adam Treister wrote:
> Is there any mechanism to forward or reply to messages with
> attachments without downloading the data just to munge them into a new
> wrapper and send them back up the wire?
>
> I can see 2 possible solutions:
>
> 1) A server-based "delegate agent" that can be invoked from the remote
> client which opens the mailbox extracts the desired pieces and sends
> off the new message.
>
> 2) A "Save Part As" function on the server that will write the
> requested attachment to some accessible space, so that the MUA can
> send off the reply / forward as a MIME external part aot the
> attachment itself. This has some security issues, and the part may
> need to be encrypted in the process, but it does seem to be the most
>
> Anyone else have a solution that can be implemented within the
> existing protocol and doesn't require needless download to the client.
I don't think this can be done using the existing protocol. Personally,
I would be very interested in a way to extend the IMAP/IMSP model to
allow a client to access files on the server. Not only for replying to
mail without the need to ship the data to the client and back, but also
to allow arbitrary server files to be attached to outbound messages, and
so incoming messages (or their attachments) could be saved as server files.
This could be done with FTP, but it would still require shipping the
data round-trip.
The problem, as I see it, is how such functionality could be gotten
without bloating the protocol or extending it where people don't want it
to go. Since IMSP is for configuration information, IMAP is for
message access, and SMTP is for message submission, there isn't any
cross-over (except in a client that understands them all).
Perhaps if IMAP had a "save as" ability to extract a message or body
part into a server file (assuming the user was authorized to do this),
and the CHUNKING extension to SMTP was itself extended to allow a chunk
to be specified as a server file, it could all be done. The client
would issue an IMAP command to save parts of messages in server files,
then compose a reply, and send the data in chunks. One or more of the
chunks would be references to the previously-saved server files. I
imagine that this would require the authentication extension to SMTP as
well, so the server could know if the user was permitted to access the
requested files.
--
|Randall Gellens | randy@mv.unisys.com|
|(714) 380-6350 | fax (714)597-8053 can add ,,,,,,,,6350|
|Opinions are personal; facts are suspect; I speak only for myself|
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29372;
20 May 96 20:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa29368;
20 May 96 20:01 EDT
Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa15413;
20 May 96 20:01 EDT
Received: by mx1.cac.washington.edu
(5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA24494;
Mon, 20 May 96 16:17:31 -0700
Errors-To: owner-imap@cac.washington.edu
X-Orig-Sender: owner-imap@cac.washington.edu
Received: from eamail1.unisys.com by mx1.cac.washington.edu
(5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA24488;
Mon, 20 May 96 16:17:30 -0700
Received: from mvdns1.mv.unisys.com (mvdns1.mv.unisys.com [192.59.253.100]) by eamail1.unisys.com (8.7.3/8.6.12) with SMTP id XAA05987; Mon, 20 May 1996 23:17:25 GMT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: RANDY@mpa15ab.mv.unisys.com
Received: from MPA15AB.MV.UNISYS.COM by mvdns1.mv.unisys.com (4.1/SMI-4.1-1.8)
id AA29420; Mon, 20 May 96 23:28:17 GMT
Date: 20 MAY 96 16:16
To: chrisn+%CMU.EDU@mvdns1.mv.unisys.com,
imap%cac.washington.edu@mvdns1.mv.unisys.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: Handling large attachments
In-Reply-To: Your message of "20 May 1996 18:23:49 -0400"
References: <832631029.19231.0@nifty.andrew.cmu.edu>,
Message-Id:
On 20 May 1996 18:23:49 -0400, Chris Newman wrote:
> I strongly oppose bloating IMAP, IMSP/ACAP or kludging SMTP CHUNKING
> to support this.
>
> If you really want to do this, here's what I'd suggest:
>
> Design an authenticated, clean, MIME-aware mail submission protocol
> which supports references to IMAP stores (server, folder, uid,
> mime-part). Whether the mail submission server gets the parts via
> IMAP proxy or pulling them directly out of the IMAP mailstore would be
> an implementation detail.
This is a nice idea. I wonder how much interest there would be for it?
It doesn't handle attaching arbitrary server files or saving attachments
as server files, but it would handle the essential business of forwarding
and so on.
--
|Randall Gellens | randy@mv.unisys.com|
|(714) 380-6350 | fax (714)597-8053 can add ,,,,,,,,6350|
|Mail Stop MV 237 | Net**2 656-6350|
|Opinions are personal; facts are suspect; I speak only for myself|
Randomly selected tag:
"If I had my life to live over, I'd live over a delicatessen."
-- Unknown
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27821;
21 May 96 15:57 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27817;
21 May 96 15:57 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa17701;
21 May 96 15:57 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id ; Tue, 21 May 1996 16:19:24 +0100
Received: from atc.boeing.com by bells.cs.ucl.ac.uk with Internet SMTP
id ; Tue, 21 May 1996 16:19:05 +0100
Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA07308;
Tue, 21 May 1996 08:16:16 -0700
Received: by xch-g6000-02.rt.cs.boeing.com
with Microsoft Exchange (IMC 4.0.838.14)
id <01BB46EE.127B4590@xch-g6000-02.rt.cs.boeing.com>;
Tue, 21 May 1996 08:18:20 -0700
Message-Id:
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Lukasik, Victor J"
To: 'OSI-DS'
Subject: Job Posting Assistance
Date: Tue, 21 May 1996 08:18:19 -0700
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14
Encoding: 84 TEXT
I have a full time permanent job opening here in Seattle Washington, USA
at Boeing for a Directory Services focal. Attached are descriptions of
the Directory opening and a EDI opening. Kindly respond with interest,
pointers to places to post these openings, or requests for more
information directly to me at vlukasik@atc.boeing.com. Do not simply
reply to the list. Fee agencies need not reply. Individuals only.
Apologies if this is not a appropriate list to post such requests.
Thanks
Vic Lukasik
Communications Technology
Boeing
Directory Services Job Description
The position is to provide technical leadership to the Boeing company
for Directory Services. Assess, evaluate, and develop new and advanced
technology solutions capitalizing on Directory services to support
Boeing business requirements. Support strategic planning and deployment
of company wide Directory Services. Consult with users developing
Cost/benefit analyses. Evaluate and integrate vendor offerings with
existing company business systems. Develop and publish a company wide
Directory Services deployment and email system integration strategy.
Develop and deliver seminars, training, and white papers on subjects
like telecommunications networks, computer software, harmonization of
business practices, standardization of business data.
Skills required
Advanced degree in Computer Science or business
Expertise and a working knowledge of X.500, and directory related IETF
protocols
10 years Directory system design, analysis, and network management
experience
Self motivated, able to work independently, strong interpersonal
communications and leadership skills. Able to communicate plans,
vision, and scenarios.
Willingness to explore and master new technologies
Able to continually redefine personal technical and analytical skills in
light of new technologies
Able to understand customer requirements and translate into technical
plans
Strong grasp of OSI model and network models
>
Electronic Data Interchange (EDI) Specialist Job Description
The position is to provide technical leadership to the Boeing company
for Electronic Data Interchange. Assess, evaluate, and develop new and
advanced technology solutions capitalizing on Electronic Data
Interchange to support electronic commerce and form electronic trading
communities per Boeing business requirements. Consult with users
developing cost/benefit analyses. Evaluate and integrate vendor
offerings with existing company business systems. Develop and publish a
EDI deployment strategy. Develop and deliver seminars, training, and
white papers on subjects like telecommunications networks, computer
software, harmonization of business practices, standardization of
business data. Validate and demonstrate new solutions. Transfer this
technology to the Boeing user community.
Skills required
Advanced degree in Computer Science or business
Expertise and a working knowledge of UN/ EDIFACT and X12 transactions
Email systems, Worldwide Internet usage and implications
10 years EDI system design, analysis, and network management experience
Self motivated, able to work independently, strong interpersonal
communications and leadership skills. Able to communicate plans,
vision, and scenarios.
Willingness to explore and master new technologies
Able to continually redefine personal technical and analytical skills in
light of new technologies
Able to understand customer requirements and translate into technical
plans
Strong grasp of OSI model and network models
>
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11302;
21 May 96 23:01 EDT
Received: from beer.pilsnet.sunet.se by CNRI.Reston.VA.US id aa23296;
21 May 96 23:01 EDT
Received: from localhost by beer.pilsnet.sunet.se (8.6.8/2.03)
id FAA29585; Wed, 22 May 1996 05:01:14 +0200
Date: Wed, 22 May 1996 05:01:14 +0200
From: Mail Delivery Subsystem
Subject: Returned mail: User unknown
Message-ID: <199605220301.FAA29585@beer.pilsnet.sunet.se>
To: ietfadm@CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
The original message was received at Wed, 22 May 1996 05:00:32 +0200
from ietf.cnri.reston.va.us [132.151.1.35]
----- The following addresses had delivery problems -----
(unrecoverable error)
----- Transcript of session follows -----
... while talking to sunic.sunet.se.:
>>> RCPT To:
<<< 550 ... User unknown
550 ... User unknown
----- Original message follows -----
Received: from IETF.cnri.reston.VA.US by beer.pilsnet.sunet.se (8.6.8/2.03)
id FAA29583; Wed, 22 May 1996 05:00:32 +0200
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11232;
21 May 96 22:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23234;
21 May 96 22:56 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11227;
21 May 96 22:55 EDT
To: shadow-dirs@CNRI.Reston.VA.US
Subject: shadow directories
Date: Tue, 21 May 96 22:55:57 -0400
From: IETF Administrative User
Message-ID: <9605212255.aa11227@IETF.CNRI.Reston.VA.US>
The following files have been added:
/ftp/ietf/96jun/nasreqng-agenda-96jun.txt
/ftp/ietf/ion/ion-charter.txt
/ftp/internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-04.txt
/ftp/internet-drafts/draft-manning-ip4.int-roe-00.txt
/ftp/internet-drafts/draft-rfced-info-chu-00.txt
/ftp/internet-drafts/draft-suzuki-stfs-ctrl-load-svc-00.txt
The following files have changed:
/ftp/ietf/1rfc_index.txt
/ftp/ietf/1wg-charters-by-acronym.txt
/ftp/ietf/1wg-charters.txt
/ftp/ietf/1wg-summary-by-acronym.txt
/ftp/ietf/1wg-summary.txt
/ftp/ietf/asid/asid-charter.txt
/ftp/ietf/drums/drums-charter.txt
/ftp/ietf/rmonmib/rmonmib-charter.txt
/ftp/internet-drafts/1id-abstracts.txt
/ftp/internet-drafts/1id-index.txt
/ftp/internet-drafts/draft-andrews-dns-ascii-01.txt
/ftp/internet-drafts/draft-bierman-rmon-atmrmon-01.txt
/ftp/internet-drafts/draft-ietf-asid-mime-vcard-00.txt
/ftp/internet-drafts/draft-ietf-drums-smtpupd-02.txt
/ftp/internet-drafts/draft-ietf-idmr-pim-sm-spec-02.txt
/ftp/internet-drafts/draft-ietf-rmonmib-rmonprot-02.txt
/ftp/iesg/1old_standards.txt
/ftp/iesg/1protocol_actions.txt
/ftp/iesg/1rfc_index.txt
/ftp/iesg/1wg_actions.txt
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23885;
22 May 96 14:36 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23881;
22 May 96 14:36 EDT
Received: from mail1.digital.com by CNRI.Reston.VA.US id aa01904;
22 May 96 14:36 EDT
Received: from nsl.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
id AA13915; Wed, 22 May 1996 11:24:53 -0700
Received: by nsl.pa.dec.com; id AA04490; Wed, 22 May 96 09:44:20 -0700
Received: by nsl.pa.dec.com; id AA04486; Wed, 22 May 96 09:44:00 -0700
Received: by pobox1.pa.dec.com; id AA11186; Wed, 22 May 96 09:43:43 -0700
Received: from crux.comverse.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
id AA24239; Wed, 22 May 1996 09:38:33 -0700
Received: from hub.comverse.com ([204.240.7.8]) by comverse.com (5.x/SMI-SVR4)
id AA04359; Wed, 22 May 1996 12:27:03 -0400
Received: from ccMail by hub.comverse.com (SMTPLINK V2.10.08)
id AA832793652; Wed, 22 May 96 12:49:59 EST
Date: Wed, 22 May 96 12:49:59 EST
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: rachel_haikis-cohen@comverse.com
Encoding: 8 Text
Message-Id: <9604228327.AA832793652@hub.comverse.com>
To: char-mib@decwrl.dec.com
Subject: Help: mib 1
Hi,
I need a help and an advice where
I can find an example of MIB1 file.
Thanks
Rachel Cohen
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05445;
22 May 96 22:11 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05437;
22 May 96 22:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08222;
22 May 96 22:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05430;
22 May 96 22:11 EDT
Received: from [206.88.22.114] by IETF.CNRI.Reston.VA.US id aa05422;
22 May 96 22:10 EDT
Received: from mail.pwrnet.com (pwrnet.com [206.88.22.54]) by unix.pwrnet.com (8.6.12/8.6.12) with ESMTP id QAA19874; Fri, 4 May 1928 16:47:13 -0600
Received: by mail.pwrnet.com from localhost
(router,SLmail95 V1.2,beta 1); Wed, 22 May 1996 21:02:45
Received: by mail.pwrnet.com from localhost.pwrnet.com
(206.88.8.23::mail daemon; unverified,SLmail95 V1.2,beta 1); Wed, 22 May 1996 21:02:42
Message-ID: <31A3C695.6E1A@pwrnet.com>
Date: Wed, 22 May 1996 20:59:49 -0500
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: qbert
X-Mailer: Mozilla 2.01 (Win95; I)
MIME-Version: 1.0
To: qbert
Subject: Internet Opportunities
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Internet User:
If you wish to be removed from this mailing list please reply "remove".
Hi, I would like to tell you about a new program by which you can make
long term residual income using the internet. One program involves a
long distance carrier and the other involves a internet service
provider. These are not get rich quick schemes, they will take some
effort and work on your part. The long distance carrier opportunity
involves no startup costs and the internet service provider involves a
small one time start up fee (less than $30).
The long distance carrier offers 12.9 cents a minute long distance 24
hours a day and the internet service provider offers unlimited monthly
access for $19.96 a month. Both plans will pay you commissions based on
the people that you sign up and their usage of such services.
If you would like more information on either of these exiciting
oppotunities, please reply and request information on either the long
distance plan, the internet plan, or both.
I look forward to hearing from you.
Aaron Jackson
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21758;
23 May 96 11:19 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21754;
23 May 96 11:19 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa09643;
23 May 96 11:19 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 23 May 1996 08:05:19 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 23 May 1996 08:05:17 -0700
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 23 May 1996 08:05:14 -0700
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.249.124])
id QQaqym04471; Thu, 23 May 1996 11:05:10 -0400 (EDT)
Message-Id:
To: kasten@ftp.com
Cc: rreq@isi.edu
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Louis A. Mamakos"
Subject: Re: musings
References: <9605231347.AA08987@MAILSERV-D.FTP.COM>
In-Reply-To: Your message of "Thu, 23 May 1996 09:47:13 EDT."
<9605231347.AA08987@MAILSERV-D.FTP.COM>
Date: Thu, 23 May 1996 11:05:10 -0400
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
> Date: Thu, 23 May 1996 09:47:13 EDT
> To: rreq@ISI.EDU
> Reply-To: kasten@ftp.com
> From: kasten@ftp.com (Frank Kastenholz)
> Subject: Re: musings
>
> stev writes...
>
> > >So, my personal recommendation would be to back off from your
> > >(laudable) desire for demonstrated interoperability for
> > >rreq, and GET ON WITH IT.
> >
> >
> > it is not clear to me that, based on the current rules, he *can* get on with
> it.
> >
> > at some point, as i understand them, the standardization rules require the
> > document to be revised to remove everything that has not been implemented in
> > *one* implementation. this does not mean *any* implementation. one was
> > required to hopefully catch any race conditions . . . . .
>
> RFC1871 -- the variance procedure -- may apply.
>
> there is also the historical precedent of ntp -- all ntp seems to be derived
> from dave mills' original code...
This is incorrect.
Mills' original code was written in PDP-11 assemby code for the
Fuzzball platform.
At the time that the original NTP protocol spec was being written
down, Mike Petry and myself , then both at the University of Maryland,
did a reference implementation based on specification. This was as
much a validation of the protocol, as well as the veracity of the
protocol specification written on paper. It was a very interesting
process and we worked closely with Mills in clarifing the written spec
when implementation questions arose. There were quite a few drafts
which were produced at the time.
The implementation that we did was a "reference implementation" built
for "comfort, not speed". It did function, however, quite well, and
is the basis for code being shipped by some commercial vendors, DEC
Ultrix and NeXT come to mind.
Sometime after, Dennis Ferguson, then of the University of Toronto
undertook his own NTP implementation ("XNTP"), targeted to NTPv2 with
a somewhat different implementation approach. It's decendents are now
the implementation of choice for UNIX platforms.
There is a quite complete implementation of NTP in Cisco routers,
which I think may be based on Ferguson's version, but I'm not sure.
We had multiple interoperable implementions which worked quite well.
In fact, the dominant implementation which was deployed in far greater
numbers was either the version that Petry and myself did or later, the
Ferguson version; the Mills implementation didn't get quite so
extensive deployment because of the unique platform which it ran on.
While the process wasn't followed because it didn't exist at the time,
the spirit of it was because that's what made the IETF standards
process work.
(Oh, and the NTP RFC is one which really makes good use of PostScript.
It makes reading the math in it much easier on the eyeballs. But I
digress..)
Louis A. Mamakos, Manager, Strategic Technologies louie@uu.net, uunet!louie
UUNET Technologies, Inc. Voice: +1 703 206 5823
3060 Williams Drive Fax: +1 703 208 5390
Fairfax, VA 22031
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01890;
23 May 96 16:43 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01886;
23 May 96 16:43 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15285;
23 May 96 16:43 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 23 May 1996 13:10:32 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id ; Thu, 23 May 1996 13:10:27 -0700
Received: from puli.cisco.com by venera.isi.edu (5.65c/5.61+local-23)
id ; Thu, 23 May 1996 13:10:18 -0700
Received: (dkatz@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id NAA16136; Thu, 23 May 1996 13:10:16 -0700
Date: Thu, 23 May 1996 13:10:16 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Katz
Message-Id: <199605232010.NAA16136@puli.cisco.com>
To: louie@uu.net
Cc: kasten@ftp.com, rreq@isi.edu
In-Reply-To: "Louis A. Mamakos"'s message of Thu, 23 May 1996 11:05:10 -0400
Subject: musings
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk
The cisco version is primarily a port of xntpd (with some creative florishes
due to a different local clock architecture).
Of course, pretty much everybody (including Dr. Mills) has had their hands
on xntpd, so it's hard to really trace the lineage any longer. But I
think the claim could be made (without *too* much of a stretch) that
in fact three independent, interoperable implementations do exist.
From: "Louis A. Mamakos"
References: <9605231347.AA08987@MAILSERV-D.FTP.COM>
Date: Thu, 23 May 1996 11:05:10 -0400
Sender: owner-rreq@ISI.EDU
Precedence: bulk
> Date: Thu, 23 May 1996 09:47:13 EDT
> To: rreq@ISI.EDU
> Reply-To: kasten@ftp.com
> From: kasten@ftp.com (Frank Kastenholz)
> Subject: Re: musings
>
> stev writes...
>
> > >So, my personal recommendation would be to back off from your
> > >(laudable) desire for demonstrated interoperability for
> > >rreq, and GET ON WITH IT.
> >
> >
> > it is not clear to me that, based on the current rules, he *can* get on with
> it.
> >
> > at some point, as i understand them, the standardization rules require the
> > document to be revised to remove everything that has not been implemented in
> > *one* implementation. this does not mean *any* implementation. one was
> > required to hopefully catch any race conditions . . . . .
>
> RFC1871 -- the variance procedure -- may apply.
>
> there is also the historical precedent of ntp -- all ntp seems to be derived
> from dave mills' original code...
This is incorrect.
Mills' original code was written in PDP-11 assemby code for the
Fuzzball platform.
At the time that the original NTP protocol spec was being written
down, Mike Petry and myself , then both at the University of Maryland,
did a reference implementation based on specification. This was as
much a validation of the protocol, as well as the veracity of the
protocol specification written on paper. It was a very interesting
process and we worked closely with Mills in clarifing the written spec
when implementation questions arose. There were quite a few drafts
which were produced at the time.
The implementation that we did was a "reference implementation" built
for "comfort, not speed". It did function, however, quite well, and
is the basis for code being shipped by some commercial vendors, DEC
Ultrix and NeXT come to mind.
Sometime after, Dennis Ferguson, then of the University of Toronto
undertook his own NTP implementation ("XNTP"), targeted to NTPv2 with
a somewhat different implementation approach. It's decendents are now
the implementation of choice for UNIX platforms.
There is a quite complete implementation of NTP in Cisco routers,
which I think may be based on Ferguson's version, but I'm not sure.
We had multiple interoperable implementions which worked quite well.
In fact, the dominant implementation which was deployed in far greater
numbers was either the version that Petry and myself did or later, the
Ferguson version; the Mills implementation didn't get quite so
extensive deployment because of the unique platform which it ran on.
While the process wasn't followed because it didn't exist at the time,
the spirit of it was because that's what made the IETF standards
process work.
(Oh, and the NTP RFC is one which really makes good use of PostScript.
It makes reading the math in it much easier on the eyeballs. But I
digress..)
Louis A. Mamakos, Manager, Strategic Technologies louie@uu.net, uunet!louie
UUNET Technologies, Inc. Voice: +1 703 206 5823
3060 Williams Drive Fax: +1 703 208 5390
Fairfax, VA 22031
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05906;
24 May 96 18:16 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05902;
24 May 96 18:16 EDT
Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa15006;
24 May 96 18:16 EDT
Received: by mx2.cac.washington.edu
(5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA25097;
Fri, 24 May 96 14:41:38 -0700
Errors-To: owner-imap@cac.washington.edu
X-Orig-Sender: owner-imap@cac.washington.edu
Received: from eamail1.unisys.com by mx2.cac.washington.edu
(5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA25091;
Fri, 24 May 96 14:41:36 -0700
Received: from mvdns1.mv.unisys.com (mvdns1.mv.unisys.com [192.59.253.100]) by eamail1.unisys.com (8.7.3/8.6.12) with SMTP id VAA06199; Fri, 24 May 1996 21:41:52 GMT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: RANDY@mpa15ab.mv.unisys.com
Received: from MPA15AB.MV.UNISYS.COM by mvdns1.mv.unisys.com (4.1/SMI-4.1-1.8)
id AA25350; Fri, 24 May 96 21:52:42 GMT
Date: 24 MAY 96 14:40
To: imap%CAC.WASHINGTON.EDU@mvdns1.mv.unisys.com,
treister%BEADLE.STANFORD.EDU@mvdns1.mv.unisys.com,
larryo%EXCHANGE.MICROSOFT.COM@mvdns1.mv.unisys.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: RE: Internationalization of IMAP servers/clients
In-Reply-To: Your message of "24 May 1996 13:25:54 -0700"
References:
On 24 May 1996 13:25:54 -0700, "Larry Osterman (Exchange)" wrote:
> If we do LANGUAGE NUMERIC, we should also have a CAPABILITY
> ERRORSTRING, which would enable the new ERRORSTRING command....
>
> I sort of see this as two extensions: The first is the basic LANGUAGE
> extension, the second is the ERRORSTRING extension, which relies on
> the LANGUAGE extension.
I like this idea. One minor point: what if (for whatever reason) the
server is unable to produce a specific error text in a requested
language? I'd say the server should be permitted to return it in a
different language, of the server's (or admin's) choice.
--
|Randall Gellens | randy@mv.unisys.com|
|(714) 380-6350 | fax (714)597-8053 can add ,,,,,,,,6350|
|Mail Stop MV 237 | Net**2 656-6350|
|Opinions are personal; facts are suspect; I speak only for myself|
Randomly selected tag:
Television has raised writing to a new low. -- Sam Goldwyn
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05726;
28 May 96 23:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05720;
28 May 96 23:01 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa20014;
28 May 96 23:01 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa16714;
28 May 96 22:51 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa16700; 28 May 96 22:44 EDT
Received: by relay.tis.com; id WAA15540; Tue, 28 May 1996 22:46:15 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma015534; Tue, 28 May 96 22:45:46 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA01987; Tue, 28 May 96 22:45:53 EDT
Received: by relay.tis.com; id WAA15531; Tue, 28 May 1996 22:45:45 -0400
Received: from rosetta.verisign.com(204.162.64.10) by relay.tis.com via smap (V3.1)
id xma015529; Tue, 28 May 96 22:45:40 -0400
Received: from dustin.verisign.com (Gateway-Outside.Verisign.COM [204.162.64.20]) by rosetta.verisign.com (8.7.4/8.6.12) with ESMTP id TAA04240 for ; Tue, 28 May 1996 19:48:15 -0700 (PDT)
Received: from peter (Peter.verisign.com [192.42.157.77]) by dustin.verisign.com (8.7.4/8.6.12) with SMTP id TAA00782 for ; Tue, 28 May 1996 19:47:53 -0700 (PDT)
Message-Id: <31ABADCE.2D26@verisign.com>
Date: Tue, 28 May 1996 18:52:14 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Williams
Reply-To: peter@verisign.com
Organization: VeriSign, Inc
X-Mailer: Mozilla 3.0b3 (Win16; I)
Mime-Version: 1.0
To: pem-dev@tis.com
Subject: directories and certificates and mail
Content-Type: multipart/mixed; boundary="------------5277467D334"
X-Orig-Sender: pem-dev-approval@neptune.tis.com
Precedence: bulk
This is a multi-part message in MIME format.
--------------5277467D334
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The web infrastructure for directories is
coming along fine. As a avergae user
I just bundled my certificate with
a listing provided in the switchboard
directory service.
see the "find user" service at www.switchboard.com.
You too can do the same -
enroll at www.verisign.com, then
list your certificate at www.switchboard.com.
Now, this listing was created without my
permission, though I amended its value.
Would it be unethical for VeriSign
to now place a link to any certificate - issued
to any user who has subscribed to the Class 1 CA service
wevebeen running for a month now - in
their listed entry, without their permission?
(I'm assuming we obtained the permission and
cooperation of Banyan, at least?)
This would bootstrap a rather sizeable
community, and might help deployment of
PEM systems.
Any comments?
Things seem to work, these days...
--------------5277467D334
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-POP3-Rcpt: peter@dustin
Return-Path: peter@verisign.com
Received: from peter (Peter.verisign.com [192.42.157.77]) by dustin.verisign.com (8.7.4/8.6.12) with SMTP id TAA00666 for ; Tue, 28 May 1996 19:32:44 -0700 (PDT)
Message-ID: <31ABAA3E.777B@verisign.com>
Date: Tue, 28 May 1996 18:37:02 -0700
From: Peter Williams
Reply-To: peter@verisign.com
Organization: VeriSign, Inc
X-Mailer: Mozilla 3.0b3 (Win16; I)
MIME-Version: 1.0
To: peter
Subject: Switchboard: More Information
Content-Type: multipart/mixed; boundary="------------7FA275276EC"
This is a multi-part message in MIME format.
--------------7FA275276EC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
http://www2.switchboard.com/bin/cgimore.dll?ID=1647663530
--------------7FA275276EC
Content-Type: text/html; charset=us-ascii; name="cgimore.dll"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="cgimore.dll"
Switchboard: More Information
More Information
Listing details...
More Information About Peter Williams
Williams, Peter...35596 Linda Dr...Fremont, CA 94536-1523
Phone: (510)796-7919
Email: peter@verisign.com
--------------7FA275276EC--
--------------5277467D334--
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07681;
29 May 96 1:42 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07677;
29 May 96 1:42 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa02170; 29 May 96 1:42 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id BAA20175; Wed, 29 May 1996 01:41:53 -0400
Received: from dimacs.rutgers.edu (root@dimacs.rutgers.edu [128.6.75.16]) by list.cren.net (8.6.12/8.6.12) with ESMTP id BAA20100 for ; Wed, 29 May 1996 01:40:34 -0400
Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id BAA02909 for ; Wed, 29 May 1996 01:40:26 -0400
Received: from vista.hevanet.com by relay7.UU.NET with SMTP
(peer crosschecked as: hevanet.com [198.5.254.1])
id QQarte03081; Wed, 29 May 1996 01:39:40 -0400 (EDT)
Received: by vista.hevanet.com (Smail3.1.28.1 #15)
id m0uOdyd-0010bxC; Tue, 28 May 96 22:39 PDT
Message-Id: <4ognub$qu6@vista.hevanet.com>
Date: 29 May 1996 05:39:23 GMT
X-Orig-Sender: owner-ietf-smtp@list.cren.net
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: R D Cameron
To: odin@gladstone.uoregon.edu
Subject: lies
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.22 (Windows; I; 16bit)
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN
this is a test of the emergency broadcast system.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07879;
29 May 96 1:54 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07875;
29 May 96 1:54 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa02295; 29 May 96 1:54 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id BAA20681; Wed, 29 May 1996 01:54:39 -0400
Received: from dimacs.rutgers.edu (root@dimacs.rutgers.edu [128.6.75.16]) by list.cren.net (8.6.12/8.6.12) with ESMTP id BAA20651 for ; Wed, 29 May 1996 01:54:10 -0400
Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id BAA02938 for ; Wed, 29 May 1996 01:54:10 -0400
Received: from vista.hevanet.com by relay4.UU.NET with SMTP
(peer crosschecked as: hevanet.com [198.5.254.1])
id QQartf07054; Wed, 29 May 1996 01:54:11 -0400 (EDT)
Received: by vista.hevanet.com (Smail3.1.28.1 #15)
id m0uOeCm-0010bxC; Tue, 28 May 96 22:54 PDT
Message-Id: <4ogopo$qu6@vista.hevanet.com>
Date: 29 May 1996 05:54:00 GMT
X-Orig-Sender: owner-ietf-smtp@list.cren.net
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: R D Cameron
To: roobn@aol.com
Subject: surprise attack!
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.22 (Windows; I; 16bit)
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN
Destiny Turns on the Radio... and it's playing Jimmy Buffet.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08224;
29 May 96 2:17 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08220;
29 May 96 2:17 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa02538; 29 May 96 2:17 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA21410; Wed, 29 May 1996 02:17:35 -0400
Received: from dimacs.rutgers.edu (root@dimacs.rutgers.edu [128.6.75.16]) by list.cren.net (8.6.12/8.6.12) with ESMTP id CAA21382 for ; Wed, 29 May 1996 02:17:18 -0400
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id CAA04227 for ; Wed, 29 May 1996 02:17:17 -0400
Received: from vista.hevanet.com by relay3.UU.NET with SMTP
(peer crosschecked as: hevanet.com [198.5.254.1])
id QQarth05524; Wed, 29 May 1996 02:16:29 -0400 (EDT)
Received: by vista.hevanet.com (Smail3.1.28.1 #15)
id m0uOeYH-0010XcC; Tue, 28 May 96 23:16 PDT
Message-Id: <4ogq3c$qu6@vista.hevanet.com>
Date: 29 May 1996 06:16:12 GMT
X-Orig-Sender: owner-ietf-smtp@list.cren.net
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ridley D Cameron
To: odin@gladstone.uoregon.edu
Subject: mess with the best and die like the rest
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.22 (Windows; I; 16bit)
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN
Yeah. Crash Override wins again.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08289;
29 May 96 2:25 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08285;
29 May 96 2:25 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa02624; 29 May 96 2:25 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA21663; Wed, 29 May 1996 02:25:51 -0400
Received: from dimacs.rutgers.edu (root@dimacs.rutgers.edu [128.6.75.16]) by list.cren.net (8.6.12/8.6.12) with ESMTP id CAA21642 for ; Wed, 29 May 1996 02:25:33 -0400
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id CAA04242 for ; Wed, 29 May 1996 02:25:32 -0400
Received: from vista.hevanet.com by relay3.UU.NET with SMTP
(peer crosschecked as: hevanet.com [198.5.254.1])
id QQarth05989; Wed, 29 May 1996 02:24:45 -0400 (EDT)
Received: by vista.hevanet.com (Smail3.1.28.1 #15)
id m0uOegH-0010cMC; Tue, 28 May 96 23:24 PDT
Message-Id: <4ogqit$qu6@vista.hevanet.com>
Date: 29 May 1996 06:24:29 GMT
X-Orig-Sender: owner-ietf-smtp@list.cren.net
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ridley D Cameron
To: victoria@hevanet.com
Subject: talking to myself
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.22 (Windows; I; 16bit)
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN
hello.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08456;
29 May 96 2:38 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08452;
29 May 96 2:38 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa02745; 29 May 96 2:38 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA22272; Wed, 29 May 1996 02:38:27 -0400
Received: from dimacs.rutgers.edu (root@dimacs.rutgers.edu [128.6.75.16]) by list.cren.net (8.6.12/8.6.12) with ESMTP id CAA22250 for ; Wed, 29 May 1996 02:38:20 -0400
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id CAA04292 for ; Wed, 29 May 1996 02:38:19 -0400
Received: from vista.hevanet.com by relay3.UU.NET with SMTP
(peer crosschecked as: hevanet.com [198.5.254.1])
id QQarti06994; Wed, 29 May 1996 02:37:33 -0400 (EDT)
Received: by vista.hevanet.com (Smail3.1.28.1 #15)
id m0uOesS-0010cMC; Tue, 28 May 96 23:37 PDT
Message-Id: <4ograf$qu6@vista.hevanet.com>
Date: 29 May 1996 06:37:03 GMT
X-Orig-Sender: owner-ietf-smtp@list.cren.net
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ridley D Cameron
To: an963@rgfn.epcc.edu
Subject: don't believe what you see
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.22 (Windows; I; 16bit)
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN
Ash,
see no fear
speak no evil
are you screaming out to no one
as you fall down a mountain of pride
now take me
now lead me from you
now take me
from the light that's dying in your eyes
photograph me sleeping. You get 10 out of 10 points for style, but
subtract 1,000,000 for good thinking.
sleep comes like a drug.
Good night, doll.
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02571;
29 May 96 17:52 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02567;
29 May 96 17:52 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa16310;
29 May 96 17:52 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa04966;
29 May 96 17:11 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa04949; 29 May 96 17:03 EDT
Received: by relay.tis.com; id RAA10223; Wed, 29 May 1996 17:05:33 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma010205; Wed, 29 May 96 17:05:06 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA06377; Wed, 29 May 96 17:05:12 EDT
Received: by relay.tis.com; id RAA10200; Wed, 29 May 1996 17:05:04 -0400
Received: from pancake.remcomp.fr(194.51.30.1) by relay.tis.com via smap (V3.1)
id xma010130; Wed, 29 May 96 17:04:18 -0400
Message-Id:
Received: from smile by smile.remcomp.fr (UUPC/extended 1.12j) with UUCP
for snmp2@tis.com; Wed, 29 May 1996 21:13:42 +0200
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: info@smile.remcomp.fr
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
To: hnms-users@maillist.cs.orst.edu
Date: Wed, 29 May 1996 21:13:41
Subject: How to join JIDM
Priority: normal
X-Mailer: PMail v3.0 (R1)
X-Orig-Sender: snmpv2-approval@neptune.tis.com
Precedence: bulk
Hello,
It has been pointed out to us that we should not use email to announce
products. On behalf of SMILE Inc. I appologize for those who did
not appreciate that mail.
I would only to mention to people interested in the CORBA-CMIP-SNMP
Inter-working work driven by JIDM that they can participate to JIDM
discussions on the mailing list xojidm@xopen.co.uk. XoJIDM is a public
mailing list. Your company does not need to be a member of the X/Open
in order to participate to that work. To subscribe send exculisivly an
email to postmaster@xopen.co.uk and provides him with your complete
affiliation: company, email ....
JIDM work is very important. It is going to be adopted by the
Network Management Forum. The OMG has adopted for TMN. ISO-ODMA
will probably adopt it also.
JIDM is specifying now gateways in order to enable inter-working
between CORBA and CMIP on one hand and between CORBA and SNMP on the
other hand. For the latter we need active participation of the SNMP
community. I'm the editor of the SNMP-CORBA inter-working document I
solliciate the SNMP community to help in this work. If you
have any ideas or suggestion then send them to xojidm@xopen.co.uk
or to me directly (soukouti@smile.remcomp.fr).
Looking forward to see a lot of contributions.
Best Regards
Dr. Nader Soukouti
ps. Please send us again your email by fax if you dont receive a
reply within 48 hours.
----------------------------------------------------------------------------
E-mail: info@smile.remcomp.fr Smile SARL
Tel: +33 (1) 40 59 09 00 Etudes et Developpements Informatiques
Fax: +33 (1) 40 59 09 01
Postal: 29, rue Viala
75015 Paris
France
----------------------------------------------------------------------------
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09180;
31 May 96 3:16 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09176;
31 May 96 3:16 EDT
Received: from mustang.via.net by CNRI.Reston.VA.US id aa03171;
31 May 96 3:16 EDT
Received: from Pbagnslr (la-ip5.via.net [204.188.133.5]) by mustang.via.net (8.6.9/8.6.9) with SMTP id AAA24159; Fri, 31 May 1996 00:00:36 -0700
Message-Id: <199605310700.AAA24159@mustang.via.net>
Comments: Authenticated sender is
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: BargainSeller
To: ltrbox@mustang.via.net
Date: Thu, 30 May 1996 18:31:00 +0000
Subject: Bargain Seekers #8
Reply-to: ltrbox@via.net
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.10)
THE BARGAIN SEEKERS ADS -The Net Connection for Bargain Advertisements
============================================================
Your name was referred to us via the membership directory.
============================================================
Our research indicates the following material is of interest to you. If you
prefer not to be on this mailing list, please let us know by hitting "reply"
and typing the word "REMOVE" in the SUBJECT field, and you will be promptly
removed. THIS IS AN AUTOMATIC FUNCTION -- IF YOU ADD ANYTHING
OTHER THAN "REMOVE" YOU ARE LIKELY TO BE LEFT ON THE LIST! !
============================================================
### If you're interested in advertising in the next issue of The Bargain
Seekers Advertisements look for info at the end of this issue! ! ###
*******************************************************************************
============================================================
####VERY IMPORTANT: If you wish to contact any of the following
advertisers you must REPLY TO THE E-MAIL ADDRESSES IN THE ADS. DO
NOT HIT REPLY! Your message will not reach its intended recipient.####
============================================================
F R E E Merchandise & Cash !
RECEIVE $1,000.00'S weekly in free merchandise and cash.
Clothes-Computers-Food-Electronics-Housewares-Jewelry-Luggage
and you name it !
Established business shows you how.
Never leave home or meet anyone.
No Products to buy ever !
No recruiting....No MLM....not your regular business opportunity. This
is the real deal.
Never dress for work again.
Work whenever you want. Part time or Full Time
Women and Men
Work anywhere you are.
No experience necessary.
We help those that work with us.
Start right away by simply e-mailing our auto-responder
at "CAPITAL@USERS.MWCI.NET" with the word "REPLY" in the text area
for our FREE REPORT.
********************************************************************************
FIND TRUE LOVE ON-LINE!
Learn How from someone who found it....and you can too!
A true story PLUS a Step-by-Step Guide on how to find the person you
always dreamed of....On-Line !
LearnHow to use:
CHAT ROOMS successfully and SAFELY. A must for anyone serious about
cyber-love.
MESSAGE BOARDS- Which ones are super powerful and draw potential
prospects like amagnet.
CLASSIFIEDS and PERSONALS- a special technique for reading these and
making good choices is revealed.
WWW DATING SERVICES- Why these are a last resort
FORUMS- Learn which one is guaranteed to produce results for you!
The story and the Guide apply to both MEN and WOMEN.
Change your life TODAY! E-mail our autoresponder at
"LIFESTYL@USERS.MWCI.NET" and type "REPLY" in the text box for
complete details.
*******************************************************************************
SAVE YOUR COMPUTER SCREEN
INSTANTLY REMOVE Dust and Dirt.
Stop scratches, smears, residue and damage.
Save hundreds of dollars in costly replacements.. just like the experts do.
Clean Speakers
Clean Entertainment Centers
Clean Audio Visual Equipment
Clean Lucite
Clean Lamp Shades and Books
A Great Lint Remover
This fabulous product works dry and can be used over and over.
Then quickly and effortlessly clean it with soap and water
We sell Gonzo because we use and believe in Gonzo
Our 30 day no questions asked guarantee policy backs up our confidence
in this fine product.
To order one today send $9.95 plus $2.95 S/H to :
Paraklesis
1 Ormian Drive
Pomona, New York 10970
Please allow 3-4 weeks for delivery
*******************************************************************************
============================================================
B AR G A I N S E E K E R S C O - O P ' S I N F O
For more information on advertising in the next Bargain Seekers Co-op
just send an e-mail to our Auto-Responder at "BARGNSLR@USERS.MWCI.NET"
on type "INFO" in the subject heading. It will respond with pricing and
availability dates within two minutes!
============================================================
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23326;
31 May 96 15:23 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23322;
31 May 96 15:23 EDT
Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa13164;
31 May 96 15:23 EDT
Received: from hpdmd48.boi.hp.com by paloalto.access.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA156219409; Fri, 31 May 1996 12:03:30 -0700
Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP
(1.37.109.16/15.5+ECS 3.4 Openmail) id AA288309406; Fri, 31 May 1996 13:03:27 -0600
Received: from hp.com by hpbs987.boi.hp.com with SMTP
(1.37.109.4/15.5+IOS 3.12) id AA21128; Fri, 31 May 96 12:53:00 -0600
Received: from uscore.underscore.com ([199.125.69.1]) by hp.com with SMTP
(1.37.109.16/15.5+ECS 3.3) id AA088189393; Fri, 31 May 1996 12:03:13 -0700
Received: by uscore.underscore.com (Smail3.1.28.1 #5)
id m0uPZNn-000US2C; Fri, 31 May 96 14:57 EDT
Message-Id:
Date: Fri, 31 May 96 14:57 EDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: JK Martin
To: lstein@fapo.com
Subject: Re: Change in Ultimate Meeting Schedule
Cc: pmi@hpbs987.boi.hp.com
Hi, Larry.
I have a real schedule conflict with having the October meetings
the first week in October.
Can we move the meetings to the following (or any other) week in
October?
...jay