Re: APOP - authentication..

> Hi roy having a bad day?

Yes and No. I was informed by one of our co-Chairs that I needed to respond
to all proposals which I do not think should be anywhere near "acceptable"
status on our Issues list, no matter how obvious that unacceptability
should be to the WG, unless someone else beats me to it.  Since everyone
appears to be ignoring your proposals, that means I need to spend some
time explaining why they are bad ideas.  Normally, I'd let someone with
more time on their hands to do it.

> There are many reasons why your comments on authentication points, transfer
> codings etc are wrong..
> 
> authentication is used to bind a request to a user. This binding has many
> uses. In a chain of proxies/gateways, you cannot have a proxy take
> responsibility for a user.. The binding has to be back to the user
> directly.

A proxy's "user" is whoever decides that the proxy should handle the request.
Since only the first proxy is "used" by the UA-user, it is not appropriate
to authenticate that user from the other proxies.

> One of the goals is to NOT continually invent silmiliar but incompatible
> protocols. The dot stuffing mechanism is well understood, simple to implement
> and has stood the test of time.. The lack of canonical EOL's in http's 
> pseudo MIME text types makes it a bit more ugly than needed.

It is well understood to be a particularly stupid and content-destructive
and unreliable mechanism for delinineating the length of content.
It has most emphatically not stood the test of time.

> The chunking proposal states how the path is 8bit then goes on to use text
> numbers to represent length... well that is endian independent. A two or
> three byte header isn't as much an overhead.

When it was discussed on the WG list, the overwhelming majority wanted
an encoding that could be read via TELNET.  Analysis of the overhead
showed no significant difference between the two for typically-sized
dynamic output.  In any case, it is not desirable to require two
mechanisms for exactly the same purpose when there is no significant
difference between those mechanisms.

>> > This document describes a simple authentication scheme for http that uses
>> > the APOP mechanism as defined in RFC1725 Post Office Protocol - Version 3.
>> 
>> It appears to be a weak subset of the Digest authentication mechanism
>> already proposed and implemented on many HTTP systems.  I don't see
>> any reason why APOP can't be mapped into Digest and thus save the client
>> from having to know more AA schemes than are necessary.
> 
> Various digest proposals have been proposed as weak subsets of SHTTP..
> APOP is an existing standard. ...

for transfer of mail, yes.  So?  You still have to translate the APOP
authentication to an HTTP syntax.  All I am saying is that you might as
well translate it into the Digest syntax, since there is zero chance
of it being implemented in HTTP clients otherwise.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Tuesday, 20 February 1996 10:07:19 UTC