Hi, Cyrus,
On 7/17/2010 12:00 PM, Cyrus Daboo wrote:
...
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.
Well there have been plenty of discussions around this in the context of
the CardDAV draft. This draft is following the process agreed upon for
CardDAV.
The goal here is to not delay drafts trying to use SRV whilst details of
the IANA ports stuff is sorted out (and then debate on that has been
going on for a while now). Once the new IANA procedure is in place it
will subsume the definitions in CardDAV and this draft.
Until the new procedure in place, the current procedure - albeit
unoffical - is to register with the SRV registry as a conventional SRV
entry.
The term "alias" has no relevance here, though.
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.
I don't understand this. SRV by itself (whilst dynamic in terms of host
and port) is not sufficient for clients to reasonably do account
"bootstrapping" as needed for CalDAV and CardDAV. A path is needed in
addition to the host/port.
That's what I understood from the doc. The question is whether that path
is fixed in some table somewhere - much like IANA ports - or whether the
path is provided by a service - like SRV records are for port numbers.
SRVs have extensions to do this - associated TXT records, as per
Cheshire's draft.
This specification standardizes the path for
CalDAV and CardDAV services. The whole basis of .well-know is that web
clients want fixed paths for finding out things about web servers. This
spec simply extends that to allow CalDAv and CardDAV clients to quickly
find the paths to their relevant services.
The problem is the idea of a 'fixed' path. That's no more useful or
appropriate than a fixed port number.
Arguably ./well-known is just as "dynamic" as SRV in that the
.well-known resources can use HTTP redirect to any arbitrary
host/port/path combination. All we are doing is "fixing" the name of the
.well-known via a registry - which seems to me exactly the same process
as registering the SRV service types.
I agree with Patrick here; redirects are NOT a solution to dynamic
discovery of paths. The appropriate solution for a port discovered via
SRV records is to use TXT records.
Joe
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf