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:
>> But that is precisely what you are NOT doing.
>> You have assigned a special significance to the character sequence
>> "\\," contrary to RFC1035.
>>
>> The language of RFC1035 is crystal clear that an escaped character is
>> parsed as plain text, independently, without regard to context, and
>> that any special meaning does not apply.
>>
>> Strict application of the RFC1035 rules causes string "...\\,..."
>> to be equivalent to "...\092,...".
>
>
> I'm not sure what you're describing. Those two inputs are universally
> equivalent in zone files under the current draft. They are both reduced to
> {'\', '"'} by char-string parsing, which is applied uniformly and without
> modification to all SvcParamValues.
... and the '\' without any special meaning fails to protect the comma
from the attention of the argument splitter.
> Each SvcParamValue has its own input format. For some SvcParamValues, '\'
> and ',' may not be allowed characters. For others, they may be ordinary
> characters to be copied into the output, or they may have special
> significance.
>
... and I might, or might not, have a boiled egg for breakfast!
>> 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.
>
> The "value-list" format is a bit like a (much simpler) cousin of the SPF
> macro language (https://tools.ietf.org/html/rfc7208#section-7.1). In both
> cases, the char-string decoder's output contains embedded commands that allow
> the next processing stage to distinguish between delimiters (comma and space,
> respectively) and escaped delimiters ("\," and "%_", respectively).
That is no justification at all. SPF people can do whatever they
like within the arguments of a TXT record.
--Dick
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
