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
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 A
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 tim
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 f
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
f
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, 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 not
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
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 o
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 wo
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
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,
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
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
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
namedr
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
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 de
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
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
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
>an
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
> submit
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 en
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
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-HTT
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. Wh
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 t
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
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
_
> 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
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
[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
32 matches
Mail list logo