Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating C

On 24 jun 2010, at 18.24, Cyrus Daboo wrote:

> --On June 24, 2010 8:59:18 AM -0700 Paul Hoffman 
> <paul(_dot_)hoffman(_at_)vpnc(_dot_)org> wrote:
>
> > As someone who normally has that "different view", I support a new RRTYPE
> > in this case because the option of reusing SRV is not sufficient: it
> > requires DNS-SRV-followed-by-HTTP. I think a new RRTYPE that keeps the
> > DNS lookup entirely in the DNS protocol far outweighs reusing SRV but
> > requiring HTTP on both sides.
> "in this case" as in the draft under discussion? If so, I don't don't 
> understand your position. The protocols/services being referenced by the 
> draft are HTTP protocols, so it is always going to be SRV-followed-by-HTTP. 
> What is more, simply getting a generic host/path is not sufficient for client 
> configuration - additional steps are required to find the principal resource 
> of the user for whom the client is setting up an "account" (as described in 
> the draft).
The only real differences are, I think (correct me here if I am wrong Cyrus):

draft-daboo-srv-caldav uses SRV + an http transaction towards a "well known 
path", followed by the normal caldav HTTP transactions.

draft-faltstrom-uri uses the new RR Type URI (that give the path, that does not 
have to be the same all over the place), followed by the normal caldav HTTP 
transactions.

Personally, I think first of all the URI RR can be useful for many things (else 
I would not have written the draft in the first place) and will push this to an 
RFC status. Secondly, what I "do not like" in the draft-daboo-srv-caldav is 
that you need an explicit well known path that one tag onto the URI. Virtual 
hosting (given normal http hosts) might be "interesting"...but of course, 
someone will hack an .htaccess together that give the right redirect given the 
HOST header... But I think that is "uglier" (note the quotes) than a new RR 
Type. YMMV...

   Patrik

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf