I think there's an implementation difficulty. Consider:
1. alpn=h2 ; clear enough
2. alpn="h2" ; should be equivalent
3. alpn=\h\2 ; should also be equivalent
4. alpn=h2,h3 ; ok (two values)
5. alpn="h2","h3" ; should be equivalent
6. alpn="h2,h3" ; malformed? or a single alpn value of h2,h3? or two
three-character values, "h2 and h3"?
7. alpn=h2\,h3,h4 ; how should this be parsed?
Section 2.1.1 tempts one to build the obvious implementation of using one's
existing character-string parser, and then passing the parsed character-string
to the individual handler for each key type. The alpn and ipv*hint handlers are
going to want to split that character-string on comma. That would treat #6 as
two two-character values (h2,h3). But #7 is problematic: the generic
character-string parser would remove the backslash, and then the alpn handler
would treat this as three alpn values when you probably wanted just two.
We could make a special character-string parser for alpn and ipv*hint, that
handles commas, but it feels odd to have to use a special parser just for
certain key types. However, if we must allow commas in alpn names, then we have
no choice.
Perhaps it would be clearer to simply remove the three paragraphs of section
2.1.1 beginning with "The presentation for for SvcFieldValue is..." and ending
with "...not limited to 255 characters.)". Since the previous paragraph says
"Values are in a format specific to the SvcParamKey", perhaps it would be best
to leave the description of each value format in the appropriate part of
section 6 and for section 2.1.1 to discuss only how to represent and parse
unrecognized keys.
To keep the implementation simple, the alpn value could be defined as a
comma-separated list of sequences of printing ASCII characters, with embedded
comma represented as \, backslash as \\, and all nonprinting and non-ASCII
characters reprsented as \nnn. (In other words, the full generality of
character-string, particularly double-quotes, is not needed here.
The other comma-separated value types -- ipv4hint and ipv6hint -- do not have
this difficulty; they also don't need the full generality of character-string
handling, because the individual values can contain only hex digits, periods,
and colons, so their specification and implementation can be much simpler.
And I think section 2.1.1 would be clearer if
using decimal escape codes (e.g. \255) when necessary
were replaced by
using decimal escape codes (e.g. \255) for all nonprinting and non-ASCII
characters, and using \\ to represent backslash
- lc
> On Jun 13, 2020, at 11:25, Ben Schwartz <bemasc=40google....@dmarc.ietf.org>
> wrote:
>
> Larry,
>
> I think that's the intent of the current text, especially the ABNF for
> "element". If you think it's unclear, we should adjust it. Please suggest
> text!
>
> --Ben Schwartz
>
> On Sat, Jun 13, 2020, 10:53 AM Larry Campbell
> <lcampbel=40akamai....@dmarc..ietf.org> wrote:
> Seciont 6.1 says:
>
> > The presentation value of "alpn" is a comma-separated list of one or more
> > "alpn-id"s. Any commas present in the protocol-id are escaped by a
> > backslash:
> >
> > escaped-octet = %x00-2b / "\," / %x2d-5b / "\\" / %x5D-FF
> > escaped-id = 1*(escaped-octet)
> > alpn-value = escaped-id *("," escaped-id)
>
> If I read this correctly, the presentation value is allowed to contain nulls
> and control characters. This seems likely to make such records very difficult
> to edit. Wouldn't it be better to require these to be encoded as \nnn?
>
> - lc
>
> _______________________________________________
> 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
