Hi, Cyrus,
On 7/16/2010 6:11 PM, Cyrus Daboo wrote:
Hi Joe,
--On July 16, 2010 2:55:42 PM -0700 Joe Touch <touch(_at_)isi(_dot_)edu> 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.
The information from section 11 of that draft should be repeated in
summary in this one, e.g., in Sec. 3.
Note that ietf-vcarddav-carddav does not request that the
carddev/carddevs strings be added to the SRV registry.
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.
The SRV registry exists even in advance of IANA's management thereof.
Further, aliases have no meaning in the SRV registry - they are
meaningful only in the IANA ports registry, and only insofar as multiple
strings are assigned the same port number. No such port number
assignment is requested or appropriate here (they aren't needed for SRV
records per se).
One exception would be if you *also* intend that these strings serve as
aliases to the well-known ports 80 and 443, respectively. However, this
document does NOT define an alias for either of those ports. An alias
would be an equivalent name which can be substituted without impact.
Here, were you to use "http" or "www" instead of "caldev" or "carddev",
you should presumably not be using the /caldev or /carddev URI suffixes.
I would be glad to discuss this further wiht the IESG or WG if needed.
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.
This doc seeks to escape the fixed allocations of the static IANA ports
table by using SRV records to locate resources dynamically. However,
this doc also refers back to a different but equally fixed .well-known
URI table without a similar SRV-like dynamic escape mechanism.
This isn't a fix; this is creating a stop-gap, and having a dynamic SRV
registry refer back to a fixed table undermines the whole point of SRV
records AFAICT.
Joe
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf