Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard

[Cullen Jennings]

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 '
>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_id&dTag=18589&rfc_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

Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard

[Patrik Fältström]

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 '
>>   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_id&dTag=18589&rfc_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

[Paul Hoffman]

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

[Patrik Fältström]

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

[SM]

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

[Alexey Melnikov]

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

[SM]

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

[Alexey Melnikov]

SM wrote:


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


That was done as an RFC Editor note.

___
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

[Thomson, Martin]

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

Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard

[Patrik Fältström]

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

[Richard L. Barnes]

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.


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 where example.com has  
outsourced its calendaring services to calendardserverfoobar.com.   
Then requiring the target domain to authenticate as the origin (i.e.,  
as example.com) means that you're enabling the outsourced calendaring  
provider to authenticate as their customer, which requires them to  
keep different keys for each customer and present different certs on  
different connections (which may or may not be feasible depending on  
how customer resources are distributed in the provider infrastructure)  
-- and invites the risk of abuse.


On top of that, there's the implementation issue that a lot of  
libraries (for HTTP, but others as well) don't let you authenticate  
any identifier than the domain name in the URI.


One flavor of this problem is being worked in XMPP now.  They're  
creating Domain Name Assertions so that the origin domain can create a  
signed object attesting to the delegation and the target domain can  
authenticate as itself.



But it's clearly a more general problem.  Stpeter and I are planning  
to organize a bar BoF about it in Maastricht, but in the spirit of  
having more ad-hoc bar BoFs, we haven't done any concrete planning.


--Richard


___
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

[Patrik Fältström]

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

[Richard L. Barnes]

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

[Cyrus Daboo]

Hi Patrik,

--On June 23, 2010 8:52:45 PM +0200 Patrik Fältström  
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

[Cyrus Daboo]

Hi Patrik,

--On June 22, 2010 8:54:22 AM +0200 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...

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

[Patrik Fältström]

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

[Cyrus Daboo]

Hi Patrik,

--On June 23, 2010 10:07:44 PM +0200 Patrik Fältström  
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

[Paul Hoffman]

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

[Patrik Fältström]

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

[Paul Hoffman]

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

[Patrik Fältström]

On 23 jun 2010, at 22.07, Patrik Fältström wrote:

> A new version of my draft I promised today, but due to this security 
> consideration discussion, it is now delayed yet another day.

The new draft is now posted:

> A new version of I-D, draft-faltstrom-uri-05.txt has been successfully 
> submitted by Patrik Faltstrom and posted to the IETF repository.
> 
> Filename:  draft-faltstrom-uri
> Revision:  05
> Title: The Uniform Resource Identifier (URI) DNS Resource 
> Record
> Creation_date: 2010-06-24
> WG ID: Independent Submission
> Number_of_pages: 12
> 
> Abstract:
> This document defines a new DNS resource record, called the Uniform
> Resource Identifier (URI) RR, for publishing mappings from hostnames
> to URIs.

   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

[Cyrus Daboo]

Hi Paul,

--On June 24, 2010 8:59:18 AM -0700 Paul Hoffman  
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

[Patrik Fältström]

On 24 jun 2010, at 18.24, Cyrus Daboo wrote:

> --On June 24, 2010 8:59:18 AM -0700 Paul Hoffman  
> 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).

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.

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. Secondly, what I "do not like" in the draft-daboo-srv-caldav is 
that you need an explicit well known path that one tag onto the URI. Virtual 
hosting (given normal http hosts) might be "interesting"...but of course, 
someone will hack an .htaccess together that give the right redirect given the 
HOST header... But I think that is "uglier" (note the quotes) than a new RR 
Type. YMMV...

   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

[Paul Hoffman]

At 12:24 PM -0400 6/24/10, Cyrus Daboo wrote:
>Hi Paul,
>
>--On June 24, 2010 8:59:18 AM -0700 Paul Hoffman  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

[Cyrus Daboo]

Hi Patrik,

--On June 24, 2010 6:32:48 PM +0200 Patrik Fältström  
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

[Patrik Fältström]

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

[Peter Saint-Andre]

On 6/24/10 1:47 PM, Patrik Fältström wrote:
> 
> 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?

That's often the case for xmpp URIs.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Patrik Fältström]

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

[Ray Bellis]

> 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

Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard

[Phillip Hallam-Baker]

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  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 '
> >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_id&dTag=18589&rfc_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

[Phillip Hallam-Baker]

[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

[Phillip Hallam-Baker]

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