(unknown charset) cc:Mail Link to SMTP Undeliverable Message

Message is undeliverable.
Reason: A platform specific error occurred while writing to a file.
	Likely disk full.
Original text follows:
---------------------

Received: from sb2inet2.dowjones.com by ccmail.dowjones.com (ccMail Link to SMTP R8.00.00)
	; Fri, 11 Jul 97 09:26:19 -0500
Return-Path: <http-wg-request@cuckoo.hpl.hp.com>
Received: by sb2inet2.dowjones.com; id JAA02958; Fri, 11 Jul 1997 09:20:43 -0400
Received: from palrel3.hp.com(156.153.255.219) by sb2inet2.sb2inet2.dowjones.com via smap (3.2)
	id xma002944; Fri, 11 Jul 97 09:20:41 -0400
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.62.116])
	by palrel3.hp.com (8.8.5/8.8.5) with ESMTP id GAA28155;
	Fri, 11 Jul 1997 06:24:15 -0700 (PDT)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.1/8.7.1) id JAA22052; Fri, 11 Jul 1997 09:23:30 -0400 (EDT)
Resent-Date: Fri, 11 Jul 1997 09:23:30 -0400 (EDT)
Message-Id: <3.0.1.32.19970711091753.00948460@name.net>
X-Sender: matt@name.net
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 11 Jul 1997 09:17:53 -0400
To: Yaron Goland <yarong@microsoft.com>
From: Matthew Rubenstein <ruby@name.net>
Subject: RE: LAST CALL, "HTTP State Management Mechanism (Rev1) " to
  Proposed Standard
Cc: "'Larry Masinter'" <masinter@parc.xerox.com>, http-wg@cuckoo.hpl.hp.com
In-Reply-To: <11352BDEEB92CF119F3F00805F14F48503187B2E@RED-44-MSG.dns.mi
 crosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"FD5MC.0.PO5.AFZnp"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3737
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

At 06:27 PM 7/10/97 -0700, Yaron Goland wrote:
>Declare it historic and forget about it. As for the new draft, no one
>seems interested in implementing it so why put an RFC on proposed track
>when it will never make it to draft status?

	We need a consistent spec for interoperable Cookies. The UAs and servers
implement them, and many applications rely on them. OPS is (will be) good
for profiles, but the majority of our state info is application
infrastructure, equally applicable to anonymous and ID'd users. Don't throw
the interop baby out with the bathwater.


>	Yaron
>
>> -----Original Message-----
>> From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
>> Sent:	Thursday, July 10, 1997 9:25 AM
>> To:	Yaron Goland
>> Cc:	http-wg@cuckoo.hpl.hp.com
>> Subject:	Re: LAST CALL, "HTTP State Management Mechanism (Rev1) "
>> to Proposed Standard
>> 
>> You have raised some (apparently new) objections to
>> moving "HTTP State Management Mechanism (Rev1)" to
>> Proposed Standard.
>> 
>> On the other hand, the working group has previously
>> issued RFC 2109, a Proposed Standard, which has serious
>> interoperability problems with currently deployed
>> software. (I assume you're familiar with this software).
>> 
>> So what do you recommend that we do? It seems intolerable
>> to have a Proposed Standard that we wouldn't actually
>> want to propose that people implement, and we should
>> move on this.
>> 
>> Withdraw 2109 (mark it Historical?) Document current
>> practice for cookies?
>> 
>> (If we proceed with this document, we should deal
>> with Yaron's comments on 4.2.2.)
>> 
>> Larry
>
>
>
--
Matthew Rubenstein                    North American Media Engines
Toronto, Ontario   *finger matt for public key*      (416)943-1010

			    Chess is for computers.