what this means is, if someone sees _TCP in use for some rr type, and they
needed something like this for their own new rr type, they should be
encouraged to either use _TCP if they find it's the best fit, or use
something else if they find that a best fit. they should not worry either
away abo
John R. Levine wrote:
Catching up:
...
if you view the use of _tcp by more than one rrtype as a coincidence
rather than as evidence for the need for a registry, then we can
simply define the global registry out of existence (where it has been
until now) and ensure that every rrtype's registry
Catching up:
Assuming we agree that the table also says where to find the registry
for second level names, this removes and need for special cases. The top
level names _tcp _udp _sctp _dccp all work for SRV and URI and take
service names on the second level.
if you view the use of _tcp by
On 3/29/2018 3:38 PM, Adam Roach wrote:
I still don't fully understand the nature of the objections I cite above
or the assertions that having separate tables for different RRTYPEs is
somehow broken. Based on my (admittedly lay) understanding of how DNS is
used by other protocols, I agree with
On 3/29/18 5:02 PM, John C Klensin wrote:
However, I believe that this discussion is, however
unintentionally, a distraction from a far more important issue.
The way the DNS, and particularly DNS queries, are defined makes
the idea of a namespace for all labels starting with "_" very
difficult an
--On Thursday, March 29, 2018 22:00 +0100 Warren Kumari
wrote:
> On Thu, Mar 29, 2018 at 9:52 PM, Dave Crocker
> wrote:
>> On 3/29/2018 1:45 PM, Warren Kumari wrote:
>>>
>>> I don't want to get into if this is the*right* behavior or
>>> not, but it seems like worth mentioning in the draft as
On 3/26/2018 8:18 AM, Martin Hoffmann wrote:
Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and
OPENPGPKEY all use underscore labels and are currently missing
from the initial table in section 3.1.
Added TLSA to the next version of the draft.
d/
--
Dave Crocker
Brandenburg Intern
On 26/03/2018 20:49, John R. Levine wrote:
> Assuming we agree that the table also says where to find the registry
> for second level names, this removes and need for special cases. The
> top level names _tcp _udp _sctp _dccp all work for SRV and URI and take
> service names on the second level.
John R. Levine wrote:
...
Assuming we agree that the table also says where to find the registry
for second level names, this removes and need for special cases. The top
level names _tcp _udp _sctp _dccp all work for SRV and URI and take
service names on the second level.
if you view the use
| _spf| TXT | [RFC7208] | <-
That's just a mistake. Take it out.
Apropos of John K's comment about per-type names, he's right. Given that
people can do whatever they want I have to agree that if people want to
define names that way, we can't prohibit them.
Assuming we a
On Mon, Mar 26, 2018 at 7:38 AM, John C Klensin wrote:
>
> . . .Table 1 of the I-D is
>
> +-+-++
> | _NODE NAME | RR | REFERENCE |
> +-+-++
> | _tcp| SRV | [RFC2782] |
> | _udp| SRV | [RFC278
Dave Crocker wrote:
>
> On 3/26/2018 8:18 AM, Martin Hoffmann wrote:
> > Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and
> > OPENPGPKEY all use underscore labels and are currently missing
> > from the initial table in section 3.1.
>
>
> The table there is for the right-most unde
On 3/26/2018 8:18 AM, Martin Hoffmann wrote:
Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and
OPENPGPKEY all use underscore labels and are currently missing
from the initial table in section 3.1.
The table there is for the right-most underscore name, which RFC 6698
seems to con
13 matches
Mail list logo