On 24 jun 2010, at 18.24, Cyrus Daboo wrote: > --On June 24, 2010 8:59:18 AM -0700 Paul Hoffman <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/ietf
