Hi Mark,
Please see inline.
>> Q2_1: There is no ABNF for the header field. There are examples using
>> both quotes ("/{username}") and angle brackets
>> (</books/{book_id}/author>), so please include the ABNF.
>
> This is a Structured Field; in the HTTP community, we've agreed that
> documenting them with ABNF is not good practice.
Gotha.
(I was comparing this to RFC 8288, and assumed that you still would have to
define the ABNF, following the rules of [STRUCTURED-FIELDS])
But, then I have the following question:
Section 2 says: "Its value is a List of Strings. Each String is a URI
Template..."
According to [STRUCTURED-FIELDS]), the syntax for String is: sf-string =
DQUOTE *chr DQUOTE
>From the example in Section 2, </books/{book_id}/author> does not follow that
syntax, does it? You must use DQUOTEs.
----
>> Q2_2: The text says "Parameter values MUST be Strings."
>>
>> It is unclear what "Strings" means. Does it mean that parameter values
>> must be encoded as quoted-strings? If so, why? RFC8288 says that
>> parameter values can be encoded both as token and quoted-string.
>
> S 1.1: "This specification uses the following terms from
> [STRUCTURED-FIELDS]: List, String, Parameter."
Yes. But, in Section 3.1.2 of [STRUCTURED-FIELDS] there is no restriction that
the Parameter value must by String. My question is why you are making that
restriction, instead of just allowing the different Parameter value encodings
defined in [STRUCTURED-FIELDS]?
Regards,
Christer
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
