Subject: TSV-DIR review of draft-daboo-srv-caldav-05

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jul 2010 14:55:42 -0700

Hi, all,

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

We would expect that the service names "caldev", "caldevs", "carddev", 
and "carddevs" would need to be registered in the SRV registry, which is 
being unified with the IANA ports registry as per pending BCP 
draft-ietf-tsvwg-iana-ports. None of these strings is registered in the 
current SRV registry. See the note #2 below.

The use of these strings inside the SRV records is consistent with the 
description in the pending BCP draft-ietf-tsvwg-iana-ports.

Some issues to discuss:

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.

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.

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.

I don't see any other significant transport issues. It is always useful 
to note that short, multibyte transactions benefit from TCPs with Nagle 
disabled, but that is not a critical issue.

I'd be glad to discuss this further on whatever list would be useful.

Joe

---------------------

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 16 Jul 2010 21:11:23 -0400

Hi Joe,

> and caldevs (Sec 3); a corresponding section for carddev and carddevs

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.

> 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.
>

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)
> 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

---

From: Joe Touch <[email-masked]>
Date: Sat, 17 Jul 2010 08:19:13 -0700

Hi, Cyrus,

On 7/16/2010 6:11 PM, Cyrus Daboo 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.

> 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.

> 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

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 17 Jul 2010 15:00:48 -0400

Hi Joe,

> carddev/carddevs strings be added to the SRV registry.

There is supposed to be an RFCEditor note covering the change.

> 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).
>

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.

> 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.
>

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 CardDAV clients to quickly 
find the paths to their relevant services.

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.

-- 
Cyrus Daboo

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 17 Jul 2010 21:17:13 +0200

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

---

From: Joe Touch <[email-masked]>
Date: Sat, 17 Jul 2010 12:27:38 -0700

Hi, Cyrus,

On 7/17/2010 12:00 PM, Cyrus Daboo wrote:
...
> 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.

> 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
> 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

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

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 17 Jul 2010 21:33:41 +0200

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

---

From: Joe Touch <[email-masked]>
Date: Sat, 17 Jul 2010 12:39:55 -0700

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

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 18 Jul 2010 09:14:37 +0200

On 17 jul 2010, at 21.39, Joe Touch wrote:

> 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

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 Jul 2010 04:27:25 -0400

--On Sunday, July 18, 2010 09:14 +0200 Patrik Fältström
<[email-masked]> wrote:

> 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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 18 Jul 2010 13:17:22 +0200

Patrik Fältström writes:
> 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

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 18 Jul 2010 14:55:38 +0200

On 18 jul 2010, at 10.27, John C Klensin wrote:

> Those problems are most evident with

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

---

From: Joe Touch <[email-masked]>
Date: Sun, 18 Jul 2010 10:17:15 -0700

> 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

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 Jul 2010 16:04:45 -0400

--On Sunday, July 18, 2010 14:55 +0200 Patrik Fältström
<[email-masked]> wrote:

> 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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 19 Jul 2010 04:42:51 +0200

On 18 jul 2010, at 22.04, John C Klensin wrote:

> 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

Fair.

> various RR types can have data that points to others of them.

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.

> 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 AAAA 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

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 19 Jul 2010 10:07:53 -0400

Hi Patrik,

--On July 19, 2010 4:42:51 AM +0200 Patrik Fältström <[email-masked]> 
wrote:

> 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.
>
> 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.

> "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."
>
> 2. Use SRV and well known algorithm for the service, using prefixes of
> the owner 3. Use A and AAAA 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 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.
>

I'm up for that.

-- 
Cyrus Daboo

---

From: John C Klensin <[email-masked]>
Date: Mon, 19 Jul 2010 10:13:06 -0400

--On Monday, July 19, 2010 04:42 +0200 Patrik Fältström
<[email-masked]> wrote:

> "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."
> 
> 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 
> 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.

> 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

In our collective copious spare time.

    john

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 19 Jul 2010 16:13:59 +0200

On 19 jul 2010, at 16.07, Cyrus Daboo wrote:

> 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? Arghhhh... Not better.

Why, why, why?

>> Luckily, Maastricht is a week from now and we can talk about it.

Excellent. Interested parties should try to meet.

   Patrik

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Jul 2010 08:34:11 -0700

On 7/18/2010 11:05 AM, Patrik Faltstrom (pfaltstr) wrote:
> On 18 jul 2010, at 19:18, "Joe Touch"<[email-masked]>  wrote:
>
>> That seems to means you use one of two different RRs, depending on the response.
>>
> 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

---

From: "Patrik Faltstrom (pfaltstr)" <[email-masked]>
Date: Sun, 18 Jul 2010 20:05:42 +0200

> 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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 19 Jul 2010 17:51:04 +0200

On 19 jul 2010, at 17.34, Joe Touch wrote:

> 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