> >So please don't use ports other than 80 unless they are over 1024.
> >And browsers should warn users before sending sensitive information
> >(like userid/passwd in the clear) to ports other than 80.
>
> Did any methods of authenticaation get discusssed at the W^5?
Only a little bit. Not much new info.
> A few points/suggestions. Why are you having the encoding be included
> with every separate format? Wouldn't it make more sense to use the
> Accept-encoding field 3 or 4 times, like this:
> * Accept-encoding: archive/tar ; archive/gtar ; archive/shar
FYI: archive/tar isn't an encoding, it's a content-type.
This does raise the question of what does Accept-encoding mean and
how does it fit in with Content-transfer-encoding.
> Or am I misunderstanding part of the proposal? If you can accept one
> type of encoding, you should be able to accept it anywhere (ie: a
> uuencoded, compressed, tar file of 3 mac hqx files :)
I would say we should process the Accept: fields in order and use the
previous fields as defaults for the rest of the types. Does this
violate anyones sensibilities. The reason the client profile is
attached to the type itself is they could very well be different, e.g.:
Accept: image/gif; class=color; depth=8; xdpi=85; ydpi=85
Accept: application/postscript; depth=1; xdpi=600; ydpi=600
This might be because you plan on printing postscript but viewing gif's
Of course, this is a silly example because the server isn't going to do
anything with the postscript information but this gives you an idea of
why the data is per content-type. We discussed this at WWWWW and decided
to do it this way.
So my question is what the heck is Accept-encoding: for? Should it
be called Accept-transfer-encoding: and use the MIME transfer encodings
or what?
--sanders