John Panzer wrote:
> But as a client author I don't want to be told that I have to
> implement TLS
> to be compliant.
You don't. A SHOULD is not a MUST.
Fair enough, but I consider a SHOULD a strong recommendation and I'm still
not sure why you're wanting APP to make that recommendation.
I think Blogger has a respectable number of blogs.
If Blogger goes live with the final APP protocol and Basic+TLS is all they
support, I'm fairly sure I'm going to want to implement it. Actually it's
highly likely I'll implement TLS anyway. I just don't see why I'm being told
up front that I SHOULD support it.
So why didn't we use that same logic about whether HTML should be
allowed in summaries?
I believe the argument was that the requirements and problems related to
syndication formats were well known by the time Atom got around to being
developed. However the publishing protocols are less well established and so
APP should be left flexible enough to develop as the market expands. At
least this is the impression I've got from the WG.
not trying to force security preferences on anyone. I think there's a
pretty well established practice, and hence a recommendation that this
spec can make that will enhance interoperability. It doesn't constrain
anyone and it doesn't make anyone non-compliant no matter what they do.
I understand the desire for interoperability, but if you have to make a
recommendation, why Basic+TLS rather than say Digest without TLS which is
certainly a lot easier? There may be very convincing security reasons for
wanting to recommend TLS but I don't know enough about security to know what
these arguments are. So far the only complaint I've seen against Digest was
that someone hacking into your password database could use the password
hashes to spoof a login. IMHO that's not a very convincing argument.
Why would the security practices in web browsers be relevant to
interoperability of to-be-written clients and servers?
The point is that these servers aren't particularly worried about security.
If they're requiring the use of TLS in their APP implementation they must
have another reason other than the concern that someone's password is going
to be intercepted by a packet sniffer.
I dunno, why does the Blogger pre-standard Atom API use HTTPS+Basic Auth
(http://code.blogger.com/archives/atom-docs.html). Maybe they suddenly
got paranoid?
As I said, it can't be parnoia because they currently show no interest in
trying to protect my password when I log in via their website. Maybe they
just haven't got around to implementing something like Digest. Maybe
Basic+TLS is all that most existing clients support. I don't know. I just
don't think "because that's the way Blogger is currently doing it" is a very
good reason for making Basic+TLS a SHOULD recommendation for everyone else.
Regards
James
