On 03/Mar/12 00:13, John R. Levine wrote:
Until provisoning systems accept UNKNOWN record types they will
always be a bottle neck. Without that you will have to wait for
the change request to be processed. Given the history just getting
records added to most of these system it will be
On 03/Mar/12 00:13, John R. Levine wrote:
Until provisoning systems accept UNKNOWN record types they will
always be a bottle neck. Without that you will have to wait for
the change request to be processed. Given the history just getting
records added to most of these system it
On 3 mar 2012, at 16:56, ned+i...@mauve.mrochek.com wrote:
Doubtful. If a record needs to have, say, a priority field, or a port number,
given the existence of MX, SRV, and various other RRs it's going to be very
difficult for the designers of said field to argue that that should be done as
ned+i...@mauve.mrochek.com wrote:
Given that, designers of new RR types will want to stick to string
formats just to spare ISPs some parsing, at the cost of losing a half
of the advantages that RFC 5507 talks about, along with syntactic
validations aimed at preventing some permerror/permfail
On Saturday, March 03, 2012 05:05:08 PM Patrik Fältström wrote:
On 3 mar 2012, at 16:56, ned+i...@mauve.mrochek.com wrote:
Doubtful. If a record needs to have, say, a priority field, or a port
number, given the existence of MX, SRV, and various other RRs it's
going to be very difficult for
� wrote:
On 3 mar 2012, at 16:56, ned+i...@mauve.mrochek.com wrote:
Doubtful. If a record needs to have, say, a priority field, or a port number,
given the existence of MX, SRV, and various other RRs it's going to be very
difficult for the designers of said field to argue that that should be
On 3 mar 2012, at 16:56, ned+i...@mauve.mrochek.com wrote:
Doubtful. If a record needs to have, say, a priority field, or a port
number,
given the existence of MX, SRV, and various other RRs it's going to be very
difficult for the designers of said field to argue that that should be
Doubtful. If a record needs to have, say, a priority field, or a port number,
given the existence of MX, SRV, and various other RRs it's going to be very
difficult for the designers of said field to argue that that should be done
as
ASCII text that has to be parsed out to use.
Agree with
Hi,
I agree with the proposal that Russ Housley made, below, but before even
provisionally granting G.8113.1 a code point by placing draft-betts in the RFC
editor's queue until G.8113.1 is approved, I would like to understand whether
there is a reasonable chance for it to be approved at WTSA
John Levine wrote:
Now mail clients parse
multiple SPF and DKIM records on every mail transaction and nobody
cares.
Well., its not like anyone really had a choice.
SPF is still maturing with its RR type, DKIM didn't bother, and now
also have VBR, ADSP and now ATPS and then DMARC (all
This draft also defines the MT-Priority header field. �It is quite unusual
for a SMTP extension specification to define a mail header field. ...
This is my major concern about this protocol as well, as I note in the
PROTO writeup (which, unfortunately, can't be seen publicly because of
a
Russ hi,
I think many concerns were raised on draft-betts itself, so I think we
should first look at these comments
Concerning G.8113.1, as mentioned before as it was disapproved, it is
clear that there was no consensus. It will be good to understand what
are the issues...the code point was
12 matches
Mail list logo
