Re: TSV-DIR review of draft-daboo-srv-caldav-05
Hi Patrik, --On July 19, 2010 4:42:51 AM +0200 Patrik Fältström p...@cisco.com wrote: From my point of view, adding additional RR types with those properties (to MX, SRV, NAPTR, and arguably CNAME and DNAME) does increase the security risks -- not by adding risks that were not there before, but by making it harder to keep track of and analyze the various risk vectors, especially when these various RR types can have data that points to others of them. YMMD. Ok. I think the current resolution mechanism in the daboo-srv-caldav draft also have a very interesting security mechanism as that is relying on a correct SRV plus a redirect in HTTP that can redirect to anything...and in this second step you rely on both the SRV and the HTTP redirect actually refer you to the correct resource. This can be tied down of course if the HTTP redirect and the SRV are bound to: - The SRV not do a referral outside the domain in question - The http redirect is on the same server the SRV referred to But that also removes some interesting flexibility that one might want to do. Like hosting virtual domains at some hosting company. So the security in draft-daboo-srv-caldav is mostly addressed by reference to draft-saintandre-tls-server-id-check. In particular that draft describes use of the X509 SRVName attribute as a means for a client to determine that the SRV lookup results they got are valid (in addition to doing normal hostname checks on the actual host). I would suggest that your draft reference draft-saintandre-tls-server-id-check too, and perhaps suggest the same use of SRVName verification but in this case applied to the URI RR. (2) It seems to me that we may be creating very high expectations in the community for the security and integrity of information in DNSSEC-signed zones that can be validated with a root trust anchor (look at almost any of the recent announcements for examples). While I understand the DNSSEC for the URI RR; TLS/SSL cert for the URI's hostname model mentioned above and described in the I-D, the reality is that many, perhaps most, of the TLS/SSL certs in the world are nearly useless or, to put it more politely, offer a very low level of assurance relative to what people have been encouraged to believe about root-anchored DNSSEC. No luser is going to understand the difference between the two elements of the validation mechanism. Far more likely, the weakest link principle will apply and the expectation of security from DNSSEC will drop to that of the quality of the typical self-signed or prove that you own the domain name by receiving mail TLS/SSL cert. Again, at a minimum, I think your Security Considerations section should analyze and warn about the fragility in practice of the approach you suggest. What I think might be needed is that IETF comes up with a proper architecture for the following: An application do have the need to contact a service. The service is identified by a unique identifier that is registered by IANA (that identifies a service) and a domain name. On top of that, there might be a sub-identifier in the form of a unique identifier for a user (i.e. local part in an email address etc). What are the steps the application should go through before it actually opens some connections over IP, and what should it do then to secure the whole thing. We have a number of alternatives: 1. Use MX 2. Use SRV and well known algorithm for the service, using prefixes of the owner 3. Use A and and well known algorithm 4. We have DDDS, using NAPTR with service selection in RDATA if DNS is used as the base database (of various flavours, UNAPTR etc) 5. We have the daboo-srv-caldav that uses SRV plus http redirect from a .well-known path that is used in the HTTP transaction 6. We have TXT records with well known syntax in the RDATA 7. I propose using a SRV-like prefix naming that give back full URIs, and the rest of the resolution have to do with URI resolution Bear in mind that the web folks are also looking at a solution in their domain - in particular proposals such as webfinger are a way to map an identifier (in this case based on a new acct: URI scheme) to various services. Let me state that I do not think we should delay the draft-daboo-srv-caldav IF a work like this is started. If we get some work like this, I suggest letting draft-daboo-srv-caldav pass, given people do not think the solution with an http redirect is too weird. So Alexey did ask the authors of .well-known about this use and we have a little side-thread going on that. I am certainly willingly to be persuaded that draft-daboo-srv-caldav is stretching the use too far, in which case I would suggest a TXT path='/xyz' solution. So one question I have with URI is whether additional metadata is likely to be needed? In which case TXT is likely to be used at provide that. If that is the case, then I don't see why URI is needed, vs SRV/TXT (with a path= in the TXT). I do not like the
Re: TSV-DIR review of draft-daboo-srv-caldav-05
--On Monday, July 19, 2010 04:42 +0200 Patrik Fältström p...@cisco.com wrote: ... No luser is going to understand the difference between the two elements of the validation mechanism. Far more likely, the weakest link principle will apply and the expectation of security from DNSSEC will drop to that of the quality of the typical self-signed or prove that you own the domain name by receiving mail TLS/SSL cert. Again, at a minimum, I think your Security Considerations section should analyze and warn about the fragility in practice of the approach you suggest. What I think might be needed is that IETF comes up with a proper architecture for the following: An application do have the need to contact a service. The service is identified by a unique identifier that is registered by IANA (that identifies a service) and a domain name. On top of that, there might be a sub-identifier in the form of a unique identifier for a user (i.e. local part in an email address etc). What are the steps the application should go through before it actually opens some connections over IP, and what should it do then to secure the whole thing. We have a number of alternatives: 1. Use MX 2. Use SRV and well known algorithm for the service, using prefixes of the owner 3. Use A and and well known algorithm 4. We have DDDS, using NAPTR with service selection in RDATA if DNS is used as the base database (of various flavours, UNAPTR etc) 5. We have the daboo-srv-caldav that uses SRV plus http redirect from a .well-known path that is used in the HTTP transaction 6. We have TXT records with well known syntax in the RDATA 7. I propose using a SRV-like prefix naming that give back full URIs, and the rest of the resolution have to do with URI resolution Part of the question I'd asking is whether, given the rate of growth, we will have 20 of those options a few years from now. If we do, what will that do to implementer confusion, interoperability, and security? The assumption that new RR types are fairly cheap does not imply that adding more and more nearly-equivalent (or at least functionally-overlapping) ones is desirable. So, yes, I think it may be time to do some serious architectural work here that comes up with specific guidelines, both about new RRs in this general area and about what should be used when. If we can't give crisp answers to the latter question, it may be time to start deprecating options, not just adding more of them. Let me state that I do not think we should delay the draft-daboo-srv-caldav IF a work like this is started. If we get some work like this, I suggest letting draft-daboo-srv-caldav pass, given people do not think the solution with an http redirect is too weird. Agreed. I would not have stepped into this discussion at all had the possibility of substituting a still-unapproved new RR type not come up. I think the discussion has been very useful, but don't believe that we should hold the present draft up as a result. I do not like the mechanism proposed in draft-daboo-srv-caldav. Definitely not. But that is a different thing than requiring rough consensus on a generic way of finding an endpoint of a connection for a service. Agree with that too, including not liking the mechanism. Luckily, Maastricht is a week from now and we can talk about it. In our collective copious spare time. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 19 jul 2010, at 16.07, Cyrus Daboo wrote: Let me state that I do not think we should delay the draft-daboo-srv-caldav IF a work like this is started. If we get some work like this, I suggest letting draft-daboo-srv-caldav pass, given people do not think the solution with an http redirect is too weird. So Alexey did ask the authors of .well-known about this use and we have a little side-thread going on that. I am certainly willingly to be persuaded that draft-daboo-srv-caldav is stretching the use too far, in which case I would suggest a TXT path='/xyz' solution. So one question I have with URI is whether additional metadata is likely to be needed? In which case TXT is likely to be used at provide that. If that is the case, then I don't see why URI is needed, vs SRV/TXT (with a path= in the TXT). Use of TXT RR? Arg... Not better. Why, why, why? I do not like the mechanism proposed in draft-daboo-srv-caldav. Definitely not. But that is a different thing than requiring rough consensus on a generic way of finding an endpoint of a connection for a service. Luckily, Maastricht is a week from now and we can talk about it. I'm up for that. Excellent. Interested parties should try to meet. 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: TSV-DIR review of draft-daboo-srv-caldav-05
On 7/18/2010 11:05 AM, Patrik Faltstrom (pfaltstr) wrote: On 18 jul 2010, at 19:18, Joe Touchto...@isi.edu wrote: That seems to means you use one of two different RRs, depending on the response. I don't see that as a step forward. No, the other way around. You, in a protocol, use either srv or uri depending on wether you need more than hostname and port or a uri. The point of SRVs is to provide a single way to find a service. When additional information is needed, it ought to be in an associated record (TXT or maybe a special URI one), but the host/port ought to remain in the SRV. We can discuss this further next week. Note that I consider addressing this important but not a show-stopper on this doc. The only showstopper was the alias issue (i.e., that, IMO, the names need to be registered in the informal SRV registry, and that IANA ports aliases are not appropriate as a stop-gap until that registry is integrated as per the iana-ports doc). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 18 jul 2010, at 19:18, Joe Touch to...@isi.edu wrote: That seems to means you use one of two different RRs, depending on the response. I don't see that as a step forward. No, the other way around. You, in a protocol, use either srv or uri depending on wether you need more than hostname and port or a uri. Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 19 jul 2010, at 17.34, Joe Touch wrote: No, the other way around. You, in a protocol, use either srv or uri depending on wether you need more than hostname and port or a uri. The point of SRVs is to provide a single way to find a service. For me, there should be a single way of finding a service, given the service you use. I.e. we already have (as I listed in a separate message) several ways of finding a service. Too many I claim. And it might get worse if we do not take care of this. I am not nervous over having multiple ways of finding a service, as long as one know that for email, you do like this, or for ssh, you do like this. When additional information is needed, it ought to be in an associated record (TXT or maybe a special URI one), but the host/port ought to remain in the SRV. I am not happy about such solutions as they require multiple lookups in DNS. And if one is not very careful the two records might have overlapping and therefore conflicting information in them. We can discuss this further next week. Yes please. Note that I consider addressing this important but not a show-stopper on this doc. Agree. If whatever IETF comes up with will be A Very Successful Mechanism, then this caldav work and other protocols can migrate over to the New And Improved way of doing things. The only showstopper was the alias issue (i.e., that, IMO, the names need to be registered in the informal SRV registry, and that IANA ports aliases are not appropriate as a stop-gap until that registry is integrated as per the iana-ports doc). Agree. The discussion about where to register names used for example for SRV has been going on since SRV RR was defined... Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 17 jul 2010, at 21.39, Joe Touch wrote: Are you suggesting a new RR instead of the SRV or in addition to the SRV? The latter seems useful; the former begs the question of how many SRV variants we would want. A new RR that is a replacement for the SRV for the cases where one need a URI and not only hostname+port. Otherwise, same syntax and usage as SRV (i.e. prefix of the owner decide the protocol and service etc). It is therefore more a replacement for SRV than replacement for NAPTR (that give back a list of services given a domain name). See draft-faltstrom-uri Patrik Joe On 7/17/2010 12:33 PM, Patrik Fältström wrote: On 17 jul 2010, at 21.27, Joe Touch wrote: The appropriate solution for a port discovered via SRV records is to use TXT records. And, for the ones that have not followed the whole history of this last call, my view is that a new RR type is needed, and I propose a URI resource record that as RDATA have the full URI to the resource in question. 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: TSV-DIR review of draft-daboo-srv-caldav-05
--On Sunday, July 18, 2010 09:14 +0200 Patrik Fältström p...@cisco.com wrote: On 17 jul 2010, at 21.39, Joe Touch wrote: Are you suggesting a new RR instead of the SRV or in addition to the SRV? The latter seems useful; the former begs the question of how many SRV variants we would want. A new RR that is a replacement for the SRV for the cases where one need a URI and not only hostname+port. Otherwise, same syntax and usage as SRV (i.e. prefix of the owner decide the protocol and service etc). It is therefore more a replacement for SRV than replacement for NAPTR (that give back a list of services given a domain name). See draft-faltstrom-uri Patrik, I don't know whether this is a useful contribution to the discussion of this particular document or not, but I am increasingly wondering whether a proliferation of RRs with domain names or URIs as DATA is a good idea. The problem manifests itself in several ways, but perhaps the most important is that, for security purposes, we run into authority problems (and hence meaningful signature ones) as soon as we get into cross-tree pointers. Those problems are most evident with aliases like CNAME and DNAME but, from the cross-tree pointer perspective, MX, NAPTR, and your new proposal may be just aliases on steroids. One could take the position that the horse left the barn with CNAME and MX and that more, and more complex, record types with domain names contained in the DATA don't really change anything, but I'm just not sure. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Patrik Fältström writes: On 17 jul 2010, at 21.39, Joe Touch wrote: Are you suggesting a new RR instead of the SRV or in addition to the SRV? The latter seems useful; the former begs the question of how many SRV variants we would want. A new RR that is a replacement for the SRV for the cases where one need a URI and not only hostname+port. Otherwise, same syntax and usage as SRV (i.e. prefix of the owner decide the protocol and service etc). It is therefore more a replacement for SRV than replacement for NAPTR (that give back a list of services given a domain name). I feel bad about this proposal. When I published the SRV draft, about a dozen people told me they'd wanted such a thing, for very diferent purposes, which made me feel that I was on the right track. For this draft I have the opposite feeling. People are deploying HTTP redirects, pointers in known or computable locations, pointers in link rel tags, etc, etc. See http://www.sitemaps.org/protocol.php#submit_robots for an example. What I can NOT remember is someone posting gee, I wish we had something like SRV but with URIs, that's what we really need. So, I feel rather uncertain that your proposed RR meets a deeply felt need. It might. Or not. I worry that it'll either be unused, or shortly be found to be insufficient. Maybe more people would want an RR containing a URI template in which clients can insert a userid and whatnot? And really, as Joe asks, how many SRV variants would we want? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 18 jul 2010, at 10.27, John C Klensin wrote: Those problems are most evident with aliases like CNAME and DNAME but, from the cross-tree pointer perspective, MX, NAPTR, and your new proposal may be just aliases on steroids. My suggestion in this draft (as explained in the Security Considerations Section of draft-faltstrom-uri) is to have the URI RR secured by DNSSEC, and then SSL cert match the hostname in the URI that you find in the RDATA. 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: TSV-DIR review of draft-daboo-srv-caldav-05
On 7/18/2010 12:14 AM, Patrik Fältström wrote: On 17 jul 2010, at 21.39, Joe Touch wrote: Are you suggesting a new RR instead of the SRV or in addition to the SRV? The latter seems useful; the former begs the question of how many SRV variants we would want. A new RR that is a replacement for the SRV for the cases where one need a URI and not only hostname+port. Otherwise, same syntax and usage as SRV (i.e. prefix of the owner decide the protocol and service etc). That seems to means you use one of two different RRs, depending on the response. I don't see that as a step forward. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
--On Sunday, July 18, 2010 14:55 +0200 Patrik Fältström p...@cisco.com wrote: On 18 jul 2010, at 10.27, John C Klensin wrote: Those problems are most evident with aliases like CNAME and DNAME but, from the cross-tree pointer perspective, MX, NAPTR, and your new proposal may be just aliases on steroids. My suggestion in this draft (as explained in the Security Considerations Section of draft-faltstrom-uri) is to have the URI RR secured by DNSSEC, and then SSL cert match the hostname in the URI that you find in the RDATA. Patrik, I'll try to study your URI draft more carefully before getting to Maastricht, but, based on looking through it a few times, it seems to me that: (1) If the RR contains a domain name outside the zone of its ownername, one essentially loses all hope of using DNSSEC mechanisms for validation. If the URI itself it resolves to an alias, the problem may be no worse, but is harder to think about. I know that you know this already, but it seems to me that the Security Considerations section should address it. From my point of view, adding additional RR types with those properties (to MX, SRV, NAPTR, and arguably CNAME and DNAME) does increase the security risks -- not by adding risks that were not there before, but by making it harder to keep track of and analyze the various risk vectors, especially when these various RR types can have data that points to others of them. YMMD. (2) It seems to me that we may be creating very high expectations in the community for the security and integrity of information in DNSSEC-signed zones that can be validated with a root trust anchor (look at almost any of the recent announcements for examples). While I understand the DNSSEC for the URI RR; TLS/SSL cert for the URI's hostname model mentioned above and described in the I-D, the reality is that many, perhaps most, of the TLS/SSL certs in the world are nearly useless or, to put it more politely, offer a very low level of assurance relative to what people have been encouraged to believe about root-anchored DNSSEC. No luser is going to understand the difference between the two elements of the validation mechanism. Far more likely, the weakest link principle will apply and the expectation of security from DNSSEC will drop to that of the quality of the typical self-signed or prove that you own the domain name by receiving mail TLS/SSL cert. Again, at a minimum, I think your Security Considerations section should analyze and warn about the fragility in practice of the approach you suggest. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 18 jul 2010, at 22.04, John C Klensin wrote: Patrik, I'll try to study your URI draft more carefully before getting to Maastricht, but, based on looking through it a few times, it seems to me that: (1) If the RR contains a domain name outside the zone of its ownername, one essentially loses all hope of using DNSSEC mechanisms for validation. DNSSEC is validating that the URI itself is what did come from the authoritative source. So you know the URI is not fake. That is what you get, regardless of whether the domain name in the URI is in the same or some other domain. Nothing more than that. If the URI itself it resolves to an alias, the problem may be no worse, but is harder to think about. I know that you know this already, but it seems to me that the Security Considerations section should address it. Fair. From my point of view, adding additional RR types with those properties (to MX, SRV, NAPTR, and arguably CNAME and DNAME) does increase the security risks -- not by adding risks that were not there before, but by making it harder to keep track of and analyze the various risk vectors, especially when these various RR types can have data that points to others of them. YMMD. Ok. I think the current resolution mechanism in the daboo-srv-caldav draft also have a very interesting security mechanism as that is relying on a correct SRV plus a redirect in HTTP that can redirect to anything...and in this second step you rely on both the SRV and the HTTP redirect actually refer you to the correct resource. This can be tied down of course if the HTTP redirect and the SRV are bound to: - The SRV not do a referral outside the domain in question - The http redirect is on the same server the SRV referred to But that also removes some interesting flexibility that one might want to do. Like hosting virtual domains at some hosting company. (2) It seems to me that we may be creating very high expectations in the community for the security and integrity of information in DNSSEC-signed zones that can be validated with a root trust anchor (look at almost any of the recent announcements for examples). While I understand the DNSSEC for the URI RR; TLS/SSL cert for the URI's hostname model mentioned above and described in the I-D, the reality is that many, perhaps most, of the TLS/SSL certs in the world are nearly useless or, to put it more politely, offer a very low level of assurance relative to what people have been encouraged to believe about root-anchored DNSSEC. No luser is going to understand the difference between the two elements of the validation mechanism. Far more likely, the weakest link principle will apply and the expectation of security from DNSSEC will drop to that of the quality of the typical self-signed or prove that you own the domain name by receiving mail TLS/SSL cert. Again, at a minimum, I think your Security Considerations section should analyze and warn about the fragility in practice of the approach you suggest. What I think might be needed is that IETF comes up with a proper architecture for the following: An application do have the need to contact a service. The service is identified by a unique identifier that is registered by IANA (that identifies a service) and a domain name. On top of that, there might be a sub-identifier in the form of a unique identifier for a user (i.e. local part in an email address etc). What are the steps the application should go through before it actually opens some connections over IP, and what should it do then to secure the whole thing. We have a number of alternatives: 1. Use MX 2. Use SRV and well known algorithm for the service, using prefixes of the owner 3. Use A and and well known algorithm 4. We have DDDS, using NAPTR with service selection in RDATA if DNS is used as the base database (of various flavours, UNAPTR etc) 5. We have the daboo-srv-caldav that uses SRV plus http redirect from a .well-known path that is used in the HTTP transaction 6. We have TXT records with well known syntax in the RDATA 7. I propose using a SRV-like prefix naming that give back full URIs, and the rest of the resolution have to do with URI resolution Let me state that I do not think we should delay the draft-daboo-srv-caldav IF a work like this is started. If we get some work like this, I suggest letting draft-daboo-srv-caldav pass, given people do not think the solution with an http redirect is too weird. I do not like the mechanism proposed in draft-daboo-srv-caldav. Definitely not. But that is a different thing than requiring rough consensus on a generic way of finding an endpoint of a connection for a service. Luckily, Maastricht is a week from now and we can talk about it. 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: TSV-DIR review of draft-daboo-srv-caldav-05
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 to...@isi.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Hi Joe, --On July 17, 2010 8:19:13 AM -0700 Joe Touch to...@isi.edu wrote: 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. There is supposed to be an RFCEditor note covering the change. 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. 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. 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. 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
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 17 jul 2010, at 21.00, Cyrus Daboo wrote: 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. As I have said before as input to this last call, I think IESG should make a decision whether using such redirects in HTTP is a proper architecture solution to finding out how a service can be reached. I think personally it is not good design. I therefore ask IESG to make a specific decision on this topic, and not just say ok or not ok on the draft in question. 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: TSV-DIR review of draft-daboo-srv-caldav-05
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
On 17 jul 2010, at 21.27, Joe Touch wrote: The appropriate solution for a port discovered via SRV records is to use TXT records. And, for the ones that have not followed the whole history of this last call, my view is that a new RR type is needed, and I propose a URI resource record that as RDATA have the full URI to the resource in question. 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: TSV-DIR review of draft-daboo-srv-caldav-05
Patrick, Are you suggesting a new RR instead of the SRV or in addition to the SRV? The latter seems useful; the former begs the question of how many SRV variants we would want. Joe On 7/17/2010 12:33 PM, Patrik Fältström wrote: On 17 jul 2010, at 21.27, Joe Touch wrote: The appropriate solution for a port discovered via SRV records is to use TXT records. And, for the ones that have not followed the whole history of this last call, my view is that a new RR type is needed, and I propose a URI resource record that as RDATA have the full URI to the resource in question. Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Hi Joe, --On July 16, 2010 2:55:42 PM -0700 Joe Touch to...@isi.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. 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
