(In reply to comment #41)
> One must remember that Thunderbird is actually implementing the spec here: they
> are keying usernames/passwords to a hostname/resource pair.  This is the
> *correct* behavior.  The incorrect behavior is that Google uses the same
> resource for all its calendars, when (at the very least) it should use a
> separate resource for each "apps for your domain" domain.  In short, the bug is
> Google's not Thunderbird's.
> 
> That being said, Thunderbird may want to allow behavior that is different than
> what the relevant RFC states in order to provide a better user experience with
> Google and other major hosts who don't implement the RFC in the best way.

Where in which RFC is this behavior specified?

My reading of the RFC's is that CalDAV can use HTTP Basic Authentication,
and RFC2617 says that in HTTP Basic Authentication the server provides the
client with a 'realm' string in its challenge.  Most of the spec revolves
around what the server should do:

  * [Section 1.2] "The realm value (case-sensitive), in combination
    with the canonical root URL (the absoluteURI for the server whose
    abs_path is empty; see section 5.1.2 of [2]) of the server being
    accessed, defines the protection space."

  * [Section 2] "The realm value should be considered an opaque string
    which can only be compared for equality with other realms on that
    server."

  * [Section 2] "The server will service the request only if it can
   validate the user-ID and password for the protection space of the
   Request-URI."

It doesn't say that userid/password is keyed to hostname/resource; it says
it's keyed to canonical-root-url/realm.  Sure, realm == resource, but
canonical-root-url != hostname.  In fact, I have the feeling that there's
a misprint in Section 1.2: "server being accessed" should have been
"service being accessed", because the intent appears to be that the key
is the root-path of the resource being accessed (where the resource is
a subtree of the path-space of the server).

Anyhow, this is all about what the server should do.  The last paragraph
of Section 2 does say something about what the client should do:

   A client SHOULD assume that all paths at or deeper than the depth of
   the last symbolic element in the path field of the Request-URI also
   are within the protection space specified by the Basic realm value of
   the current challenge. A client MAY preemptively send the
   corresponding Authorization header with requests for resources in
   that space without receipt of another challenge from the server.

So, if a client has already authenticated to "http://example.com/a/b", then
it should assume that "http://example.com/a/b/c/d" is covered by the same
bits.  However, the RFC does not say what the client should do with
"http://example.com/a" or "http://example.com/a/q".

The RFC says nothing about how the client should present any of this to
the user either.  Given all the above, it seems that the problem is that
Thunderbird is implementing an interface that goes *beyond* the behavior
specified in the RFC, and does so in a way that is annoying and 
counter-intuitive to the user.  (Firefox has the same user interface,
but the behavior is defective in a different way since the interaction
with a "website" is very different from the interaction with a CalDAV
calendar service.)

----

Once again, I reiterate my offer:  if some one points me in the right 
direction in the mozilla codebase and gives me some coaching, I'd be
happy to try to do some work on this.  (Reading some RFC's is one thing,
trying to understand how that mass of code works is another.)