Output from "cron" command

[[e-mail]]

Your "cron" job

(cd /home/ietf/MAILING-LISTS/ietf_list; ../make_lists_mx ../ietf 10 ietf_sub ietf list;)

produced the following output:

/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
Now sorting the address list, please wait...
Now creating the address files...








To: [e-mail]
Subject: Output from "cron" command
Date: Fri, 16 Feb 96 0:17:40 EST
From: [e-mail]
Sender: [e-mail]
Message-ID:  <[e-mail]>

Your "cron" job

(cd /home/ietf/MAILING-LISTS/ietf_list_123; ../make_lists_mx ../ietf-123 10 ietf_123_sub ietf-123 privlist;)

produced the following output:

/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
ns_skiphdr returned char * 0...
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
Now sorting the address list, please wait...
Now creating the address files...








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07571;
          16 Feb 96 1:27 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07566;
          16 Feb 96 1:27 EST
Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa22583;
          16 Feb 96 1:27 EST
Received: by mx2.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA01350;
	Thu, 15 Feb 96 21:53:16 -0800
Errors-To: [e-mail]
X-Orig-Sender: [e-mail]
Received: from rurha-pente.epilogue.com by mx2.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA01344;
	Thu, 15 Feb 96 21:53:13 -0800
Received: from rurha-pente.epilogue.com by rurha-pente.epilogue.com id aa20230;
          16 Feb 96 00:53 -0500
To: IMAP Interest List <[e-mail]>
Subject: Re: UID EXPUNGE 
In-Reply-To: Message from Mark Crispin <[e-mail]> 
             dated "Wed, 14 Feb 96 12:50:41 PST"
             <[e-mail]> 
References: <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 16 Feb 1996 00:53:07 -0500
Sender:[e-mail]
From: Rob Austein <[e-mail]>
Message-Id:  <[e-mail]>

Rather to my surprise, Mark's argument has convinced me that UID
EXPUNGE isn't worth adding.  I'm surprised because I've been bitten by
the thing John's trying to fix all too many times using DMSP.

Unless we change the EXPUNGE semantics, I think the rule has to be
that you should never set \Deleted unless you're willing to see the
message get expunged at any time.  Maybe it'll still be around later
if you want to clear \Deleted, maybe it won't.  Not doing EXPUNGE
right away is just an optimization, there's no guarantee that you'll
be able to undo a delete.  Never set \Deleted unless you mean it.

Whether or not it was a good idea for a 1990s Internet protocol to
reimplement TOPS-20 filesystem semantics all the way down to
"spontaneous" expunge is another question entirely, but that's how the
protocol currently works and I don't think it's worth holding up
standardization to rehash it now.

--Rob








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08809;
          16 Feb 96 3:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08805;
          16 Feb 96 3:14 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa28707; 16 Feb 96 3:13 EST
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id DAA28946; Fri, 16 Feb 1996 03:12:49 -0500
Received: from dimacs.rutgers.edu ([e-mail] [128.6.75.16]) by list.cren.net (8.6.12/8.6.12) with ESMTP id DAA28874 for <[e-mail]>; Fri, 16 Feb 1996 03:11:37 -0500
Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id DAA02469 for <[e-mail]>; Fri, 16 Feb 1996 03:11:38 -0500
Received: from perseus.peganet.com by relay5.UU.NET with SMTP 
	id QQaddg01692; Fri, 16 Feb 1996 03:11:36 -0500 (EST)
Received: (from root@localhost) by perseus.peganet.com (8.6.12/8.6.9) id DAA24619; Fri, 16 Feb 1996 03:12:35 -0500
Message-Id: <4g1e9i$[e-mail]>
Date: Fri, 16 Feb 1996 02:10:00
X-Orig-Sender: [e-mail]
Sender:[e-mail]
From: [e-mail]
To: [e-mail]
Subject: FREE MOUSEPADS!
X-Listprocessor-Version: 8.0(beta) -- ListProcessor by CREN

Dear Cyberfriend,

Give  me  a moment to introduce the newest, largest, fastest
turnaround,  best  customer support , and most  importantly,
least expensive  computer Mega-store to enter  the galaxy in
cyberspace,  ESINET.   We  at  ESINET  pride  ourselves   on
providing  the  friendly  support  before  and  after   your
purchase  that  no other online store can.   Our  Mega-sales
team, with their Mega-knowledge, with our Mega-product  line
is  ready  to  assist  your  hardware/software  needs,  just
call!!!  Just an example of our Mega-low prices:

R  A  M  is only $28.50 per megabyte for 30-pin  and  72-pin
SIMMS!!!

***FREE MOUSEPAD WITH EVERY ORDER***

Check out our website for our latest hot sheet of Mega-deals
and give us a call.  We are the friendliest folks in space.


 1-800-443-3229 ask for our Mega Sales Department

http://esinet.com/upgrade.htm

email:  [e-mail]


Sincerely,
ESINET Staff










Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08826;
          16 Feb 96 3:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08822;
          16 Feb 96 3:14 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa29071; 16 Feb 96 3:14 EST
Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by merit.edu (8.7.3/merit-2.0) with ESMTP id DAA17297 for <[e-mail]>; Fri, 16 Feb 1996 03:11:36 -0500 (EST)
Received: from perseus.peganet.com by relay6.UU.NET with SMTP 
	id QQaddg06614; Fri, 16 Feb 1996 03:11:34 -0500 (EST)
Received: (from root@localhost) by perseus.peganet.com (8.6.12/8.6.9) id DAA24614; Fri, 16 Feb 1996 03:12:33 -0500
To: [e-mail]
Path: usenet
Sender:[e-mail]
From: [e-mail]
Newsgroups: info.ietf.njm
Subject: FREE MOUSEPADS!
Date: Fri, 16 Feb 1996 02:09:58
Organization: Pegasus Software & Imaging
Lines: 32
Message-ID: <4g1e9g$[e-mail]>
NNTP-Posting-Host: peg7-ts14.peganet.com

Dear Cyberfriend,

Give  me  a moment to introduce the newest, largest, fastest
turnaround,  best  customer support , and most  importantly,
least expensive  computer Mega-store to enter  the galaxy in
cyberspace,  ESINET.   We  at  ESINET  pride  ourselves   on
providing  the  friendly  support  before  and  after   your
purchase  that  no other online store can.   Our  Mega-sales
team, with their Mega-knowledge, with our Mega-product  line
is  ready  to  assist  your  hardware/software  needs,  just
call!!!  Just an example of our Mega-low prices:

R  A  M  is only $28.50 per megabyte for 30-pin  and  72-pin
SIMMS!!!

***FREE MOUSEPAD WITH EVERY ORDER***

Check out our website for our latest hot sheet of Mega-deals
and give us a call.  We are the friendliest folks in space.


 1-800-443-3229 ask for our Mega Sales Department

http://esinet.com/upgrade.htm

email:  [e-mail]


Sincerely,
ESINET Staff










Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08942;
          16 Feb 96 3:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08938;
          16 Feb 96 3:28 EST
Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa05782;
          16 Feb 96 3:28 EST
Received: by mx1.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA08960;
	Thu, 15 Feb 96 23:59:32 -0800
Errors-To: [e-mail]
X-Orig-Sender: [e-mail]
Received: from sun4nl.NL.net by mx1.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA08954;
	Thu, 15 Feb 96 23:59:28 -0800
Received: from atis by sun4nl.NL.net via EUnet
	id AA19505 (5.65b/CWI-3.3); Fri, 16 Feb 1996 08:59:26 +0100
Received: from tardis.atis.nl by marsupial.atis.nl (SMI-8.6/SMI-SVR4)
	id IAA00384; Fri, 16 Feb 1996 08:37:35 GMT
Comments: This mail was sent by ATISMAIL for Windows version 2.4
X-Mailer: ATISMAIL (MS-Windows 95 / MS-Windows 3.11) version 2.4
Date: Fri, 16 Feb 1996 08:38:41 WET
X-Stardate: 35109.8
Sender:[e-mail]
From: Ron Croonenberg <[e-mail]>
Subject: Re[2]: Locked mailboxes / read only access
To: Mark Crispin <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Hi Mark,

>> It isn't possible to connect to a server and select a mailbox read-only so
>> another process still can connect read-write. This might be convenient. For
>> example a program that scans mailboxes to check if new mail arrived could
>> connect read-only so another user still can connect read-write without being
>> bothered by the process that is only checking the mailbox.
>
>Have you considered the EXAMINE command?  Also, look at the STATUS command in
>the latest draft.

I did take a look at the EXAMINE command. However there is a situation that
can't be distinguished. suppose I connect to a mailbox and delete a new message.
If (another) new message arrives before the next poll of the newmail program,
the EXAMINE command gives the same information. This way I cannot recognize that
a new mesage arrived.

However I didn't know about the latest draft, could you give me it's name ?


Ron

==================================================================

      AAAAAA  TTTTTTTTTTTT  II    SSSSSSSSS
     AA   AA       TT            SSS
    AA    AA       TT       II    SSSSSS
   AAAAAAAAA       TT       II        SSSSSS
  AA      AA       TT       II            SSS
 AA       AA       TT       II   SSSSSSSSSS
------------------------------------------------------------------
 Adviesbureau- Toegepaste Informatica en Systeemontwikkeling.
==================================================================
 A.T.I.S.                     | E-mail  : [e-mail]
 Dinxperlolaan 27             | Tel     : [phone]
 5043 GV Tilburg              | Fax     : [phone]
 The Netherlands              |
==================================================================








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09013;
          16 Feb 96 3:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09009;
          16 Feb 96 3:34 EST
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa08685;
          16 Feb 96 3:33 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa09012; 16 Feb 96 3:14 EST
Received: from relay.tis.com by neptune.TIS.COM id aa08998; 16 Feb 96 3:10 EST
Received: by relay.tis.com; id DAA02214; Fri, 16 Feb 1996 03:11:42 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
	id xma002210; Fri, 16 Feb 96 03:11:13 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
	id AA17768; Fri, 16 Feb 96 03:10:16 EST
Received: by relay.tis.com; id DAA02207; Fri, 16 Feb 1996 03:11:12 -0500
Received: from relay6.uu.net(192.48.96.16) by relay.tis.com via smap (V3.1)
	id xma002204; Fri, 16 Feb 96 03:11:10 -0500
Received: from perseus.peganet.com by relay6.UU.NET with SMTP 
	id QQaddg06643; Fri, 16 Feb 1996 03:12:17 -0500 (EST)
Received: (from root@localhost) by perseus.peganet.com (8.6.12/8.6.9) id DAA24679; Fri, 16 Feb 1996 03:13:15 -0500
To: [e-mail]
Path: usenet
Sender:[e-mail]
From: [e-mail]
Newsgroups: info.pem-dev
Subject: FREE MOUSEPADS!
Date: Fri, 16 Feb 1996 02:10:40
Organization: Pegasus Software & Imaging
Lines: 32
Message-Id: <4g1ear$[e-mail]>
Nntp-Posting-Host: peg7-ts14.peganet.com
X-Orig-Sender: [e-mail]
Precedence: bulk

Dear Cyberfriend,

Give  me  a moment to introduce the newest, largest, fastest
turnaround,  best  customer support , and most  importantly,
least expensive  computer Mega-store to enter  the galaxy in
cyberspace,  ESINET.   We  at  ESINET  pride  ourselves   on
providing  the  friendly  support  before  and  after   your
purchase  that  no other online store can.   Our  Mega-sales
team, with their Mega-knowledge, with our Mega-product  line
is  ready  to  assist  your  hardware/software  needs,  just
call!!!  Just an example of our Mega-low prices:

R  A  M  is only $28.50 per megabyte for 30-pin  and  72-pin
SIMMS!!!

***FREE MOUSEPAD WITH EVERY ORDER***

Check out our website for our latest hot sheet of Mega-deals
and give us a call.  We are the friendliest folks in space.


 1-800-443-3229 ask for our Mega Sales Department

http://esinet.com/upgrade.htm

email:  [e-mail]


Sincerely,
ESINET Staff










Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10724;
          16 Feb 96 5:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10720;
          16 Feb 96 5:49 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa07633;
          16 Feb 96 5:49 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA09765 for uri-out; Fri, 16 Feb 1996 05:01:43 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA09760 for <[e-mail]>; Fri, 16 Feb 1996 05:01:40 -0500
Received: from necom830.cc.titech.ac.jp by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA19350  (mail destined for [e-mail]); Fri, 16 Feb 96 04:52:27 -0500
Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Fri, 16 Feb 1996 18:30:26 +0900
Sender:[e-mail]
From: Masataka Ohta <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: http charset labelling
To: Keld J|rn Simonsen <[e-mail]>
Date: Fri, 16 Feb 96 18:30:24 JST
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>; from "Keld J|rn Simonsen" at Feb 14, 96 4:48 pm
X-Mailer: ELM [version 2.3 PL11]
X-Orig-Sender: [e-mail]
Precedence: bulk

Keld;

I wrote:

> > So, code mapping proposal which is proven not to work on paper is,
> > IMHO, almost useless. Maybe, URLs in e-mail are rare exceptions.

Again, code mapping proposal which is proven not to work on paper is
almost useless.

> To me it means that the URL is hidden and can be anything so it
> does not matter then if it is encoded in a special charset or not.

On browsers, yes, it is hidden. So, it is meaningless to use
a special charset.

						Masataka Ohta








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10746;
          16 Feb 96 5:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10742;
          16 Feb 96 5:51 EST
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa08588;
          16 Feb 96 5:51 EST
Received: from localhost by reef.bucknell.edu with SMTP
	(5.65/IDA-1.2.8) id AA04253; Fri, 16 Feb 1996 05:45:40 -0500
Date: Fri, 16 Feb 1996 05:45:40 -0500
Message-Id: <199602160352.IAA24662@comm10>
Errors-To: [e-mail]
Reply-To: [e-mail]
Originator: [e-mail]
X-Orig-Sender: [e-mail]
Precedence: bulk
Sender:[e-mail]
From: Rajesh Saluja <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Re: Default Gateways.
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
X-Mailer: ELM [version 2.4 PL24]

[e-mail] writes:
> 
> 
>      Any suggestions on how I can make a dhcp client use its own IP address 
>      as the default gateway using dhcp server on an NT box? I'm not on this 
>      mailing list so please cc any replies back to my address.
>      
>      Regards,
>      Bret Clark
>      Cabletron Systems
>      [e-mail]
> 
It means that your client is a router and it is requesting an IP address from
the DHCP server. BUT in the beginning of the DHCP RFC , it is clearly
mentioned that DHCP is not intended for use in configuring routers...
 
regards:
Rajesh Saluja
email: [e-mail]








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10771;
          16 Feb 96 5:53 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10767;
          16 Feb 96 5:53 EST
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa09428;
          16 Feb 96 5:53 EST
Received: from localhost by reef.bucknell.edu with SMTP
	(5.65/IDA-1.2.8) id AA04135; Fri, 16 Feb 1996 05:42:52 -0500
Date: Fri, 16 Feb 1996 05:42:52 -0500
Message-Id: <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Originator: [e-mail]
X-Orig-Sender: [e-mail]
Precedence: bulk
Sender:[e-mail]
From: Eric Weber <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: digests
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4


I happen to like digest mailing lists.  It's easier to focus when I
read all of the DHCP messages at one time.  Even if they change their
policy back, I suggest leaving digest as an option.

-- Eric









Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11504;
          16 Feb 96 6:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11500;
          16 Feb 96 6:28 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa28711;
          16 Feb 96 6:28 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA09894 for uri-out; Fri, 16 Feb 1996 05:14:27 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA09889 for <[e-mail]>; Fri, 16 Feb 1996 05:14:25 -0500
Received: from necom830.cc.titech.ac.jp by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA19400  (mail destined for [e-mail]); Fri, 16 Feb 96 05:12:46 -0500
Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Fri, 16 Feb 1996 18:30:26 +0900
Sender:[e-mail]
From: Masataka Ohta <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: http charset labelling
To: Keld J|rn Simonsen <[e-mail]>
Date: Fri, 16 Feb 96 18:30:24 JST
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>; from "Keld J|rn Simonsen" at Feb 14, 96 4:48 pm
X-Mailer: ELM [version 2.3 PL11]
X-Orig-Sender: [e-mail]
Precedence: bulk

Keld;

I wrote:

> > So, code mapping proposal which is proven not to work on paper is,
> > IMHO, almost useless. Maybe, URLs in e-mail are rare exceptions.

Again, code mapping proposal which is proven not to work on paper is
almost useless.

> To me it means that the URL is hidden and can be anything so it
> does not matter then if it is encoded in a special charset or not.

On browsers, yes, it is hidden. So, it is meaningless to use
a special charset.

						Masataka Ohta








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13958;
          16 Feb 96 9:37 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13954;
          16 Feb 96 9:37 EST
Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa21261;
          16 Feb 96 9:36 EST
Received: by mx1.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA13598;
	Fri, 16 Feb 96 05:52:00 -0800
Errors-To: [e-mail]
X-Orig-Sender: [e-mail]
Received: from sums2.rdg.ac.uk by mx1.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA13588;
	Fri, 16 Feb 96 05:51:44 -0800
Received: from suma3.rdg.ac.uk (actually host suma3-e3.rdg.ac.uk) 
          by sums2.rdg.ac.uk with SMTP - Local (PP);
          Fri, 16 Feb 1996 13:31:20 +0000
Received: by suma3.rdg.ac.uk (8.6.12/8.6.12) id NAA17157;
          Fri, 16 Feb 1996 13:31:12 GMT
Date: Fri, 16 Feb 1996 13:31:11 +0000 (GMT)
Sender:[e-mail]
From: John Stumbles <[e-mail]>
To: "(Lee C. W. Hutchison II.)" <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: UID EXPUNGE
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 15 Feb 1996, (Lee C. W. Hutchison II.) wrote:

> On Thu, 15 Feb 1996, Chris Newman wrote:
> > -----
> > Chris Newman <[e-mail]>, http://www.contrib.andrew.cmu.edu/~nifty/
> > By using the word "shit" here, I may be jailed for 2 years and fined $250,000.

>   Lee C. W. Hutchison II. is equally outraged, and wants to join in the 
> civil disobidence action, here. He says "Oh, shit" all the time, but 
> ususally it is only when catsup lands in his lap, or something dumb like 
> that....he thinks being brought to justice for that is a violation of the 
> Free Speech established at UCLA by Mario Savio in 1963....listening, FBI?
> He feels liberal Republicans shouild be willing to take on the system, to 
> be a witness to the social change uncompleted in the 1960's.....Praise 
> the Lord, and pass the Catsup!  Lee C. W. Hutchison II>  
> <[e-mail]> 

OK, equally or even more off topic here (the only justification I can find
for posting this to the IMAP list is that I'm doing with an IMAP-capable
mailer :-) --- can one of you US folks tell me what 'catsup' is? 

Oh, and for you CDA fans, here's a poem by one of our more celebrated
British poets. I'm not sure whether he was ever Poet Laureate (official
poet to our Queen and Royal Family). The British 'Poetry Society' used to
(may still do) run a series of adverts on the London tube trains called
'Poems on the Underground' in which they print poems, for travellers to
read. This was one of them:


	This Be The Verse

	Philip Larkin 


They fuck you up, your mum and dad 
They may not mean to, but they do. 
They fill you with the faults they had 
And add some extra, just for you. 

But they were fucked up in their turn 
By fools in old-style hats and coats, 
Who half the time were soppy-stern 
And half at one another's throats. 

Man hands on misery to man, 
It deepens like a coastal shelf. 
Get out as early as you can, 
And don't have any kids yourself. 

--
John Stumbles                                      [e-mail]
Computer Services, University of Reading       http://www.rdg.ac.uk/~suqstmbl 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTICE: This E-mail is indecent and intended to annoy.
        Please notify all appropriate government agencies.








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19032;
          16 Feb 96 12:43 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab19028;
          16 Feb 96 12:43 EST
Received: from hpcsos.col.hp.com by CNRI.Reston.VA.US id aa09598;
          16 Feb 96 12:43 EST
Received: from hpdmd48.boi.hp.com by hpcsos.col.hp.com with ESMTP
	(1.37.109.16/15.5+IOS 3.14) id AA014032577; Fri, 16 Feb 1996 10:42:57 -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 AA006752308; Fri, 16 Feb 1996 10:38:28 -0700
Received: from paloalto.access.hp.com by hpbs987.boi.hp.com with SMTP
	(1.37.109.4/15.5+IOS 3.12) id AA08194; Fri, 16 Feb 96 10:24:30 -0700
Received: from avalon.dpc.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA014963633; Wed, 14 Feb 1996 13:33:53 -0800
Received: (from smap@localhost) by avalon.dpc.com (8.6.11/8.6.9) id MAA16998 for <[e-mail]>; Wed, 14 Feb 1996 12:09:37 -0800
Sender:[e-mail]
From: [e-mail]
Received: from gate(10.30.0.166) by avalon via smap (V1.3)
	id sma016995; Wed Feb 14 12:09:16 1996
Received: by gate.dpc.com (5.65/DEC-Ultrix/4.3)
	id AA10048; Wed, 14 Feb 1996 12:07:51 -0800
Date: Wed, 14 Feb 1996 12:07:51 -0800
Message-Id: <[e-mail]>
To: "GATE [e-mail]"@avalon.dpc.com
Subject: SENSE Meeting Date (Retransmission)

No I have not changed the meeting dates.  I need a calendar refresh course.

The SENSE meeting is still scheduled for Feb 21 and 22.

	Ron Bergman
	Dataproducts
	[e-mail]









Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20734;
          16 Feb 96 13:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20728;
          16 Feb 96 13:47 EST
Received: from hpcsos.col.hp.com by CNRI.Reston.VA.US id aa15621;
          16 Feb 96 13:47 EST
Received: from hpdmd48.boi.hp.com by hpcsos.col.hp.com with ESMTP
	(1.37.109.16/15.5+IOS 3.14) id AA052086397; Fri, 16 Feb 1996 11:46:37 -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 AA175076217; Fri, 16 Feb 1996 11:43:37 -0700
Received: from hp.com by hpbs987.boi.hp.com with SMTP
	(1.37.109.4/15.5+IOS 3.12) id AA10511; Fri, 16 Feb 96 11:29:27 -0700
Received: from uscore.underscore.com by hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.3) id AA014155917; Fri, 16 Feb 1996 10:38:38 -0800
Received: by uscore.underscore.com (Smail3.1.28.1 #5)
	id m0tnUyz-000US2C; Fri, 16 Feb 96 13:34 EST
Message-Id: <[e-mail]>
Date: Fri, 16 Feb 96 13:34 EST
Sender:[e-mail]
From: JK Martin <[e-mail]>
To: [e-mail]
Subject: SENSE Architecture Document not yet available

I apologize to one and all for not having this document ready today,
Friday, Feb 16, as planned.

I expect to have the first draft version of the document on the wire
sometime over the weekend, or Monday morning at the latest.

Thanks for your patience.

	...jay








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26437;
          16 Feb 96 18:21 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26433;
          16 Feb 96 18:21 EST
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa26291;
          16 Feb 96 18:21 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa24464;
          16 Feb 96 18:13 EST
Received: from rsa.com by neptune.TIS.COM id aa24450; 16 Feb 96 18:08 EST
Received: from snail.rsa.com by RSA.COM with SMTP
	id AA26606; Fri, 16 Feb 96 15:01:48 PST
Received: from cc:Mail by snail.rsa.com
	id AA824511993; Fri, 16 Feb 96 15:06:07 PST
Date: Fri, 16 Feb 96 15:06:07 PST
Sender:[e-mail]
From: spock <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], 
    [e-mail], [e-mail], 
    Raph Levien <[e-mail]>
Subject: Re: A brief comparison of email encryption protocols
X-Orig-Sender: [e-mail]
Precedence: bulk

Hello Ralph,

Thanks for your interest in S/MIME.  A couple of minor corrections to your 
comparison seem to be in order.

>S/MIME is an attempt to graft MIME support onto underlying PEM
>standards. See http://www.rsa.com/rsa/S-MIME/ for more info.

S/MIME integrates PKCS #7 and #10 message services (not PEM) into MIME.

>Probably the most controversial aspect of S/MIME is its signature
>format. An S/MIME signed message is a MIME multipart in which the 
>first part is the data to be signed, and the second part is a 
>complete PKCS #7 (section 10) signed message.

Although the description of this format is accurate, this format is 
only documented as an option, not the primary signature format.  This 
option has been supplied for backward compatability to address a mixed 
(S/MIME-aware and non-S/MIME aware) audience of recipients.  The 
primary signature format is a PKCS #7 signed message (including signed 
MIME content) carried in a single body part: application/x-pkcs7-mime.










Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26958;
          16 Feb 96 18:42 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26953;
          16 Feb 96 18:42 EST
Received: from relay.hp.com by CNRI.Reston.VA.US id aa08249; 16 Feb 96 18:42 EST
Received: from hpdmd48.boi.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA218834057; Fri, 16 Feb 1996 15:41:04 -0800
Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.4 Openmail) id AA147883980; Fri, 16 Feb 1996 16:39:41 -0700
Received: from relay.hp.com by hpbs987.boi.hp.com with SMTP
	(1.37.109.4/15.5+IOS 3.12) id AA05772; Fri, 16 Feb 96 16:26:15 -0700
Received: from alpha.xerox.com by relay.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.3) id AA211333719; Fri, 16 Feb 1996 15:35:21 -0800
Received: from norman.cp10.es.xerox.com ([13.240.128.43]) by alpha.xerox.com with SMTP id <14759(9)>; Fri, 16 Feb 1996 15:30:33 PST
Received: from power (power.cp10.es.xerox.com) by norman.cp10.es.xerox.com (4.1/SMI-4.1)
	id AA24111; Fri, 16 Feb 96 15:30:49 PST
Received: by power (5.x/SMI-SVR4)
	id AA00970; Fri, 16 Feb 1996 15:28:33 -0800
Date: Fri, 16 Feb 1996 15:28:33 PST
Sender:[e-mail]
From: "Edwin H. Reveche" <[e-mail]>
Message-Id: <9602162328.AA00970@power>
To: [e-mail], [e-mail]
Subject: Re: Attendee List for February 20-21 SENSE Meeting
Cc: [e-mail], [e-mail], [e-mail], 
    [e-mail]
X-Sun-Charset: US-ASCII


Ron and others,

Sorry for the confusion, but I won't able to attend the SENSE meetings.  I did ask to have information forwarded to me, but that was only to evaluate whether I would be able to attend or not, and to forward the information to other Xerox colleagues.

Please remove me from the attendee list.  I look forward to receiving information regarding the meeting's output.

Ed Reveche








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27526;
          16 Feb 96 19:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27522;
          16 Feb 96 19:08 EST
Received: from hp.com by CNRI.Reston.VA.US id aa23572; 16 Feb 96 19:08 EST
Received: from hpdmd48.boi.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA165495585; Fri, 16 Feb 1996 16:06:27 -0800
Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.4 Openmail) id AA194305532; Fri, 16 Feb 1996 17:05:32 -0700
Received: from hp.com by hpbs987.boi.hp.com with SMTP
	(1.37.109.4/15.5+IOS 3.12) id AA06849; Fri, 16 Feb 96 16:51:59 -0700
Received: from postbox.anu.edu.au by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA296182477; Wed, 14 Feb 1996 16:01:28 -0800
Received: from coombs.anu.edu.au by postbox.anu.edu.au with SMTP
	(1.37.109.16/16.2) id AA193049091; Thu, 15 Feb 1996 10:04:51 +1100
Received: from slbri1p04.ozemail.com.au by coombs.anu.edu.au (1.38.193.4) id AA11281; Thu, 15 Feb 1996 10:02:49 +1100
Date: Thu, 15 Feb 1996 10:02:49 +1100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Don Wright <[e-mail]>
Sender:[e-mail]
From: "cyberzone.com.au" <[e-mail]>
Subject: Driver vs. interrupt feedind
Cc: "pmi%hpbs987.boi.hp.com" <[e-mail]>

Don,

>printer to stop before committing the page to paper (using alerts) you
>can insure that the page has been paid for before printing it.
>
>Why not spend some of your efforts to write the drivers necessary to
>exploit this ability and convince other printer manufacturers that SNMP
>is not the be all to end all for printer management?  Demonstrating
>superior functionality is one of the more efficient ways to move the
>industry.  While there is no guarantee of success, there never is!!
>
>Don

Reason: SPEED. Faster to rasterize while marking simultaneously and only
stop normal process in exceptional cirmumstances. Password protection would
still be nice though :-)











To: [e-mail]
Subject: Output from "cron" command
Date: Fri, 16 Feb 96 20:17:31 EST
From: [e-mail]
Sender: [e-mail]
Message-ID:  <[e-mail]>

Your "cron" job

/home/ietf/BIN/mirror_nic.nordu.net;

produced the following output:


package=ietf nic.nordu.net:/aux/dbs/gopher/data/ftp/ietf -> /ftp/ietf/
ftp timeout set to 40
Connecting to nic.nordu.net
Cannot connect, skipping package

package=iesg nic.nordu.net:/aux/dbs/gopher/data/ftp/iesg -> /ftp/iesg/
ftp timeout set to 40
Connecting to nic.nordu.net
Cannot connect, skipping package

package=internet-drafts nic.nordu.net:/aux/dbs/gopher/data/ftp/internet-drafts -> /ftp/internet-drafts/
ftp timeout set to 40
Connecting to nic.nordu.net
220 nic.nordu.net FTP server (Version wu-2.4(1) Wed Sep 6 11:42:51 MET DST 1995) ready.
login as ietf
---> USER ietf
331 Password required for ietf.
---> PASS <somestring>
230 User ietf logged in.
---> REST 0
350 Restarting at 0. Send STORE or RETRIEVE to initiate transfer.
---> TYPE I
200 Type set to I.
---> HELP SITE
214-The following SITE commands are recognized (* =>'s unimplemented).
   IDLE    HELP    GPASS   MINFO   EXEC    CDPATH 
Scanning local directory /ftp/internet-drafts/
Scanning remote directory /aux/dbs/gopher/data/ftp/internet-drafts
---> CWD /aux/dbs/gopher/data/ftp/internet-drafts
214 Direct comments to [e-mail].
250 CWD command successful.
---> TYPE A
200 Type set to A.
---> PORT 132,151,1,35,16,23
200 PORT command successful.
---> LIST -lRat
150 Opening ASCII mode data connection for /bin/ls.
226 Transfer complete.
---> TYPE I
200 Type set to I.
compare directories for xfer
put file 1id-abstracts.txt as 1id-abstracts.txt
put file 1id-index.txt as 1id-index.txt
Cannot create symlinks on remote systems (1id-guidelines.txt -> ../ietf/1id-guidelines.txt)
Need to put file 1id-abstracts.txt as 1id-abstracts.txt (x)
---> PORT 132,151,1,35,16,112
200 PORT command successful.
---> STOR .in.1id-abstracts.txt.
150 Opening BINARY mode data connection for .in.1id-abstracts.txt..
226 Transfer complete.
---> RNFR .in.1id-abstracts.txt.
350 File exists, ready for destination name
---> RNTO 1id-abstracts.txt
250 RNTO command successful.
Need to put file 1id-index.txt as 1id-index.txt (x)
---> PORT 132,151,1,35,16,114
200 PORT command successful.
---> STOR .in.1id-index.txt.
150 Opening BINARY mode data connection for .in.1id-index.txt..
226 Transfer complete.
---> RNFR .in.1id-index.txt.
350 File exists, ready for destination name
---> RNTO 1id-index.txt
250 RNTO command successful.
disconnecting from nic.nordu.net
---> QUIT
221 Goodbye.
All done, Exiting








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28812;
          16 Feb 96 20:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa28808;
          16 Feb 96 20:28 EST
Received: from hp.com by CNRI.Reston.VA.US id aa11414; 16 Feb 96 20:28 EST
Received: from hpdmd48.boi.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA257400475; Fri, 16 Feb 1996 17:27:55 -0800
Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.4 Openmail) id AA051280455; Fri, 16 Feb 1996 18:27:35 -0700
Received: from hp.com by hpbs987.boi.hp.com with SMTP
	(1.37.109.4/15.5+IOS 3.12) id AA09051; Fri, 16 Feb 96 18:17:07 -0700
Received: from postbox.anu.edu.au by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA026704296; Wed, 14 Feb 1996 16:31:48 -0800
Received: from coombs.anu.edu.au by postbox.anu.edu.au with SMTP
	(1.37.109.16/16.2) id AA227654112; Thu, 15 Feb 1996 11:28:32 +1100
Received: from slbri1p25.ozemail.com.au by coombs.anu.edu.au (1.38.193.4) id AA15458; Thu, 15 Feb 1996 11:26:26 +1100
Date: Thu, 15 Feb 1996 11:26:26 +1100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: JK Martin <[e-mail]>
Sender:[e-mail]
From: "cyberzone.com.au" <[e-mail]>
Subject: SENSE - a good idea - really !
Cc: [e-mail]


Just so PWG does not mis-understand, I support SENSE per se; read on if
interested.

Jay wrote:
>However, I don't recall that anyone has suggested (or demanded) that a
>formal business study be conducted for your printer accounting/security
>stuff, either.

Geoff wrote:
Yes. You (and others) have demanded it. Both at the December meeting and
elsewhere in this long thread.

Jay wrote:
 All that has been asked of you is that you make available
>the "3-4 Mb" of email that you have captured documenting the need for
>these facilities.

>A much more important difference between how you are handling your demands
>for the printer accounting/security features versus my handling of the
>SENSE Project is that my company (Underscore) is "putting its money where
>its mouth is" by not only coordinating an ad hoc group effort, but more
>importantly, we are actually DEVELOPING a first pass solution even as I
>write this message.

Geoff wrote:
We have our chips on the table too.  If the manufacturers are happy to give
me the ROM code (which of course they will not) I would figure a way to
implement it. As it is, Tom and I have submitted a precise specification.
What further can be done ? It is one single feature, not a whole protocol.

Yes. I agree that writing drivers is hard. But it is up to each
manufacturer to write their own drivers. Also, I am unlear why this is
necessarily so. What I propose is OPTIONAL to implement and OPTIONAL if a
site wants to use it.  It is perfectly OK to have it latent in the ROM and
just waiting for budding developers,  PJL is an example of something that
is there but most do not know about it and few write drivers to take
advantage of it. Only then do they have to worry about drivers. This would
mean that Underscore would, for example, be possibly forced by clients who
wanted this feature to write a driver to take advantage of it.

Jay wrote:
>That's not to say that accounting/security can't be studied in parallel
>with SENSE.  Go for it.

Geoff wrote:

Finally, the choice items of mail will be published on a web page for all
to see just as soon as (a) I make sure it is ok by the originators of the
mail for their stuff to published (b) set the thing up.  Please note that
much of the mail is long, technical discussions, code, workarounds,
proposals etc. But there is still a hell of a lot of email collected over
the last few years specifically requesting security.

Jay, please understand that I have nothing against SENSE; on the contrary.
I would like to see it *enhanced* as a protocol: I think Harry Lewis has
some good ideas on this that are worthy of another look. It is just that I
do not enjoy the market metaphor as the world's panacea. You asked me to
provide maret evidence of the need for security; I asked you to
reciprocate. The market gets it wrong. In the stockmarket, people
necessarily get it wrong all of the time, and they are, after all, the
so-called professionals. You know as well as I do that if we used the
market metaphor alone then SENSE would be dead. This will cost vendors
money to implement, and that is a fact.

The truth is that we have to use our brains, hearts and efforts to
anticipate and innovate and second guess what people need/want but who do
not necessarily articulate or even know themselves.

Much of this is gut feeling.

There is nothing wrong with gut feelings; many of the great inventions this
century were plain accidents, like X-RAYS and penicillian; there were not
even gut feelings.   The point here is to get away from this narrow market
focus, or more accurately, people's *perceptions of what they think is the
market* and need for various things.  This cannot be proved or disproved
until a product exists. Whether we say yes or no to SENSE, the Cookie
proposal or whatever, let us clearly understand that we doing it on the
basis of guesswork as to how useful it will be at the end of the day.

By the way, I hardly think my idea is aimed for anything other than
networked, enterprise levels, assuming of course enterprise encompasses
large and small; a department within say the Gigantic Corporation may be an
enterprise; so is a Cyber Cafe.  My use of Circuit City was a bad anaolgy.

No the idea is not perfect, but it is do-able, and do-able quickly. A full
protocol would take years to develop and implement and involve endless
debates. Better to stick to a small, achievable item.  Some manufacturers
have already put in various security items over the years; my proposal is
to standardize a single, specific item.

And to those who think I am flaming PWG; sorry.  I like to see vigorous
debate; it is healthy.  Email is great but fails to convey many human
facial or vocal cues, so things can get mis-interpreted.  Like everyone
else, I want to see technical and engineering excellence that is relevant
to the market of today - and tomorrow.  I know that I don't have any hard
feelings towards anyone :-).










Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id ab29116;
          16 Feb 96 20:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa29112;
          16 Feb 96 20:54 EST
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa27067;
          16 Feb 96 20:54 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa26612;
          16 Feb 96 20:40 EST
Received: from nala.qualcomm.com by neptune.TIS.COM id aa26598;
          16 Feb 96 20:36 EST
Received: from [129.46.110.231] (llundblade-mac.qualcomm.com [129.46.110.231]) by nala.qualcomm.com (8.7.3/8.7.2/1.6) with ESMTP id RAA21567; Fri, 16 Feb 1996 17:37:56 -0800 (PST)
X-Sender: [e-mail]
Message-Id: <v03004d0cad4ac6d75935@[129.46.110.231]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 16 Feb 1996 17:02:56 -0800
To: Raph Levien <[e-mail]>, [e-mail], [e-mail], 
    [e-mail], [e-mail], 
    [e-mail]
Sender:[e-mail]
From: Laurence Lundblade <[e-mail]>
Subject: Re: A brief comparison of email encryption protocols
X-Orig-Sender: [e-mail]
Precedence: bulk

Raph, your summary is very useful!  I would like to make a few comments and
suggest a model for breaking down an email encryption system into four
components: the trust model, the key/certificate distribution system, the
on-the-wire certificate data structure and the on-the-wire transport data
structure.  The comments:

At 12:49 PM 2/14/96, Raph Levien wrote:
>....
> An additional grave concern is key management. Contrary to some
>beliefs, key management is not a solved problem. All of the proposals
>contain some mechanism for key management, but none of them have been
>demonstrated to be scalable to an Internet-wide email system. My
>belief is that the problems with key management do not stem from the
>classic Web of trust/certification hierarchy split, but the
>nonexistence of a distributed database (with nice interfaces) for
>holding keys. The encryption protocols also stand in the way of such a
>database, with key formats that are either overly complex, inadequate,
>or both.

Here here! agreed!


>   S/MIME remains firmly grounded in the X.509 certification
>hierarchy, although the FAQ claims that the guidelines for hierarchies
>are "more flexible" than in PEM.

X.509 v3 explicitly does allow for more flexibility.  To quote from section
12.4.1:

 g) Complete flexibility in trust models is required.  A strict hierarchical
    model which is adequate for a single organization is not adequate when
    considering the needs of multiple interconnected enterprises.  Flexibility
    is required in the selection of the first trusted CA in a certification
    path.  In particular, it should be possible to require that the
    certification path start in the local security domain of the public-key
    user system.


>   Probably the most controversial aspect of S/MIME is its signature
>format. An S/MIME signed message is a MIME multipart in which the
>first part is the data to be signed, and the second part is a complete
>PKCS #7 (section 10) signed message.

It is certainly technically possible to use the multipart/signed format
from RFC-1847 (also used in PGP/MIME) with PKCS #7.  It certainly seems
superior is almost every way to the multipart/alternative in the current
S/MIME draft.  Also Steve D. pointed out that the multipart/alternative
format is not the primary signature format.


Going back to breaking things down into four parts, these are some points I
know about.  Please correct me if I say something wrong and pardon some of
the details most of us already know:

The Trust Model
---------------
Any fully implemented system will have to choose some form of a trust
model.  Some possibilities are:
  * web of trust
  * strict hierarchy
  * web of hierarchies or some other hybrid

The important thing here is that there are many trust models that are valid
and useful and it may be useful for other components of the system to be
neutral to the trust model as is clearly the case with MOSS.

The Key Distribution System
---------------------------
A lot of components may go into this (protocols, client/server
architectures, local key stores) and it is probably the most complicated
part of any system.  Some options are:
  * distribution of keys manually via e-mail
  * automatic non-interactive lookup of keys from a server
  * interactive browsing of a key store for keys
  * revocation lists or none
  * online certificate verification via a secure channel
  * certificate caching

Probably the best thing to say, is that there's a lot of work to do here.

The Certificate format
----------------------
It seems possible to pick a certificate format independent of the other
issues.  Doing so would allow us to leverage components like we do with
other data objects like MIME.  There probably only two major contenders:
  * X.509 v3
     + broadly supported by standard bodies
     + supported by several industries (e.g., banking)
     + very rich and flexible
     + ASN.1
     - ASN.1 (tough for a student to get an ASN.1 compiler)
     - complicated
  * PGP keys
     + widely deployed
     + simple to write code for
     - difficult to lookup (linear search on key id required)
     - too simple to support many trust models and distribution systems

Note that both use the RSA algorithms, so they are interchangeable at some
very basic level.

The Transport of Content format
-------------------------------
This is the format of the actual message that is sent from one user to the
next.  I'm going to discard anything that doesn't handle MIME because I
don't think they are important any more.  Raph described a lot of this so
I'll just mention a few considerations explicitly about transport formats.
   * PGP/MIME
       From a data structure format this is a compact binary format.  It
       seems reasonable to implement, is documented and requires no special
       tools.  There is a performance problem with key look ups
       for signed message because a linear search is required unless the
       key or other data is always included with the message.

   * S/MIME  (PKCS + MIME)
       Uses PKCS format with some MIME formatting.  The main problems here
       are the multipart/alternative format for signatures and the ASN.1
       requirement.  An ASN.1 compiler is required to implement this.  PKCS
       has actually been around for a while and has been used for a number
       of cryptographic systems.

   * MOSS
       MOSS is perhaps the easiest to implement and the most flexible since
       it is an ASCII text protocol like other Internet protocols and because
       it explicitly supports several trust models.

I think the most important observation is that PGP/MIME and MOSS share the
security multiparts structure from RFC 1847.  It is also possible to use
the security multiparts format with PKCS #7 and thus S/MIME could be
changed to support it.  If this happened we'd have something in common for
all formats and it would make life much easier for all e-mail client
authors.  An added bonus is that RFC-1847 support allows an e-mail client
to support encryption and signing of full MIME entities with an external
program that can be configured like MIME content viewers are with something
like the mailcap facility.  It can be something as simple as a UNIX pipe to
a command like pgp.

Laurence Lundblade      <[e-mail]>
QUALCOMM Inc.           619-658-3584














Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29561;
          16 Feb 96 21:20 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa29557;
          16 Feb 96 21:20 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa12861;
          16 Feb 96 21:20 EST
Received: by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA19957>; Fri, 16 Feb 1996 17:53:28 -0800
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20)
	id <AA19950>; Fri, 16 Feb 1996 17:53:27 -0800
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: The RREQ list management
Reply-To: [e-mail]
Date: Fri, 16 Feb 96 17:53:26 PST
Sender:[e-mail]
From: List Manager Account <[e-mail]>
X-Orig-Sender: [e-mail]
Precedence: bulk



Hi.

The rreq list is now managed by MajorDomo at ISI.EDU.


To ADD yourself to this list, send a message to <[e-mail]>
with the line

	subscribe rreq

as the contents of the message.


To REMOVE yourself from this list, send a message to
<[e-mail]> with the line

	unsubscribe rreq

as the contents of the message.

The List Manager.









To: [e-mail]
Subject: Output from "cron" command
Date: Fri, 16 Feb 96 22:30:04 EST
From: [e-mail]
Sender: [e-mail]
Message-ID:  <[e-mail]>

Your "cron" job

/home/informix/bin/update_charters; 

produced the following output:

/home/informix/bin/wginfo stdguide -charter -id -rfc  > /ftp/ietf/stdguide/stdguide-charter.txt                                                                                                         
sh: /ftp/ietf/stdguide/stdguide-charter.txt: Permission denied








Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03357;
          16 Feb 96 23:46 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21404;
          16 Feb 96 23:46 EST
Date:     Fri, 16 Feb 96 23:46:34 EST
From:     "IETF.CNRI.Reston.VA.US Mail System" (MMDF) <[e-mail]>
Sender:   [e-mail]
Subject:  Failed mail  (msg.aa06144)
To:       [e-mail]
Message-ID:  <[e-mail]>

    Your message could not be delivered to
'[e-mail] (host: ebone.net) (queue: smtpns)' for the following
reason:  ' <[e-mail]>... User unknown'


    Your message follows:

Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06144;
          16 Feb 96 22:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10505;
          16 Feb 96 22:56 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06138;
          16 Feb 96 22:56 EST
To: [e-mail]
Subject: shadow directories
Date: Fri, 16 Feb 96 22:56:33 -0500
From: IETF Administrative User <[e-mail]>
Message-ID:  <[e-mail]>

The following files have changed:
   /ftp/ietf/0mtg-agenda.txt
   /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/internet-drafts/1id-abstracts.txt
   /ftp/internet-drafts/1id-index.txt
   /ftp/iesg/1old_standards.txt
   /ftp/iesg/1protocol_actions.txt
   /ftp/iesg/1rfc_index.txt
   /ftp/iesg/1wg_actions.txt








To: [e-mail]
Subject: Output from "cron" command
Date: Fri, 16 Feb 96 23:51:23 EST
From: [e-mail]
Sender: [e-mail]
Message-ID:  <[e-mail]>

Your "cron" job

(cd /home/ietf/MAILING-LISTS/ietf_list; ../make_lists_mx ../ietf 10 ietf_sub ietf list;)

produced the following output:

/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
Now sorting the address list, please wait...
Now creating the address files...








To: [e-mail]
Subject: Output from "cron" command
Date: Fri, 16 Feb 96 23:57:30 EST
From: [e-mail]
Sender: [e-mail]
Message-ID:  <[e-mail]>

Your "cron" job

(cd /home/ietf/MAILING-LISTS/ietf_list_123; ../make_lists_mx ../ietf-123 10 ietf_123_sub ietf-123 privlist;)

produced the following output:

/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
Now sorting the address list, please wait...
Now creating the address files...








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02524;
          17 Feb 96 16:29 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id af02485;
          17 Feb 96 16:29 EST
Received: from relay.hp.com by CNRI.Reston.VA.US id aa16963; 17 Feb 96 6:47 EST
Received: from hpdmd48.boi.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA282597631; Sat, 17 Feb 1996 03:47:12 -0800
Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.4 Openmail) id AA077077599; Sat, 17 Feb 1996 04:46:39 -0700
Received: from relay.hp.com by hpbs987.boi.hp.com with SMTP
	(1.37.109.4/15.5+IOS 3.12) id AA09450; Sat, 17 Feb 96 04:32:49 -0700
Received: from archimedes.inoc.sj.nec.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA133695293; Wed, 14 Feb 1996 16:48:18 -0800
Received: by inoc.sj.nec.com (8.7.3/YDL1.7-930126.17)
	id QAA04915(archimedes.inoc.sj.nec.com); Wed, 14 Feb 1996 16:45:56 -0800 (PST)
Received: by sj.nec.com (8.7.3/YDL1.7-940623.1)
	id QAA05652(netkeeper.sj.nec.com); Wed, 14 Feb 1996 16:10:07 -0800 (PST)
Received: by neclpd.lpd.sj.nec.com  (4.1/YDL1.7-911107.16)
	id AA05506(neclpd.lpd.sj.nec.com ); Wed, 14 Feb 96 16:07:20 PST
Message-Id: <[e-mail] >
X-Sender: tfrye@131.241.45.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 14 Feb 1996 16:09:48 -0700
To: [e-mail], [e-mail], [e-mail]
Sender:[e-mail]
From: Thomas Frye <[e-mail]>
Subject: Desktop Management Task Force (DMTF)
Cc: [e-mail], [e-mail], [e-mail]


NEC Technologies will be supporting the emerging industry standards for
network print management.  These standards are based around the IEEE
P1284.3  standards.  We would like more information on the Desktop
Management Task Force (DMTF) and the Network Printing Alliance (NPA).

Would you please send me information about the DMTF and NPA, or at least,
send me the correct email address for information?  Your cooperation in
this matter is greatly appreciated.  Thank you in advance for your help!

                                                        Tom Frye

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                                          _/
_/                               [e-mail]                       _/
_/                                                                          _/
_/ Tom Frye at NEC Technologies, Laser Printer Division, Mountain View, CA  _/
_/                                                                          _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/










Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05267;
          17 Feb 96 20:07 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05263;
          17 Feb 96 20:07 EST
Received: from relay.hp.com by CNRI.Reston.VA.US id aa26439; 17 Feb 96 20:07 EST
Received: from hpdmd48.boi.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA238965520; Sat, 17 Feb 1996 17:05:21 -0800
Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.4 Openmail) id AA009085502; Sat, 17 Feb 1996 18:05:02 -0700
Received: from hpbs9874.boi.hp.com by hpbs987.boi.hp.com with SMTP
	(1.37.109.4/15.5+IOS 3.12) id AA09819; Sat, 17 Feb 96 17:53:56 -0700
Received: by winservr.boi.hp.com with NT SMTP Gateway ver 31
	id <[e-mail]>; Sat, 17 Feb 96 18:16:54 M
Sender:[e-mail]
From: Binnur Al-Kazily <[e-mail]>
To: dmtf-info <[e-mail]>, 
    dmtf-info_request <[e-mail]>, 
    pmi <[e-mail]>, tfrye <[e-mail]>
Cc: kkeller <[e-mail]>, lmartinez <[e-mail]>
Subject: RE: Desktop Management Task Force (DMTF)
Date: Sat, 17 Feb 96 18:01:00 M
Message-Id: <[e-mail]>
Encoding: 48 TEXT
X-Mailer: Microsoft Mail V3.0


You can get a copy of Printer MIF at:

   ftp://ftp-out.external.hp.com/snmpmib/prtmif/prtmif84.txt

 ---
Binnur Al-Kazily  Hewlett-Packard Company Integrated Network Solutions
[e-mail]       [phone]           KB7YWD    DoD #2010


 ----------
From:  tfrye[SMTP:[e-mail]]
Sent:  Wednesday, February 14, 1996 4:10 PM
To:  dmtf-info; dmtf-info_request; pmi
Cc:  lmartinez; kkeller; tfrye
Subject:  Desktop Management Task Force (DMTF)


NEC Technologies will be supporting the emerging industry standards for
network print management.  These standards are based around the IEEE
P1284.3  standards.  We would like more information on the Desktop
Management Task Force (DMTF) and the Network Printing Alliance (NPA).

Would you please send me information about the DMTF and NPA, or at least,
send me the correct email address for information?  Your cooperation in
this matter is greatly appreciated.  Thank you in advance for your help!

                                                        Tom Frye

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/  
_/_/
_/   
                                                                         _  
/
_/                               [e-mail]   
                      _/
_/   
                                                                         _  
/
_/ Tom Frye at NEC Technologies, Laser Printer Division, Mountain View,   
CA  _/
_/   
                                                                         _  
/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/  
_/_/










To: [e-mail]
Subject: Output from "cron" command
Date: Sat, 17 Feb 96 20:18:25 EST
From: [e-mail]
Sender: [e-mail]
Message-ID:  <[e-mail]>

Your "cron" job

/home/ietf/BIN/mirror_nic.nordu.net;

produced the following output:


package=ietf nic.nordu.net:/aux/dbs/gopher/data/ftp/ietf -> /ftp/ietf/
ftp timeout set to 40
Connecting to nic.nordu.net
220 nic.nordu.net FTP server (Version wu-2.4(1) Wed Sep 6 11:42:51 MET DST 1995) ready.
login as ietf
---> USER ietf
331 Password required for ietf.
---> PASS <somestring>
230 User ietf logged in.
---> REST 0
350 Restarting at 0. Send STORE or RETRIEVE to initiate transfer.
---> TYPE I
200 Type set to I.
---> HELP SITE
214-The following SITE commands are recognized (* =>'s unimplemented).
   IDLE    HELP    GPASS   MINFO   EXEC    CDPATH 
Scanning local directory /ftp/ietf/
Scanning remote directory /aux/dbs/gopher/data/ftp/ietf
---> CWD /aux/dbs/gopher/data/ftp/ietf
214 Direct comments to [e-mail].
250 CWD command successful.
---> TYPE A
200 Type set to A.
---> PORT 132,151,1,35,13,235
200 PORT command successful.
---> LIST -lRat
150 Opening ASCII mode data connection for /bin/ls.
226 Transfer complete.
---> TYPE I
200 Type set to I.
compare directories for xfer
put file 0mtg-agenda.txt as 0mtg-agenda.txt
put file 1rfc_index.txt as 1rfc_index.txt
put file 1wg-charters-by-acronym.txt as 1wg-charters-by-acronym.txt
put file 1wg-charters.txt as 1wg-charters.txt
put file 1wg-summary-by-acronym.txt as 1wg-summary-by-acronym.txt
put file 1wg-summary.txt as 1wg-summary.txt
put file uswg/uswg-charter.txt as uswg/uswg-charter.txt
put file ipatm/ipatm-charter.txt as ipatm/ipatm-charter.txt
put file ipngwg/ipngwg-charter.txt as ipngwg/ipngwg-charter.txt
Need to put file 0mtg-agenda.txt as 0mtg-agenda.txt (x)
---> PORT 132,151,1,35,13,242
200 PORT command successful.
---> STOR .in.0mtg-agenda.txt.
150 Opening BINARY mode data connection for .in.0mtg-agenda.txt..
226 Transfer complete.
---> RNFR .in.0mtg-agenda.txt.
350 File exists, ready for destination name
---> RNTO 0mtg-agenda.txt
250 RNTO command successful.
Need to put file 1rfc_index.txt as 1rfc_index.txt (x)
---> PORT 132,151,1,35,13,243
200 PORT command successful.
---> STOR .in.1rfc_index.txt.
150 Opening BINARY mode data connection for .in.1rfc_index.txt..
226 Transfer complete.
---> RNFR .in.1rfc_index.txt.
350 File exists, ready for destination name
---> RNTO 1rfc_index.txt
250 RNTO command successful.
Need to put file 1wg-charters-by-acronym.txt as 1wg-charters-by-acronym.txt (x)
---> PORT 132,151,1,35,13,244
200 PORT command successful.
---> STOR .in.1wg-charters-by-acronym.txt.
150 Opening BINARY mode data connection for .in.1wg-charters-by-acronym.txt..
226 Transfer complete.
---> RNFR .in.1wg-charters-by-acronym.txt.
350 File exists, ready for destination name
---> RNTO 1wg-charters-by-acronym.txt
250 RNTO command successful.
Need to put file 1wg-charters.txt as 1wg-charters.txt (x)
---> PORT 132,151,1,35,13,248
200 PORT command successful.
---> STOR .in.1wg-charters.txt.
150 Opening BINARY mode data connection for .in.1wg-charters.txt..
226 Transfer complete.
---> RNFR .in.1wg-charters.txt.
350 File exists, ready for destination name
---> RNTO 1wg-charters.txt
250 RNTO command successful.
Need to put file 1wg-summary-by-acronym.txt as 1wg-summary-by-acronym.txt (x)
---> PORT 132,151,1,35,13,253
200 PORT command successful.
---> STOR .in.1wg-summary-by-acronym.txt.
150 Opening BINARY mode data connection for .in.1wg-summary-by-acronym.txt..
226 Transfer complete.
---> RNFR .in.1wg-summary-by-acronym.txt.
350 File exists, ready for destination name
---> RNTO 1wg-summary-by-acronym.txt
250 RNTO command successful.
Need to put file 1wg-summary.txt as 1wg-summary.txt (x)
---> PORT 132,151,1,35,13,255
200 PORT command successful.
---> STOR .in.1wg-summary.txt.
150 Opening BINARY mode data connection for .in.1wg-summary.txt..
226 Transfer complete.
---> RNFR .in.1wg-summary.txt.
350 File exists, ready for destination name
---> RNTO 1wg-summary.txt
250 RNTO command successful.
Need to put file uswg/uswg-charter.txt as uswg/uswg-charter.txt (x)
---> PWD
257 "/aux/dbs/gopher/data/ftp/ietf" is current directory.
---> CWD uswg/
250 CWD command successful.
---> CWD /aux/dbs/gopher/data/ftp/ietf
250 CWD command successful.
---> PORT 132,151,1,35,14,0
200 PORT command successful.
---> STOR uswg/.in.uswg-charter.txt.
150 Opening BINARY mode data connection for uswg/.in.uswg-charter.txt..
226 Transfer complete.
---> RNFR uswg/.in.uswg-charter.txt.
350 File exists, ready for destination name
---> RNTO uswg/uswg-charter.txt
250 RNTO command successful.
Need to put file ipatm/ipatm-charter.txt as ipatm/ipatm-charter.txt (x)
---> PWD
257 "/aux/dbs/gopher/data/ftp/ietf" is current directory.
---> CWD ipatm/
250 CWD command successful.
---> CWD /aux/dbs/gopher/data/ftp/ietf
250 CWD command successful.
---> PORT 132,151,1,35,14,1
200 PORT command successful.
---> STOR ipatm/.in.ipatm-charter.txt.
150 Opening BINARY mode data connection for ipatm/.in.ipatm-charter.txt..
226 Transfer complete.
---> RNFR ipatm/.in.ipatm-charter.txt.
350 File exists, ready for destination name
---> RNTO ipatm/ipatm-charter.txt
250 RNTO command successful.
Need to put file ipngwg/ipngwg-charter.txt as ipngwg/ipngwg-charter.txt (x)
---> PWD
257 "/aux/dbs/gopher/data/ftp/ietf" is current directory.
---> CWD ipngwg/
250 CWD command successful.
---> CWD /aux/dbs/gopher/data/ftp/ietf
250 CWD command successful.
---> PORT 132,151,1,35,14,4
200 PORT command successful.
---> STOR ipngwg/.in.ipngwg-charter.txt.
150 Opening BINARY mode data connection for ipngwg/.in.ipngwg-charter.txt..
226 Transfer complete.
---> RNFR ipngwg/.in.ipngwg-charter.txt.
350 File exists, ready for destination name
---> RNTO ipngwg/ipngwg-charter.txt
250 RNTO command successful.

package=iesg nic.nordu.net:/aux/dbs/gopher/data/ftp/iesg -> /ftp/iesg/
ftp timeout set to 40
Already connected to site nic.nordu.net
Scanning local directory /ftp/iesg/
Scanning remote directory /aux/dbs/gopher/data/ftp/iesg
---> CWD /aux/dbs/gopher/data/ftp/iesg
250 CWD command successful.
---> TYPE A
200 Type set to A.
---> PORT 132,151,1,35,14,6
200 PORT command successful.
---> LIST -lRat
150 Opening ASCII mode data connection for /bin/ls.
226 Transfer complete.
---> TYPE I
200 Type set to I.
compare directories for xfer
put file 1protocol_actions.txt as 1protocol_actions.txt
put file 1old_standards.txt as 1old_standards.txt
put file 1wg_actions.txt as 1wg_actions.txt
put file 1rfc_index.txt as 1rfc_index.txt
Need to put file 1protocol_actions.txt as 1protocol_actions.txt (x)
---> PORT 132,151,1,35,14,7
200 PORT command successful.
---> STOR .in.1protocol_actions.txt.
150 Opening BINARY mode data connection for .in.1protocol_actions.txt..
226 Transfer complete.
---> RNFR .in.1protocol_actions.txt.
350 File exists, ready for destination name
---> RNTO 1protocol_actions.txt
250 RNTO command successful.
Need to put file 1old_standards.txt as 1old_standards.txt (x)
---> PORT 132,151,1,35,14,8
200 PORT command successful.
---> STOR .in.1old_standards.txt.
150 Opening BINARY mode data connection for .in.1old_standards.txt..
226 Transfer complete.
---> RNFR .in.1old_standards.txt.
350 File exists, ready for destination name
---> RNTO 1old_standards.txt
250 RNTO command successful.
Need to put file 1wg_actions.txt as 1wg_actions.txt (x)
---> PORT 132,151,1,35,14,9
200 PORT command successful.
---> STOR .in.1wg_actions.txt.
150 Opening BINARY mode data connection for .in.1wg_actions.txt..
226 Transfer complete.
---> RNFR .in.1wg_actions.txt.
350 File exists, ready for destination name
---> RNTO 1wg_actions.txt
250 RNTO command successful.
Need to put file 1rfc_index.txt as 1rfc_index.txt (x)
---> PORT 132,151,1,35,14,12
200 PORT command successful.
---> STOR .in.1rfc_index.txt.
150 Opening BINARY mode data connection for .in.1rfc_index.txt..
226 Transfer complete.
---> RNFR .in.1rfc_index.txt.
350 File exists, ready for destination name
---> RNTO 1rfc_index.txt
250 RNTO command successful.

package=internet-drafts nic.nordu.net:/aux/dbs/gopher/data/ftp/internet-drafts -> /ftp/internet-drafts/
ftp timeout set to 40
Already connected to site nic.nordu.net
Scanning local directory /ftp/internet-drafts/
Scanning remote directory /aux/dbs/gopher/data/ftp/internet-drafts
---> CWD /aux/dbs/gopher/data/ftp/internet-drafts
250 CWD command successful.
---> TYPE A
200 Type set to A.
---> PORT 132,151,1,35,14,15
200 PORT command successful.
---> LIST -lRat
150 Opening ASCII mode data connection for /bin/ls.
226 Transfer complete.
---> TYPE I
200 Type set to I.
compare directories for xfer
put file 1id-abstracts.txt as 1id-abstracts.txt
put file 1id-index.txt as 1id-index.txt
Cannot create symlinks on remote systems (1id-guidelines.txt -> ../ietf/1id-guidelines.txt)
Need to put file 1id-abstracts.txt as 1id-abstracts.txt (x)
---> PORT 132,151,1,35,14,18
200 PORT command successful.
---> STOR .in.1id-abstracts.txt.
150 Opening BINARY mode data connection for .in.1id-abstracts.txt..
226 Transfer complete.
---> RNFR .in.1id-abstracts.txt.
350 File exists, ready for destination name
---> RNTO 1id-abstracts.txt
250 RNTO command successful.
Need to put file 1id-index.txt as 1id-index.txt (x)
---> PORT 132,151,1,35,14,19
200 PORT command successful.
---> STOR .in.1id-index.txt.
150 Opening BINARY mode data connection for .in.1id-index.txt..
226 Transfer complete.
---> RNFR .in.1id-index.txt.
350 File exists, ready for destination name
---> RNTO 1id-index.txt
250 RNTO command successful.
disconnecting from nic.nordu.net
---> QUIT
221 Goodbye.
All done, Exiting








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06379;
          17 Feb 96 22:07 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06375;
          17 Feb 96 22:07 EST
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa11888;
          17 Feb 96 22:07 EST
Received: from localhost by reef.bucknell.edu with SMTP
	(5.65/IDA-1.2.8) id AA06416; Sat, 17 Feb 1996 22:04:36 -0500
Date: Sat, 17 Feb 1996 22:04:36 -0500
Message-Id: <v02120d24ad4b78f97454@[134.82.7.154]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Originator: [e-mail]
X-Orig-Sender: [e-mail]
Precedence: bulk
Sender:[e-mail]
From: Ralph Droms <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Re: A counter-proposal for option 127
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

At 1:55 PM 2/15/96, David Lapp wrote:
>I just took a look at the new IDs for DHCP (Authentication,
>FQDN, and option 127). My compliments on their brevity :-)

Thanks...

>I have a question and perhaps a suggestion for the option 127
>doc.

You and Shawn both discovered the same problem.  See below.

At 1:52 PM 2/15/96, Shawn Mamros wrote:
>I have a problem with the way it's defined, because it violates the
>single-byte option code followed by single-byte length field that
>we've been following to date,

Thanks to both of you for picking up the deviation from the format of the
other options.

>If our esteemed WG chair is willing to entertain a counter-proposal,
>here it is...

Gratuitous flattery aside :-), I think both of you suggested essentially
the same format for option 127; so, it must be the right thing to do.  I
must admit to being appalled at the prospect of 2^16 more options (and the
RFCs needed to define those options!), but I can live with a two-octet
subcode.

There is one difference between your two proposals: Dave suggests wrapping
multiple extended subcodes in one instance of option 127, while Shawn
suggests encoding each subcode option separately.  In the interests of
simplicity, I'd lean towards encoding each separately, but either way is
OK.

How about (from Shawn's message):

    Code   Len     Option      Data...
   +-----+-----+-----+-----+-----+-----+----
   | 127 |  n  |  oh |  ol |  d1 |  d2 | ...
   +-----+-----+-----+-----+-----+-----+----

where "oh" is the high-order byte of the two-byte extended option code,
and "ol" is the low-order byte.  The length "n" must include the two bytes
of the extended option code itself.

- Ralph










Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00464;
          17 Feb 96 23:22 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07182;
          17 Feb 96 23:22 EST
Date:     Sat, 17 Feb 96 23:22:09 EST
From:     "IETF.CNRI.Reston.VA.US Mail System" (MMDF) <[e-mail]>
Sender:   [e-mail]
Subject:  Failed mail  (msg.aa11588)
To:       [e-mail]
Message-ID:  <[e-mail]>

    Your message could not be delivered to
'[e-mail] (host: ebone.net) (queue: smtpns)' for the following
reason:  ' <[e-mail]>... User unknown'


    Your message follows:

Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11588;
          17 Feb 96 22:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12282;
          17 Feb 96 22:56 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11583;
          17 Feb 96 22:56 EST
To: [e-mail]
Subject: shadow directories
Date: Sat, 17 Feb 96 22:56:31 -0500
From: IETF Administrative User <[e-mail]>
Message-ID:  <[e-mail]>

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/internet-drafts/1id-abstracts.txt
   /ftp/internet-drafts/1id-index.txt
   /ftp/iesg/1old_standards.txt
   /ftp/iesg/1protocol_actions.txt
   /ftp/iesg/1rfc_index.txt
   /ftp/iesg/1wg_actions.txt








To: [e-mail]
Subject: Output from "cron" command
Date: Sat, 17 Feb 96 23:53:12 EST
From: [e-mail]
Sender: [e-mail]
Message-ID:  <[e-mail]>

Your "cron" job

(cd /home/ietf/MAILING-LISTS/ietf_list; ../make_lists_mx ../ietf 10 ietf_sub ietf list;)

produced the following output:

/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
Now sorting the address list, please wait...
Now creating the address files...








To: [e-mail]
Subject: Output from "cron" command
Date: Sat, 17 Feb 96 23:59:22 EST
From: [e-mail]
Sender: [e-mail]
Message-ID:  <[e-mail]>

Your "cron" job

(cd /home/ietf/MAILING-LISTS/ietf_list_123; ../make_lists_mx ../ietf-123 10 ietf_123_sub ietf-123 privlist;)

produced the following output:

/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
Now sorting the address list, please wait...
Now creating the address files...








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id ab05505;
          17 Feb 96 23:59 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05501;
          17 Feb 96 23:59 EST
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa29260;
          17 Feb 96 23:59 EST
Received: from localhost by reef.bucknell.edu with SMTP
	(5.65/IDA-1.2.8) id AA10491; Sat, 17 Feb 1996 23:55:18 -0500
Date: Sat, 17 Feb 1996 23:55:18 -0500
Message-Id: <01BAFD70.3A562AC0@parker1>
Errors-To: [e-mail]
Reply-To: [e-mail]
Originator: [e-mail]
X-Orig-Sender: [e-mail]
Precedence: bulk
Sender:[e-mail]
From: "Charles M. Francis" <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

subscribe [e-mail]









Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11432;
          18 Feb 96 11:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11428;
          18 Feb 96 11:26 EST
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa19105;
          18 Feb 96 11:26 EST
Received: from localhost by reef.bucknell.edu with SMTP
	(5.65/IDA-1.2.8) id AA28967; Sun, 18 Feb 1996 11:23:17 -0500
Date: Sun, 18 Feb 1996 11:23:17 -0500
Message-Id: <v02120d3aad4cf102bc0b@[134.82.7.154]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Originator: [e-mail]
X-Orig-Sender: [e-mail]
Precedence: bulk
Sender:[e-mail]
From: Ralph Droms <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Sessions in LA
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

We have two sessions scheduled for Tuesday, 3/5.  The morning session will
foucs on DHCPv4 and the evening session on DHCPv6.  The agendas for the two
meetings are:

DHCPv4:

     (New I-Ds)
        Option approval process
        Reservation of option 127 as a prefix for two-octet option codes
        The FQDN option code
        DHCP-DNS interaction
        Authentication and verification of DHCP messages
        Renumbering

     (Not yet an I-D)
        Server-server protocol

DHCPv6:

        Protocol spec I-D
        Options spec I-D

Please let me know if you have anything else you'd like to get on the agenda.

- Ralph











Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11998;
          18 Feb 96 12:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11994;
          18 Feb 96 12:34 EST
Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa15158;
          18 Feb 96 12:34 EST
Received: by mx2.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA24297;
	Sun, 18 Feb 96 08:55:28 -0800
Errors-To: [e-mail]
X-Orig-Sender: [e-mail]
Received: from mailhost1.cac.washington.edu by mx2.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA24291;
	Sun, 18 Feb 96 08:55:26 -0800
Received: from shiva1.cac.washington.edu by mailhost1.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA22940;
	Sun, 18 Feb 96 08:55:25 -0800
Date: Sun, 18 Feb 1996 08:55:24 -0800 (PST)
Sender:[e-mail]
From: Terry Gray <[e-mail]>
To: [e-mail]
Subject: Re: UID EXPUNGE
Message-Id: <[e-mail]>
Organization: University of Washington; Office of Computing & Communications
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Folks,
First a Meta-comment, reiterating Mark's point that time is of the
essence:

   We need to reach closure on this (and the other changes already
   incorporated in the new draft) ASAP.  It would be enormously
   valuable to be able to ask the IESG to act on the new base draft
   at the upcoming IETF, just a couple of weeks hence.  As of March,
   John Klensin is retiring from Area-Directorship, and with him goes
   a lot of corporate history on the IMAP project, and someone with
   enormous credibility who can help us move this forward quickly...
   Provided we can get consensus among ourselves.

Regarding UID EXPUNGE, I don't have anything to say that hasn't already
been said, but I'd like to gather together what I consider to be some of
the most important points previously made.  I'm going to use the term
"selective expunge" for this proposed functionality, since it seems
descriptive.

It's too late to argue about the following; these are deeply engrained
characteristics of IMAP:

 o \DELETED is a permanent flag (it persists across sessions)
 o \DELETED is a global, not a private (per-user), flag
 o In practice, EXPUNGE is not an invisible housekeeping operation
 o We can't pretend that marking \DEL and expunging are atomic
 o Users will expect to be able to initiate expunging in their own folders
 o Users *should* expect expunging initiated elsewhere in shared folders

The question at hand: Is some form of "selective expunge" worthwhile?

I'm going to postulate that the proposed function would only affect
messages that were marked \DELETED, because (a) to do othewise seems like
a significant and inconsistent departure from previous IMAP philosophy,
and (b) John was not opposed to this variation on the proposal.

In order to try to answer the "Is it worthwhile?" question, I think it
would be useful to separate the discussion into two contexts (private
folders and shared folders) and compare selective vs. non-selective
expunging for disconnected users.

 o In a private folder case: imagine a scenario where there are msgs
   on the server marked deleted that are *not* in the client cache.
   Probably a rare case, but it could happen.  The issue is whether
   it is important to be able to leave some \DELETED messages untouched
   after re-connecting and replaying state changes and an expunge.
   I would have guessed that it was OK to have all the \DELETEDs go away.
   (Even in the online case, I often lose track of what all I've marked
   deleted from one session to the next, or before and after being
   interrupted in one session, and it doesn't bother me that they *all* go
   away when I expunge.)

 o Disconnected operation in a shared folder environment: selective
   expunge comes up against the reality that (a) a listed message may
   already be gone (OK, so what?), and (b) a listed message might
   get undeleted by someone else between the replay of the deleted and
   the selective expunge.  Conversely, both the current expunge and
   proposed selective expunge could make messages go poof that someone
   else was still looking at... Well, life in a shared environment is
   uncertain anyway, so again, I'm not sure that selective expunge is a
   very big win.


Conclusion: I think I come down on the side of "It's probably not worth
doing a selective expunge."  But I also don't think it would be a tragedy
to have one (provided it only affected messages marked \DELETED.) In some
ways I think the unselective expunge could be less surprising and easier
to explain to users, but that depends on how the disconnected client
handles it.

However, my main goal is to *promptly* reach closure one way or the
other...

My sense is that the group is divided, with maybe a little bit more
sentiment for "don't bother"  --but I didn't go back and count.
I suspect we'd all agree that in the absence of a clear consensus
about including a new feature, the default should be to punt.

But I value fairness above most other process values, so I'm going to
propose the following: now that we've had a reasonable airing of the
issues pro and con, could we have a quick straw poll with messages of the
form "Subject: UID EXPUNGE: yes" or "UID EXPUNGE: no"?   We can assume
that Mark and John's votes will counteract, so they don't need to play :)

(I know we don't believe in voting, but I'm not sure how else to fairly
converge on a decision to include/exclude from the new draft.)

I think we should try to close on *this* issue by Tuesday, and have one
more day to entertain any other objections to the new draft.  In a perfect
world, it would be great if we could forward the draft to the IESG on
Thurs or Friday of this coming week.

-teg










Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15050;
          18 Feb 96 17:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15046;
          18 Feb 96 17:47 EST
Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa06252;
          18 Feb 96 17:47 EST
Received: by mx2.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA28505;
	Sun, 18 Feb 96 14:15:11 -0800
Errors-To: [e-mail]
X-Orig-Sender: [e-mail]
Received: from mercury.Sun.COM by mx2.cac.washington.edu
	(5.65+UW96.01/UW-NDC Revision: 2.33 ) id AA28499;
	Sun, 18 Feb 96 14:15:04 -0800
Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM)
	id OAA23031; Sun, 18 Feb 1996 14:15:03 -0800
Received: from hape.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3)
	id AA11227; Sun, 18 Feb 1996 14:15:02 -0800
Received: from yao by hape.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA06143; Sun, 18 Feb 1996 14:14:59 -0800
Date: Sun, 18 Feb 1996 14:14:14 -0800 (PST)
Sender:[e-mail]
From: Chez moi <[e-mail]>
Reply-To: Chez moi <[e-mail]>
Subject: UID EXPUNGE: no
To: Terry Gray <[e-mail]>
Cc: [e-mail]
In-Reply-To: "Your message with ID" <[e-mail]>
Message-Id: <Roam.3.0.824681654.1016.yeager@roam>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII









Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16487;
          18 Feb 96 20:18 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16483;
          18 Feb 96 20:18 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa24123;
          18 Feb 96 20:18 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA23672 for uri-out; Sun, 18 Feb 1996 20:03:29 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA23667 for <[e-mail]>; Sun, 18 Feb 1996 20:03:23 -0500
Received: from ebt-inc.ebt.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA05993  (mail destined for [e-mail]); Sun, 18 Feb 96 20:03:17 -0500
Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.12/8.6.9) id UAA09669; Sun, 18 Feb 1996 20:01:09 -0500
Date: Sun, 18 Feb 1996 20:01:09 -0500
Sender:[e-mail]
From: Gavin Nicol <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]> (message from Masataka Ohta on Fri, 16 Feb 96 18:30:24 JST)
Subject: Re: http charset labelling
X-Orig-Sender: [e-mail]
Precedence: bulk

>> To me it means that the URL is hidden and can be anything so it
>> does not matter then if it is encoded in a special charset or not.
> 
>On browsers, yes, it is hidden. So, it is meaningless to use
>a special charset.

The point is that if I receive a URL, by whatever means, and then I
type it into the "go to" field of any browser, then when it is sent to
the server, the server has no idea what encoding is being used.

The actual indication of the encoding should be hidden from the user,
but it is still important for it to be there, because even for ASCII
names, maybe the user entered it in zenkaku.









Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16976;
          18 Feb 96 21:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16971;
          18 Feb 96 21:08 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa18005;
          18 Feb 96 21:08 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA24179 for uri-out; Sun, 18 Feb 1996 20:46:33 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA24174 for <[e-mail]>; Sun, 18 Feb 1996 20:46:31 -0500
Received: from [163.138.25.11] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA06100  (mail destined for [e-mail]); Sun, 18 Feb 96 20:46:27 -0500
Received: by cactus.slab.ntt.jp (4.1/core*slab.mx8+)
	id AA22835; Mon, 19 Feb 96 10:46:04 JST
Date: Mon, 19 Feb 96 10:46:04 JST
Sender:[e-mail]
From: Paul Francis <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Ingrid ready for initial testing...
X-Orig-Sender: [e-mail]
Precedence: bulk


Apologies in advance for the cross-posting, (and for the
length of this message) but...

I am pleased to finally be able to announce that we will
begin preliminary testing of Ingrid software.   We are
looking for a small group of volunteers.


What Ingrid Is:

For those of you who haven't followed Ingrid, it is a
technique for whole-web searching that doesn't require
a central search database.  Instead, it automatically
generates links between similar web resources, resulting
in an infrastructure that can be (we hope) efficiently searched
robot-style (at search time).  While it is certain to have
disadvantages to central search databases, one advantage
we hope it has is that it pushes the control over searching
to the edges (publishers and navigators).  Anyway, please
see http://rodem.slab.ntt.jp:8080/home/index-e.html for
more info (please don't imagine that the quality of our
home-page is a reflection on the quality of our software :-)



What We Have:

We have early versions of software that:

1.  Publisher:  Finds (using a robot) and processes text resources
    (isolates words, selects high-weight terms, etc.) in English and
    Japanese (please contact us if you want to add your favorite
    language...character set is not a restriction).

2.  Server:  Inserts the processed text into a global linked
    infrastructure, and then answers queries about that text and text
    that it is linked to.

3.  Navigator:  Allows users to search/navigate that infrastructure
    using a robot/GUI navigator running on their own workstation.  This
    navigator has some nice relevance feedback features you don't
    find on current web search engines (that I'm familiar with).
    The navigator can also be coupled with your browser.

The Publisher is in Perl.  The Server is in C, and the Navigator is
in C and uses Motif.  We are running on Sun OS4 and Solaris.  All
interactions take place using UDP packets with a high port number.
(This software, by the way, will all be freely available.)


What We Want To Do:

Starting around the end of this month, we want to start building the
infrastructure.  The primary purposes are:

1.  to try to find out how well it scales,
2.  to flush out bugs, installation procedures, etc.,
3.  to learn what kind of features we should add to the navigator.


Who We Are Looking For:

On the publishing side, we need voluteers that:

1.  Are willing to spend a bit of time with this.  While we are trying
    to make this all as simple as possible, you will have to spend
    some time at installation, check to see that things are working
    properly, and so on.  Also, we expect there to be frequent
    re-installs early on, for bug fixes etc.

2.  Have a machine that is continuously internet-accessible and has
    some spare memory/CPU/bandwidth.  (Just how much we don't know...that
    is part of what we want to learn.  It should, however, be negligible
    compared to running a web server.)

3.  Ideally (though not absolutely necessary) you should have a set of
    resources that you yourself would like to be able to search (and
    that you would like others to be able to search).  In particular, we
    are able to loosely couple Ingrid with other local search engines in
    that our search result not only finds resources for you, but points
    you to search engines that contain those resources so that you can do
    additional searching.  Also, if you've already installed Harvest, our
    software can use your Harvest configuration files, so you don't have
    to do it again.

    I would say that our ideal first "customer" is someone that has already
    installed multiple Harvest (or similar) databases, and would like to
    see those databases coupled in some nice way.  It is ideal because
    such a person gets some immediate personal benefit from using Ingrid.



What You Should Do:

Please send me mail ([e-mail]) if you are interested in
participating.  (Do so even if you want to postpone your participation
till we have something more solid.)  We can then discuss particulars.


Thanks,

PF








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17911;
          18 Feb 96 22:02 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17855;
          18 Feb 96 22:02 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa06826;
          18 Feb 96 22:02 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA24725 for uri-out; Sun, 18 Feb 1996 21:37:33 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA24720 for <[e-mail]>; Sun, 18 Feb 1996 21:37:30 -0500
Received: from necom830.cc.titech.ac.jp by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA06202  (mail destined for [e-mail]); Sun, 18 Feb 96 21:37:25 -0500
Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Mon, 19 Feb 1996 11:28:06 +0900
Sender:[e-mail]
From: Masataka Ohta <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: http charset labelling
To: Gavin Nicol <[e-mail]>
Date: Mon, 19 Feb 96 11:28:05 JST
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>; from "Gavin Nicol" at Feb 18, 96 8:01 pm
X-Mailer: ELM [version 2.3 PL11]
X-Orig-Sender: [e-mail]
Precedence: bulk

Gavin;

> The actual indication of the encoding should be hidden from the user,
> but it is still important for it to be there,

Could you please remember that, because of duplicated encoding,
character code itself is necessary?

I already stated so more than 3 times.

> because even for ASCII
> names, maybe the user entered it in zenkaku.

Another good example of duplicated encoding. But you misunderstand how
Japanese encoding is.

With RFC 1468 ISO-2022-JP encoding, character 'A' may be represented
with ASCII, JIS X 0201 or JIS X 0208.

But, there is nothing like "zenkaku". It's a display property and
have nothing to do with encoding (though brain-deadly broken Unicode
OPTIONALLY allow to encode some display property, which should properly
belongs to the HTML).

The character 'A', latin capital letter 'A', in both ASCII, JIS X 0201
and JIS X 0208, without any ambiguity, have the same name of "LATIN
CAPITAL LETTER A".

That is, as URL is ASCII only, even if JIS X 0201 or JIS X 0208 'A'
is entered through ISO-2022-JP encoding, an ASCII code of "LATIN
CAPITAL LETTER A" must be sent.

Finally, with ISO-2022-JP encoding, you can put a lot of necessary and
redundant escape sequences. The sequences are totally invisible.
So, how can you figure out the corrent number of escape sequences
are?

						Masataka Ohta








Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23472;
          18 Feb 96 23:01 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26984;
          18 Feb 96 23:01 EST
Date:     Sun, 18 Feb 96 23:01:02 EST
From:     "IETF.CNRI.Reston.VA.US Mail System" (MMDF) <[e-mail]>
Sender:   [e-mail]
Subject:  Failed mail  (msg.aa23368)
To:       [e-mail]
Message-ID:  <[e-mail]>

    Your message could not be delivered to
'[e-mail] (host: ebone.net) (queue: smtpns)' for the following
reason:  ' <[e-mail]>... User unknown'


    Your message follows:

Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23368;
          18 Feb 96 22:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25154;
          18 Feb 96 22:56 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa23363;
          18 Feb 96 22:56 EST
To: [e-mail]
Subject: shadow directories
Date: Sun, 18 Feb 96 22:56:02 -0500
From: IETF Administrative User <[e-mail]>
Message-ID:  <[e-mail]>

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/internet-drafts/1id-abstracts.txt
   /ftp/internet-drafts/1id-index.txt
   /ftp/internet-drafts/draft-dckmtr-proxy-00.txt
   /ftp/internet-drafts/draft-flick-interfaces-mib-00.txt
   /ftp/internet-drafts/draft-flick-repeater-dev-mib-00.txt
   /ftp/internet-drafts/draft-ietf-idmr-pim-arch-01.txt
   /ftp/internet-drafts/draft-ietf-mhsds-infotree-06.txt
   /ftp/internet-drafts/draft-ietf-mhsds-subtrees-06.txt
   /ftp/internet-drafts/draft-ietf-mhsds-supmapping-06.txt
   /ftp/internet-drafts/draft-ietf-sdr-erp-01.txt
   /ftp/internet-drafts/draft-ietf-snmp-isdn-cisco-00.txt
   /ftp/internet-drafts/draft-ietf-uri-urn-madsen-critique-00.txt
   /ftp/internet-drafts/draft-kastenholz-loki-00.txt
   /ftp/internet-drafts/draft-mcdonald-ipv6-sec-api-00.txt
   /ftp/internet-drafts/draft-metzger-ah-sha-00.txt
   /ftp/internet-drafts/draft-robinson-games-overview-00.txt
   /ftp/internet-drafts/draft-robinson-newtelex-01.txt
   /ftp/internet-drafts/draft-simpson-ipv6-discov-formats-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 aa01122;
          18 Feb 96 23:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01117;
          18 Feb 96 23:41 EST
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa18987;
          18 Feb 96 23:41 EST
Received: from localhost by reef.bucknell.edu with SMTP
	(5.65/IDA-1.2.8) id AA04037; Sun, 18 Feb 1996 23:04:43 -0500
Date: Sun, 18 Feb 1996 23:04:43 -0500
Message-Id: <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Originator: [e-mail]
X-Orig-Sender: [e-mail]
Precedence: bulk
Sender:[e-mail]
From: David Lapp <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Re: A counter-proposal for option 127
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
X-Mailer: ELM [version 2.4 PL21]


.. stuff deleted
> 
> There is one difference between your two proposals: Dave suggests wrapping
> multiple extended subcodes in one instance of option 127, while Shawn
> suggests encoding each subcode option separately.  In the interests of
> simplicity, I'd lean towards encoding each separately, but either way is
> OK.
> 
> How about (from Shawn's message):
> 
>     Code   Len     Option      Data...
>    +-----+-----+-----+-----+-----+-----+----
>    | 127 |  n  |  oh |  ol |  d1 |  d2 | ...
>    +-----+-----+-----+-----+-----+-----+----
> 
I've got no strong feelings about putting multiple subcodes in
the wrapper. Shawn's suggestion sounds fine to me.

Dave L.








To: [e-mail]
Subject: Output from "cron" command
Date: Sun, 18 Feb 96 23:49:35 EST
From: [e-mail]
Sender: [e-mail]
Message-ID:  <[e-mail]>

Your "cron" job

(cd /home/ietf/MAILING-LISTS/ietf_list; ../make_lists_mx ../ietf 10 ietf_sub ietf list;)

produced the following output:

/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
Now sorting the address list, please wait...
Now creating the address files...








To: [e-mail]
Subject: Output from "cron" command
Date: Sun, 18 Feb 96 23:57:16 EST
From: [e-mail]
Sender: [e-mail]
Message-ID:  <[e-mail]>

Your "cron" job

(cd /home/ietf/MAILING-LISTS/ietf_list_123; ../make_lists_mx ../ietf-123 10 ietf_123_sub ietf-123 privlist;)

produced the following output:

/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The Nameserver had a failure.
/usr/local/bin/resolve: server was unable to answer this query because:
		The domain requested is unknown!
Now sorting the address list, please wait...
Now creating the address files...








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15150;
          19 Feb 96 9:38 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15146;
          19 Feb 96 9:38 EST
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa25551;
          19 Feb 96 9:38 EST
Received: from localhost by reef.bucknell.edu with SMTP
	(5.65/IDA-1.2.8) id AA27200; Mon, 19 Feb 1996 09:30:28 -0500
Date: Mon, 19 Feb 1996 09:30:28 -0500
Message-Id: <v02120d01ad4e3535a800@[134.82.18.89]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Originator: [e-mail]
X-Orig-Sender: [e-mail]
Precedence: bulk
Sender:[e-mail]
From: Ralph Droms <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Re: A counter-proposal for option 127
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

I've submitted draft-ietf-dhc-options-opt127-01.txt - a revision to the
definition of option 127 as an extended option code -  for publication as
an I-D.  The revised version is available now for anonymous ftp in
ftp://ftp.bucknell.edu/pub/dhcp.

Thanks to Shawn Mamros and Dave Lapp for their suggestions about improving
the definition of option 127...

- Ralph











Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15204;
          19 Feb 96 9:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15195;
          19 Feb 96 9:41 EST
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa27257;
          19 Feb 96 9:41 EST
Received: from localhost by reef.bucknell.edu with SMTP
	(5.65/IDA-1.2.8) id AA27305; Mon, 19 Feb 1996 09:31:56 -0500
Date: Mon, 19 Feb 1996 09:31:56 -0500
Message-Id: <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Originator: [e-mail]
X-Orig-Sender: [e-mail]
Precedence: bulk
Sender:[e-mail]
From: "Edie E. Gunter" <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Re: New I-Ds on ftp.bucknell.edu
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

   Sorry if this is a duplicate...the bucknell mailer bounced
	it back to me.


> 1.  What is the rationale for allowing both the client and server to
> 	initiate updates to the A RR record?  Is it simply for the
> 	client to get confirmation of the change?

Normally, one thinks of a client as owning its name.  This
ownership, then, suggests that it is more logical for the
client to perform name->IPaddress (A RR) updates.

There is also the more practical issue of mobility.  If a
user takes his PC to another site in another
town or country, that user will probably want a local IP
address, but will want to keep his same name.  In this
case, the user/client is more likely to know the DNS
server to which the A RR update should be sent than a DHCP
server in a far away place.

> 3.  Even if the suggested option is maintained, I'd still favor
> 	having the servers submit all updates as this simplifies the
> 	protocol specifications immensely by eliminating the need for
> 	the flag within the option and answering the first discussion
>	question as to whether a server can override the client.

I would disagree.  In particular, I think in a secure DNS,
having DHCP servers update A RRs would make management of
the KEY next to impossible for the case where a PC moves
among multiple domains.

> 4.  I'm unclear as to why one would include lease information within
>	DNS. < stuff deleted >

DNS needs to know the lease expiration so that it can ensure
that the A/PTR RR's expire when the DHCP lease expires.  On
renewal of a lease, a client and/or server will send updates
to DNS.  This will effectively extend the expiration of the RRs.

> 	It seems a simpler approach would be to require a packet be
>	sent to DNS whenever a lease expires or is released by the
>	client. <more stuff deleted>

Waiting until the lease expires isn't going to work in a secure
DNS.  The expiration of the A/PTR RR's must be set up when the
RR's are added/updated.  Making the expiration arbitrarily far
into the future, assuming you'll be told when a lease expires or
when it's been released doesn't seem like a good idea to me.

Edie










Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19037;
          19 Feb 96 11:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19033;
          19 Feb 96 11:57 EST
Received: from relay.hp.com by CNRI.Reston.VA.US id aa17524; 19 Feb 96 11:57 EST
Received: from hpdmd48.boi.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA143769004; Mon, 19 Feb 1996 08:56:44 -0800
Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.4 Openmail) id AA298248982; Mon, 19 Feb 1996 09:56:23 -0700
Received: from relay.hp.com by hpbs987.boi.hp.com with SMTP
	(1.37.109.4/15.5+IOS 3.12) id AA21737; Mon, 19 Feb 96 09:45:07 -0700
Received: from VNET.IBM.COM by relay.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.3) id AA142348871; Mon, 19 Feb 1996 08:54:31 -0800
Message-Id: <[e-mail]>
Received: from BLDVMB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9519;
   Mon, 19 Feb 96 11:50:09 EST
Date: Mon, 19 Feb 96 09:47:42 MST
Sender:[e-mail]
From: "Harry Lewis <[e-mail]>" <[e-mail]>
To: [e-mail]
Subject: SMIv2 vs v1

I've tried sending the printer MIB to both the following addresses which
are invalid. ([e-mail]; [e-mail]).
Does anyone have the correct address?

Also, would it be a worthwhile service to run the v2-to-v1 conversion and
store it on the PWG server, say as RFC1759A? I know we based the RFC on
SMIv2, but there are a lot of legacy v1 Network Managers out there which might
benifit.








Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22259;
          19 Feb 96 14:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22243;
          19 Feb 96 14:00 EST
Received: from relay.hp.com by CNRI.Reston.VA.US id aa22955; 19 Feb 96 14:00 EST
Received: from hpdmd48.boi.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA237516382; Mon, 19 Feb 1996 10:59:43 -0800
Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.4 Openmail) id AA289906359; Mon, 19 Feb 1996 11:59:19 -0700
Received: from relay.hp.com by hpbs987.boi.hp.com with SMTP
	(1.37.109.4/15.5+IOS 3.12) id AA26449; Mon, 19 Feb 96 11:47:57 -0700
Received: from mail.sharplabs.com ([204.75.175.200]) by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA235386232; Mon, 19 Feb 1996 10:57:12 -0800
Received: from sla5c by mail.sharplabs.com (SMI-8.6/SMI-SVR4)
	id KAA19543; Mon, 19 Feb 1996 10:48:50 -0800
Sender:[e-mail]
From: Randy Turner <[e-mail]>
Received: by sla5c (SMI-8.6) id KAA23585; Mon, 19 Feb 1996 10:48:46 -0800
Date: Mon, 19 Feb 1996 10:48:46 -0800
Message-Id: <199602191848.KAA23585@sla5c>
Subject: Re: Converting v2 mibs to v1
To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Md5: TnV/kGOiDqNF/JmAN0r/hA==


I sent this message to the folks at SNMP Research and this is the reply
I got....David also followed up his message by saying that the freely
available Mosy compiler in the ISODE distribution also supports this
option.

Randy




------------- Begin Forwarded Message -------------