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
[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
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
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
Hi Paul,
--On June 24, 2010 8:59:18 AM -0700 Paul Hoffman paul.hoff...@vpnc.org
wrote:
As someone who normally has that different view, I support a new RRTYPE
in this case because the option of reusing SRV is not sufficient: it
requires DNS-SRV-followed-by-HTTP. I think a new RRTYPE that
At 12:24 PM -0400 6/24/10, Cyrus Daboo wrote:
Hi Paul,
--On June 24, 2010 8:59:18 AM -0700 Paul Hoffman paul.hoff...@vpnc.org wrote:
As someone who normally has that different view, I support a new RRTYPE
in this case because the option of reusing SRV is not sufficient: it
requires
Hi Patrik,
--On June 24, 2010 6:32:48 PM +0200 Patrik Fältström p...@cisco.com
wrote:
in this case as in the draft under discussion? If so, I don't don't
understand your position. The protocols/services being referenced by the
draft are HTTP protocols, so it is always going to be
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
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
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
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
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
Hi Patrik,
--On June 23, 2010 8:52:45 PM +0200 Patrik Fältström p...@cisco.com
wrote:
In principle, example.com is the proper domain to authenticate, but in
practice, that causes a lot of problems. Consider the case where the
target of the redirection is a separate entity from the origin;
Hi Patrik,
--On June 22, 2010 8:54:22 AM +0200 Patrik Fältström p...@cisco.com
wrote:
I have together with Olaf Kolkman suggested a new RR type that I call URI
that work similarly to what is described in this draft (regarding the
owner of the RRSET), but a URI in the RDATA. It has been
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
Hi Patrik,
--On June 23, 2010 10:07:44 PM +0200 Patrik Fältström p...@cisco.com
wrote:
I did chat with a few server implementors about this and the feeling was
SRV + .well-known is a good solution that can quickly be deployed. Some
points:
1) SRV's are very deployable today - a new RR will
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
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
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
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
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
At 08:51 18-06-10, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Use of SRV records for locating CalDAV and CardDAV services '
draft-daboo-srv-caldav-05.txt as a Proposed Standard
The IESG plans to make a decision in the
SM wrote:
At 08:51 18-06-10, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Use of SRV records for locating CalDAV and CardDAV services '
draft-daboo-srv-caldav-05.txt as a Proposed Standard
The IESG plans to make a
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
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
The IESG has received a request from an individual submitter to consider
the following document:
- 'Use of SRV records for locating CalDAV and CardDAV services '
draft-daboo-srv-caldav-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
26 matches
Mail list logo
