Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
I strongly disagree with the use of NAPTR. It has a ridiculous amount of power and mechanism. SRV is well supported in servers, NAPTR is not. The process of standards making is to eliminate unnecessary flexibility. In this case the configuration of the caldav Web host is not relevant to the client. Therefore those details should not be exposed to the client. This is a security issue but also an encapsulation issue. Exposing unnecessary details to clients is an invitation to engage in the equivalent of undocumented API calls. I do not want to expose that information to clients because I do not want them to start relying on it. Rather, I suggest that we generalize the process and adopt the convention that the URL be formed from the SRV prefix. That is we have one registry for prefixes and apply them to SRV and URI formation. I would also suggest adding in a version number so that it is possible to run two versions of the protocol using different back ends. Since we are using SRV we will have two DNS names involved 1) The DNS name of the protocol 2) The DNS name of the host on which the service is provided The DNS name of the host need not be the only DNS name that the host responds to. Ergo, there is no actual need to use the .wellknown hack in this particular case. We can insist that the DNS name be reserved for forwarding web services. As for the need for 'redirect' this should not affect the protocol on the wire. Rather the Web server should perform any internal mapping. On Mon, Jun 21, 2010 at 2:10 PM, Cullen Jennings flu...@cisco.com wrote: It seems like using NAPTR might be a better choice than the ./well-known with redirect. On Jun 18, 2010, at 9:51 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Use of SRV records for locating CalDAV and CardDAV services ' draft-daboo-srv-caldav-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-07-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-daboo-srv-caldav-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18589rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
[Sorry, got Cullens' out of thread, did not realize there was more debate since, replying to a number of different posters here] I really do not like the idea of a new RR unless it can be shown that SRV is not sufficient. There are still issues deploying new RRs. Windows DNS does not provide an administrator interface for new RRs. Plugging them into BIND is not exactly simple either. At root DNS remains a binary protocol and that means that no DNS server is going to have decent support for unknown RRs until it gets an update. The mere ability to dynamic update a new RR into a server is not the same thing as being able to use that RR in a production environment. You have to be able to update the RR using the same tools you use for the rest of the zone. What really worries me is that there are people who are busy inventing new discovery mechanisms for Internet protocols via HTTP who are completely ignoring the existing DNS infrastructure. For example, why does OpenID not just use u...@example.com as the identifier for a user and SRV to discover the authentication server that can give an answer for that domain? It would be job done five years ago. At the moment OpenID has a discovery mechanism via HTTP and a proprietary lookup scheme via XRI that isn't proprietary really because the people who control the rights tell us they trust themselves. A proposal for a new RR in that debate is the last thing we need. It suggests that the IETF does not understand how to do service discovery and opens up the field for XRI. For caldav over HTTP, SRV works fine. For finding the right protocol amongst a number of options (e.g. finding the right authentication protocol from Kerberos, SAML, OpenID, KitchenSink, etc.) we need something additional. I can see that a new RR could add value there if it provided a list of protocols on offer, protocol options, version numbers etc. In other words a Service DESCRIPTION record. I think that that would be a very valuable thing for the IETF to work on. The functionality I need is not considered in NAPTR. As for the interaction with DNSSEC, I think it is double ended. At the moment DNSSEC has no particular function. If we only implement what is described to date there is nothing that DNSSEC can do that is not already done better by the existing infrastructure of SSL and CA issued Domain Validated X.509 certs. Now consider what would happen if we added the ability to use the DNS to distribute statements of the form 'this SMTP server always offers STARTTLS, This Caldev server always offers SSL Suddenly DNSSEC not only has a point, it has a point that cannot be supported using any other infrastructure. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Has anyone talked to anyone in the applications world about this? The use of a new DNS Resource Record creates far more problems than any of these proposed discovery mechanisms offer. No matter how much the DNSEXT people want to believe that adding DNS records is not an issue, the fact is that it is. SRV is a well established record. It is already widely used for service discovery. This new proposal does not offer any real functionality. All it allows is for the service administrator to choose a random string to insert into every one of their service URLs. The random string chosen has no semantic significance whatsoever, has no security benefit and the only constraint on it is that it should be unique for each service. Back in the earliest days of the web, the first web server was info.cern.ch. After a short while www.example.com became the standard naming to the point where it is now embedded in many browsers that if a search for a domain fails, add www. to the name and try again. Whether you like that approach or not, the fact is that the administrative constraint of a web server being expected to be at www has not proved onerous. If we pick out one way to do the management of web services via SRV lookup the software world will quickly adapt to it. The transition from the SRV way of doing things to the new way of doing things can be easily managed through server side URI mapping. There is no need for HTTP redirects of any on-the-wire protocol impact. What we are missing here is a better way to find the protocol properties. That is something that should be done through a DNS record rather than an HTTP lookup. If the protocol properties are discovered through HTTP lookup then we have already made the decision to use HTTP and we can't use DNSSEC to advertise that SSL is always available to avoid a downgrade attack. On Fri, Jun 25, 2010 at 3:53 AM, Ray Bellis ray.bel...@nominet.org.ukwrote: I can certainly see where it would be useful. However, I question your comments in Section 9 of your draft: specifically that URI should be viewed as a replacement for SRV. URI (may) make sense for resource discovery, but I don't believe that is true for service discovery - I think SRV still makes the best sense for that. IMHO, that depends on the service. In RAI we have LoST and HELD, both of which are HTTP(s) based services contacted through a URI. A URI RR-based solution for discovery of those would, I think, have been cleaner than the current U-NAPTR based methods. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher, Nominet e: r...@nominet.org.uk, t: +44 1865 332211 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
At 7:47 AM +0200 6/24/10, Patrik Fältström wrote: Sure, but, support for unknown RR Types is said to be needed since long time back. And what API do not handle the ability to request an RR with a specific RRTYPE? int res_query(const char *dname, int class, int type, u_char *answer, int anslen); Anyway...this discussion has been held in the IETF I do not know how many times. Instead of writing another 10 lines of code (or whatever is needed) people fall back to existing RR Types, and not only that, define future protocols because of lack of #define for new RRTYPES. I know people have different views here, and I have one specific view ;-) 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. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Paul, --On June 24, 2010 8:59:18 AM -0700 Paul Hoffman paul.hoff...@vpnc.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). -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
At 12:24 PM -0400 6/24/10, Cyrus Daboo wrote: Hi Paul, --On June 24, 2010 8:59:18 AM -0700 Paul Hoffman paul.hoff...@vpnc.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). Sorry, I wasn't clear. My in this case was how does the IETF want to handle the case of getting a resource from the DNS, not the CalDAV/CardDAV case. It may be fine that the CalDAV/CardDAV API include HTTP, but I would hope that the IETF could settle on one DNS-specific method that all apps could use. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 24, 2010 6:32:48 PM +0200 Patrik Fältström p...@cisco.com wrote: 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. Well, I think .well-know/caldav should be normal for CalDAV irrespective of whether SRV or URI is setup. That still provides major advantages to clients and server admins. 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. I can certainly see where it would be useful. However, I question your comments in Section 9 of your draft: specifically that URI should be viewed as a replacement for SRV. URI (may) make sense for resource discovery, but I don't believe that is true for service discovery - I think SRV still makes the best sense for that. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 24 jun 2010, at 20.26, Cyrus Daboo wrote: I can certainly see where it would be useful. However, I question your comments in Section 9 of your draft: specifically that URI should be viewed as a replacement for SRV. URI (may) make sense for resource discovery, but I don't believe that is true for service discovery - I think SRV still makes the best sense for that [not in context of the caldav draft...] Hmm...you might be correct here. For example in the case of a URI RR that refer to a mailto URI that in turn (theoretically) should use SRV to know what port and hostname to use for the destination of the SMTP connection? So a URI might in some cases in turn result in the need for an SRV lookup? Is that your point? Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 24 jun 2010, at 21.49, Peter Saint-Andre wrote: So a URI might in some cases in turn result in the need for an SRV lookup? That's often the case for xmpp URIs. Point taken. New draft will be produced. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 23 jun 2010, at 00.59, Thomson, Martin wrote:
It seems that Section 7 has an old example in it. Did you previously use
NAPTR with a D flag?
Actually, no. If you do know what protocol you look for, you can use the URI RR
directly. The idea with the NAPTR and the D flag was that it would list what
URI records exists in the zone.
Let me expand a bit also including the caldav example:
$ORIGIN example.com.
IN NAPTR 200 10 D EM:protA ( ; service
; regexp
example.com. ) ; replacement
IN NAPTR 200 10 D caldav:caldav ( ; service
; regexp
example.com. ) ; replacement
IN NAPTR 200 10 D caldav:carddav ( ; service
; regexp
example.com. ) ; replacement
_protA._EM IN URI prota://somehost.example.com/
_carddav._caldav IN URI http://somehost.example.com/whateveruri;
_caldav._caldav IN URI http://somehost.example.com/someotheruri;
I.e. if you know you want the carddav/caldav URI, you just look up the
{IN,URI,_carddav._caldav.example.com} RRSET, if you want to know the services
example.com has, you look up {IN,NAPTR,example.com} and then with flag D you
see what you can find using lookup of URI RR.
So, the NAPTR and flag D is not really needed for the resolution. It is a
list the services feature.
But, I will remove that part because it is not really a piece of the URI
definition.
For security considerations, I have one to add. RFC 3958 (S-NAPTR) has this
nasty little authentication hitch, that you should really consider in this
draft. The reference identifier (see draft-saintandre-tls-server-id-check)
that you are required to use for authenticating the host is the one that is
input to the resolution process...not the product of the process.
Basically, if you search for _http._web.example.net and get
http://www.example.com/ , then you are expected to authenticate against
_http._web.example.net (or maybe example.net, I'm not sure - NAPTR doesn't
use the '_' prefix).
I thought you should authenticate against example.net?
I.e. you want caldav/caldav for example.com and get back
http://www.calendarserverfoobar.com/caldav/example.com/caldav; (for a
PROPFIND), what is the best to require for authentication? example.com or
www.calendarserverfoobar.com? I presume example.com (the domain name used
_before_ the URI lookup happens.
Patrik
I'm happy to expand on the problems that I faced with this little security
tangle. The problem doesn't end there.
PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 23 jun 2010, at 16.33, Richard L. Barnes wrote: In principle, example.com is the proper domain to authenticate, but in practice, that causes a lot of problems. Consider the case where the target of the redirection is a separate entity from the origin; this could arise, for example, in a situation whereexample.com has outsourced its calendaring services to calendardserverfoobar.com. So, the connect the dots is to: - Announce the fact example.com is hosted at calendarserverfoobar.com (with some URL) in DNS - Secure that announcement in DNS with DNSSEC - Verify the SSL (for example) cert for the connection to calendarserverfoobar.com matches - Do application layer authentication etc over the then encrypted connection Sounds ok? Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Basically, yeah, as long as you have DNSSEC. In fact, if you've got DNSSEC, you don't really even need the application-specific bit at the end. The goal of the XMPP DNA work (and other analogous things) is to work around not having DNSSEC in the mean time. In that solution, the parallel path is: - Announce the fact that example.com is hosted at clendarserverfoobar.com in DNS - Connect to calendarserverfoobar.com over TLS and check that the name in the cert is indeed calendarfoobar.com - Obtain an attribute cert for calendarfoobar.com signed by example.com - Valid signature and certificate for example.com implies that delegation is OK The third of these steps of course require some application-specific magic. --Richard On Jun 23, 2010, at 2:52 PM, Patrik Fältström wrote: On 23 jun 2010, at 16.33, Richard L. Barnes wrote: In principle, example.com is the proper domain to authenticate, but in practice, that causes a lot of problems. Consider the case where the target of the redirection is a separate entity from the origin; this could arise, for example, in a situation whereexample.com has outsourced its calendaring services to calendardserverfoobar.com. So, the connect the dots is to: - Announce the fact example.com is hosted at calendarserverfoobar.com (with some URL) in DNS - Secure that announcement in DNS with DNSSEC - Verify the SSL (for example) cert for the connection to calendarserverfoobar.com matches - Do application layer authentication etc over the then encrypted connection Sounds ok? Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 23, 2010 8:52:45 PM +0200 Patrik Fältström p...@cisco.com wrote: In principle, example.com is the proper domain to authenticate, but in practice, that causes a lot of problems. Consider the case where the target of the redirection is a separate entity from the origin; this could arise, for example, in a situation whereexample.com has outsourced its calendaring services to calendardserverfoobar.com. So, the connect the dots is to: - Announce the fact example.com is hosted at calendarserverfoobar.com (with some URL) in DNS - Secure that announcement in DNS with DNSSEC - Verify the SSL (for example) cert for the connection to calendarserverfoobar.com matches So the srv-caldav (and srv-email) drafts reference Section 3 of draft-saintandre-tls-server-id-check which describes how clients can go about verifying a server identity when using TLS under various circumstances, including an initial discovery via SRV records. - Do application layer authentication etc over the then encrypted connection Sounds ok? Well the key here is DNSSEC of course! -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 22, 2010 8:54:22 AM +0200 Patrik Fältström p...@cisco.com wrote: I have together with Olaf Kolkman suggested a new RR type that I call URI that work similarly to what is described in this draft (regarding the owner of the RRSET), but a URI in the RDATA. It has been posted to the namedroppers list a few times...but maybe that has been wrong. Maybe Apps Area should have been notified about the work a bit more... Cyrus has asked a few questions about it, and maybe it is me that have not reached out to the Caldav people enough? I have tried to push it through via the DNS people in the IETF, but there have not been enough traction. I did chat with a few server implementors about this and the feeling was SRV + .well-known is a good solution that can quickly be deployed. Some points: 1) SRV's are very deployable today - a new RR will be harder to deploy. 2) There is a push to support SRV's with other protocols (e.g. draft-daboo-srv-email for IMAP, POP3, and Submission) so from an operational standpoint its likely to be more common. 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 23 jun 2010, at 21.20, Cyrus Daboo wrote: I did chat with a few server implementors about this and the feeling was SRV + .well-known is a good solution that can quickly be deployed. Some points: 1) SRV's are very deployable today - a new RR will be harder to deploy. 2) There is a push to support SRV's with other protocols (e.g. draft-daboo-srv-email for IMAP, POP3, and Submission) so from an operational standpoint its likely to be more common. 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path. Hmm...regarding the new RR, the only thing I can think of today is the need for some changes in the provisioning system from which one create the DNS zones. I do not know of any DNS code today that can not handle unknown DNS RR Types, but maybe I am wrong? I am though confused over (1) as this is 2010 and not 1998. Regarding (3), I think it is sad people move redirects and lookups and functionality to be on top of HTTP instead of IP. And I do not understand in the absence of DNS...that is an interesting situation ;-) Specifically to use that as the foundation for the architecture to use for calendaring, that is -- I hope -- one of the more fundamental applications on the Internet. A new version of my draft I promised today, but due to this security consideration discussion, it is now delayed yet another day. And yes, I will do the job of releasing a new version although there will continue to not be any interest of using it. :-) Or maybe I should just push it through, although for calendaring draft-daboo-srv-caldav will be used. Hmm... I do not want to be problematic here. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 23, 2010 10:07:44 PM +0200 Patrik Fältström p...@cisco.com wrote: I did chat with a few server implementors about this and the feeling was SRV + .well-known is a good solution that can quickly be deployed. Some points: 1) SRV's are very deployable today - a new RR will be harder to deploy. 2) There is a push to support SRV's with other protocols (e.g. draft-daboo-srv-email for IMAP, POP3, and Submission) so from an operational standpoint its likely to be more common. 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path. Hmm...regarding the new RR, the only thing I can think of today is the need for some changes in the provisioning system from which one create the DNS zones. I do not know of any DNS code today that can not handle unknown DNS RR Types, but maybe I am wrong? I am though confused over (1) as this is 2010 and not 1998. I am thinking more of client APIs. Regarding (3), I think it is sad people move redirects and lookups and functionality to be on top of HTTP instead of IP. And I do not understand in the absence of DNS...that is an interesting situation ;-) Specifically to use that as the foundation for the architecture to use for calendaring, that is -- I hope -- one of the more fundamental applications on the Internet. Sorry - bad wording on my part. What I meant was in the absence of a service-type to hostname mapping in the DNS. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
At 3:20 PM -0400 6/23/10, Cyrus Daboo wrote: 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path. This sounds weird to me. The tradeoff is using two different protocols (DNS and HTTP) versus one (DNS). For schemes that are not being run over HTTP, that means that the client needs to add an HTTP client stack just to find the right server. Is this really a good idea? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 23 jun 2010, at 23.05, Cyrus Daboo wrote: Hmm...regarding the new RR, the only thing I can think of today is the need for some changes in the provisioning system from which one create the DNS zones. I do not know of any DNS code today that can not handle unknown DNS RR Types, but maybe I am wrong? I am though confused over (1) as this is 2010 and not 1998. I am thinking more of client APIs. Sure, but, support for unknown RR Types is said to be needed since long time back. And what API do not handle the ability to request an RR with a specific RRTYPE? int res_query(const char *dname, int class, int type, u_char *answer, int anslen); Anyway...this discussion has been held in the IETF I do not know how many times. Instead of writing another 10 lines of code (or whatever is needed) people fall back to existing RR Types, and not only that, define future protocols because of lack of #define for new RRTYPES. I know people have different views here, and I have one specific view ;-) Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
All, I have together with Olaf Kolkman suggested a new RR type that I call URI that work similarly to what is described in this draft (regarding the owner of the RRSET), but a URI in the RDATA. It has been posted to the namedroppers list a few times...but maybe that has been wrong. Maybe Apps Area should have been notified about the work a bit more... Cyrus has asked a few questions about it, and maybe it is me that have not reached out to the Caldav people enough? I have tried to push it through via the DNS people in the IETF, but there have not been enough traction. Anyway... I can do that via an individual submission if there is interest. I think the draft is ready for publication. See http://tools.ietf.org/html/draft-faltstrom-uri-04 (i.e. the draft has expired a few months ago). 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Target/ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this case (to take an example from the draft in question), it would be for example: Instead of: _caldav._tcp SRV 0 1 80 calendar.example.com. Followed by doing PROPFIND for http://calendar.example.com/.well-known/caldav ...etc... With a potential redirect etc... It could with the URI resource record for example be: _caldav._caldavIN URI 10 1 http://www.example.com/example/whatever/uri/caldav/; or _carddav._caldavIN URI 10 1 http://www.example.com/foo/some/other/uri/carddav/; And the URI is used directly for the PROPFIND. Patrik On 21 jun 2010, at 20.10, Cullen Jennings wrote: It seems like using NAPTR might be a better choice than the ./well-known with redirect. On Jun 18, 2010, at 9:51 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Use of SRV records for locating CalDAV and CardDAV services ' draft-daboo-srv-caldav-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-07-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-daboo-srv-caldav-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18589rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
At 8:54 AM +0200 6/22/10, Patrik Fältström wrote: I have together with Olaf Kolkman suggested a new RR type that I call URI that work similarly to what is described in this draft (regarding the owner of the RRSET), but a URI in the RDATA. It has been posted to the namedroppers list a few times...but maybe that has been wrong. Maybe Apps Area should have been notified about the work a bit more... Patrik and Olaf's proposal has some big advantages over two-step SRV searching. To implementers, there will be just one API for many services; now that web browsers are the universal application, this could be a big win. It is also only one DNS lookup instead of a DNS request followed by a HTTP PROPFIND. It should be seriously considered (and they should get a new draft out...) instead of a hodgepodge of scheme-specific methods. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 22 jun 2010, at 16.15, Paul Hoffman wrote: It should be seriously considered (and they should get a new draft out...) instead of a hodgepodge of scheme-specific methods. Consider a new draft posted tomorrow (it is already close to evening here in Sweden, and my cats are screaming after food). Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
At 08:51 18-06-10, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Use of SRV records for locating CalDAV and CardDAV services ' draft-daboo-srv-caldav-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the What is the -CardDAV tag for in Updates? In Section 5: The client will need to make authenticated HTTP requests to the service. Typically a user identifier is required for some form of user/password authentication. Is that the userinfo from RFC 3986? Is the user prompted for the password? In Section 5: An SRV lookup for _caldavs._tcp (for CalDAV) or _carddavs._tcp (for CardDAV) is done with the user provided domain as the service domain. The IANA request (Section 8.3) only mentions adding caldav and caldavs service labels as aliases for http and https respectively. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
SM wrote: At 08:51 18-06-10, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Use of SRV records for locating CalDAV and CardDAV services ' draft-daboo-srv-caldav-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the Hi SM, What is the -CardDAV tag for in Updates? This is the same as [I-D.ietf-vcarddav-carddav]. In Section 5: The client will need to make authenticated HTTP requests to the service. Typically a user identifier is required for some form of user/password authentication. Is that the userinfo from RFC 3986? Yes. Is the user prompted for the password? In Section 5: An SRV lookup for _caldavs._tcp (for CalDAV) or _carddavs._tcp (for CardDAV) is done with the user provided domain as the service domain. The IANA request (Section 8.3) only mentions adding caldav and caldavs service labels as aliases for http and https respectively. carddavs and carddav are already registered in [I-D.ietf-vcarddav-carddav]. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Alexey, At 13:10 22-06-10, Alexey Melnikov wrote: carddavs and carddav are already registered in [I-D.ietf-vcarddav-carddav]. Section 11 of draft-ietf-vcarddav-carddav-10 mentions that the specification adds two service types for use with SRV records, i.e. carddav and carddavs. That's not mentioned under IANA Considerations (Section 14). Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
From: Patrik Fältström on Tuesday, 22 June 2010 4:54 PM: See http://tools.ietf.org/html/draft-faltstrom-uri-04 (i.e. the draft has expired a few months ago). It seems that Section 7 has an old example in it. Did you previously use NAPTR with a D flag? For security considerations, I have one to add. RFC 3958 (S-NAPTR) has this nasty little authentication hitch, that you should really consider in this draft. The reference identifier (see draft-saintandre-tls-server-id-check) that you are required to use for authenticating the host is the one that is input to the resolution process...not the product of the process. Basically, if you search for _http._web.example.net and get http://www.example.com/ , then you are expected to authenticate against _http._web.example.net (or maybe example.net, I'm not sure - NAPTR doesn't use the '_' prefix). I'm happy to expand on the problems that I faced with this little security tangle. The problem doesn't end there. Cheers, Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Use of SRV records for locating CalDAV and CardDAV services ' draft-daboo-srv-caldav-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-07-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-daboo-srv-caldav-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18589rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
