Seriously, it's not obvious to me that it's *impossible* to change.
Of course it's not impossible. But the question is whether the benefit
from the change is large enough that the people who'd have to write the
software will do so.
IPv4 DNSBLs have been working just dandy with A records for
On Fri, Nov 14, 2008 at 01:38:54PM -0800, Ted Hardie wrote:
> If we are documenting practice and nothing more, then the publication
> stream can move to informational and text can be added on why
> a new RR, which would normally be expected here, is not being used
> (essentially, inertia in the fac
On Nov 14, 2008, at 1:38 PM, Ted Hardie wrote:
If we are documenting practice and nothing more, then the
publication stream can move to informational and text can be added
on why a new RR, which would normally be expected here, is not being
used (essentially, inertia in the face of 15 year
At 10:56 AM -0800 11/14/08, John L wrote:
> > Sorry, what about SRV made RRTYPE not significant? Sorry
>> to be dense, but I don't understand your point here.
>
>A SRV record with _tcp in its name means something different from a SRV
>query with _udp in its name. I suppose you could argue that's
context for the RRTYPE based on the zone of the query, which is not
what the DNS currently uses for disambiguating the types of
requests/responses.
Didn't that plan go out the window in 1996 with RFC 2052?
Sorry, what about SRV made RRTYPE not significant? Sorry
to be dense, but I don't under
At 8:17 AM -0800 11/14/08, Tony Finch wrote:
>
>Note that I'm not arguing against a new RR type, I'm just trying to
>understand the arguments against the de facto standard.
>
>One significant advantage which I have not seen clearly articulated is
>that a new RR type could combine the functions that
At 5:06 AM -0800 11/14/08, John Levine wrote:
> >The whole approach here is "An A record in this zone has a meaning
>>different from the meaning in other zones". That creates a DNS
>>context for the RRTYPE based on the zone of the query, which is not
>>what the DNS currently uses for disambiguatin
On Fri, 14 Nov 2008, Hardie, Ted wrote:
>
> Since you now have two different meanings for what an A record is, you
> now need two different code trees that understand what A records are,
> and those code trees are not interoperable.
What do you mean by "interoperable" here? What would it mean for
From: Tony Finch [EMAIL PROTECTED] On Behalf Of Tony Finch [EMAIL PROTECTED]
Sent: Friday, November 14, 2008 4:11 AM
To: Hardie, Ted
Cc: Andrew Sullivan; ietf@ietf.org
Subject: Re: Context specific semantics was Re: uncooperative DNSBLs, was
several
>The whole approach here is "An A record in this zone has a meaning
>different from the meaning in other zones". That creates a DNS
>context for the RRTYPE based on the zone of the query, which is not
>what the DNS currently uses for disambiguating the types of
>requests/responses.
Didn't that pl
On Thu, 13 Nov 2008, Ted Hardie wrote:
>
> That's an example in which an A record in this zone has the standard DNS
> meaning and the expectation is that you can use it construct a URI.
> The other A records have a specific meaning in which the data returned
> indicates that indicates something abo
At 12:08 PM -0800 11/13/08, Ted Hardie wrote:
> The other A records have
>a specific meaning in which the data returned indicates that indicates
>something about
>its reputation in a specific context (what reputation etc. being context
>specific). One
>of these things is not like the other. Usi
12 matches
Mail list logo
