On May 7, 2021, at 3:21 AM, Pieter Lexis <pieter.le...@powerdns.com> wrote:
> 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.
Pieter has a point here: to parse correctly, you need a two-step (or two-level) 
process. The *only* way to prevent that in the spec would be to say that commas 
are forbidden in  parameter values. However, even if the spec said that, 
someone would mess up and put a comma in a parameter value, and then different 
parsers will yield different values based on whether or not they took that 
shortcut.

Escaping is hard.

--Paul Hoffman

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