Hi folks,
On 5/6/21 10:16 PM, Dick Franks wrote:
> On Thu, 6 May 2021 at 19:11, Ben Schwartz <bem...@google.com> wrote:
>> On Thu, May 6, 2021 at 8:50 AM Dick Franks <rwfra...@gmail.com> wrote:
>>> BIND, NSD, and Net::DNS are all able to arrive at implementations of
>>> SVCB using the RFC1035 standard escape conventions, which demonstrates
>>> beyond reasonable doubt that recognising "\\," is not an essential
>>> requirement.
>>
>> I disagree: what you are proposing is a deviation from RFC1035 escape
>> conventions, and what the draft does is specifically to ensure that no such
>> deviation is required.
>
> I am advocating strict adherence to RFC1035 escape conventions. You
> are the one proposing to deviate.
>
>> ... I have now encountered multiple codebases where modifying the RFC1035
>> char-string parsing in the way that you suggest would be prohibitively
>> complex, and that complexity will only grow over time as new SvcParamValues
>> are defined.>
> If the development cost is prohibitive, the obvious solution is to use
> BIND, NSD, or one of the other respectable implementations which are
> certain to be not far behind. If Google cannot afford the license
> fee, a six line perl Net::DNS script could be used to translate
> RFC1035 compliant SVCB RRs into RFC3597 format at nil cost.
, respectively).
> [...]
> That is no justification at all. SPF people can do whatever they
> like within the arguments of a TXT record.
For PowerDNS, we treat the parsing of SVCParams as a two-step process.
First we use the normal rfc1035 character decoder on the full SVCParam
value, after which we apply the value-list parser. The former parses
'foo\\,bar' into 'foo\,bar' that is then parsed to a list of length 1
with value {'foo,bar'}. So nothing changes from the perspective of the
rfc 1035 parser.
I can see how this might be confusing to those writing zone contents and
would support a solution that either prohibits comma's in SVCParam list
values or a different value separator that is not allowed to be embedded
in values.
Regards,
Pieter
--
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
