> On 11 May 2021, at 02:56, Ben Schwartz <bemasc=40google....@dmarc.ietf.org>
> wrote:
>
> I don't support breaking the SvcParams into separate RRs across the RRSet.
> This would be an extremely inefficient encoding in wire format, and would
> conflict with the usual understanding of resource records as independently
> meaningful alternatives. It would also require a dramatic rewrite of a
> specification that is now widely deployed.
>
> As for the question of commas, I continue to believe that the current text is
> preferable. I believe that the behavior Dick is advocating for is in fact
> the one that was present in the draft until -02 [1], changed here [2]. We
> changed this text after receiving complaints from WG members that the
> algorithm as specified was too complicated, along with my own experiences
> attempting to implement it in multiple codebases that apply char-string
> decoding during or before tokenization.
>
> The key question is: how is the zone file parsing supposed to work? I see
> two main options:
>
> One-pass (draft-02):
> 1. Read the key name up to an "="
> 2. Load a parser whose behavior depends on the key name
> 3. Feed this parser characters from the zone file until it declares
> completion or error
>
> Two-pass (more recent drafts):
> 1. Read the key name up to an "="
> 2. Parse the value as a char-string
> 3. Pass the char-string parser output to the a key-specific parser for deeper
> processing
>
> In one-pass parsing, comma-separated value (CSV) lists are like dot-separated
> domain names: first-class entities whose delimiter escaping is fully
> integrated into the parsing. In two-pass parsing, CSV format is an
> implementation detail of particular SvcParam registrations, encoded as data
> inside plain char-strings in the zone file.
>
> To see why I favor two-pass, consider a SvcParam whose wire format value is
> defined to be CBOR, represented as JSON in the zone file. JSON is defined as
> UTF-16, and allows strings containing any character from the Basic
> Multilingual Plane. It also allows various kinds of backslash escaping
> including " \" " for quotes within strings, and "\uD834\uDD1E" for extended
> unicode codepoints. A one-pass parser must somehow integrate this into the
> flow of zone file parsing. The easiest way is to simply disable all
> RFC1035-style escapes and line-breaks for the duration of the SvcParamValue,
> but this is a major breach of standard zone file practice, and raises
> questions about how to store UTF-16 characters in a zone file.
> Alternatively, we could somehow combine both RFC1035 and JSON escaping, but
> if this is even possible, it would seem to require writing a new RFC1035+JSON
> hybrid parser. I also think these behaviors would be confusing to users, who
> would have to try to understand how thi
s new integrated escaping works in order to author zone files containing
either kind of escape.
Yet you fail to mention that the following
3. Encoding
JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8.
The UTF-16 JSON strings values are encoded as UTF-8. UTF-8 in zone files
usually ends up being \DDD for non-ASCII and ASCII control octets once it has
gone from text -> wire -> text to put everything into ASCII printable. Zone
files are ASCII documents. If you are using the values in other contexts you
may convert the
wire forms differently.
> In two-pass parsing, this is trivial. One simply parses the value as a
> char-string, and feeds the output to a JSON parser. The resulting
> double-escaping may be unattractive, but is commonplace when working with
> structured data inside a string.
>
> Another point in favor of two-pass parsing: it makes unknown keys "value
> errors" instead of "syntax errors". In one-pass parsing, when the parser
> encounters an unrecognized SvcParamKey, it must stop and fail immediately.
> It cannot proceed, because it cannot even continue tokenizing.
>
> [1]
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-02#appendix-A.1
> [2] https://github.com/MikeBishop/dns-alt-svc/pull/282
>
>
> On Mon, May 10, 2021 at 8:35 AM Joe Abley <jab...@hopcount.ca> wrote:
> Hi Pieter,
>
> On 10 May 2021, at 11:23, Pieter Lexis <pieter.le...@powerdns.com> wrote:
>
>> You then invite the following issues:
>>
>> Clients need to match the tuple (ownername + prio + target) and get all
>> data from all matched rrsets, whereas now you get all that data in one
>> piece of rdata.
>
> Inviting that issue is also a potential benefit, but I agree that the
> implication exists. For example, the ability to publish sets of SvcParams
> with long TTLs ought to increase the probability of cache hits for that data
> and reduce SVCB response sizes.
>
>> A client also can't figure out (if not doing DNSSEC valdiation
>> themselves) if you have received all the SVC data for a certain name.
>
> A client can't figure out without DNSSEC whether anything they have received
> is correct in, in general. So setting aside that more general authentication
> problem, I don't think it's correct to say that a client cannot tell whether
> they have received a complete RRSet in the answer section of a response. It's
> either there and complete or it's absent (and perhaps TC=1 if the reason for
> its absence is message truncation).
>
> There should be no response possible in an implementation that adheres to the
> protocol in which a truncated RRSet appears in the answer section. If we're
> widening the net to implementations that don't follow the rules then I agree
> anything is possible.
>
>
> Joe
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
