Hi Joe, --On July 16, 2010 2:55:42 PM -0700 Joe Touch <touch@xxxxxxx> wrote:
1) the document contains a section discussing the registration of caldev and caldevs (Sec 3); a corresponding section for carddev and carddevs should be added.
As noted in the fourth paragraph of the introduction, the CardDAV service types have been defined in [I-D.ietf-vcarddav-carddav] currently in the RFC Editor queue.
2) the IANA recommendation that these four service names be added as aliases to http and https (correspondingly) does not seem correct. If these are indeed aliases, then this specification should recommend the use of either "http" or "https" (correspondingly) in the SRV records, without the need for new names. However, I believe the intent is that the caldev and/or carddev servers could exist on other ports than the typical web server; as such, they should be registered as service names (as per the existing SRV registry, e.g.), NOT as aliases in either the SRV registry (which has no such concept) or the IANA ports table. I.e., these new names should be registered as service names, not as aliases. This should be sufficient for the purposes of this document.
In [I-D.ietf-vcarddav-carddav], after much debate with the IESG and the associated working group, the approach of registering the service types as aliases was agreed upon as a stop gap measure until the IANA SRV registry is setup. draft-daboo-srv-caldav follows that same approach.
3) The use of a required URI suffix (/carddev or /caldev) seems to be too fixed. draft-cheshire-dnsext-dns-sd (intended as standards track) indicates a way to embed this information in the a TXT record with the same DNS name as the SRV record; RFC 5507 represents the IAB (informational) position that most additional information should be included in new RR types (though it's unclear this could easily support URI suffixes). My concern is that this document does neither; it embeds this information in this document as a requirement, rather than presenting it as a configurable option with a default. I would prefer to see the latter (regardless of how), to indicate the URI suffix if not the 'default' as specified in this document.
RFC5785 defines the .well-known URI - I think it is very clear that, given that CalDAV and CardDAV are in effect web-services, making use of .well-known is the right thing to do. There is no need for any additional data in the DNS. What is more, the .well-known approach is in fact useful in the absence of SRV - it can minimise the information users would have to enter. I don't see this approach as being "too fixed" - the whole point about .well-known is to fix things like this.
-- Cyrus Daboo _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf