On Thu, May 6, 2021 at 8:50 AM Dick Franks <rwfra...@gmail.com> wrote:

> On Tue, 4 May 2021 at 21:18, Ben Schwartz <bem...@google.com> wrote:
>
...

> >> For the sanity of all concerned, SVCB should adhere to the same
> >> standard RFC1035 escape conventions as the other 50+ RRTYPEs.
> >
> > I think that's a good description of why this arrangement was chosen.
>
> 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.

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.

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 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.

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).

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to