[core] Genart last call review of draft-ietf-core-links-json-07

[Elwyn Davies]

Reviewer: Elwyn Davies
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-core-links-json-07
Reviewer: Elwyn Davies
Review Date: 2017-04-25
IETF LC End Date: 2017-04-21
IESG Telechat date: 2017-04-27

Summary:Not ready for publication. There a number of issues that need
to be addressed as discussed below. In particular whether the
formats could be returned as the web link specification instead of RFC
6990 format in response to a GET /.well-known/core request.

Having thought about the quote stripping/addition issue cited in Adam
Roach's DISCUSS, I would take a slightly different view... see below.

Major issues:

Intentions:
Is it one of the intentions of this draft that a server should be able
to return web link descriptions using JSON or CBOR, specifically in
response to GET /.well-known/core? Content formats for the new
formats are registered (s3.2) - could a user ask for the alternative
formats by specifying at ct filter with the GET request? It strikes
me that if one has a constrained server of sufficiently limited
capabilities that it wants to use CBOR then having to encode the RFC
6690 format responses for the web links requests is wasting resources.
Some more thought needs to be given to this as an update to RFC 6690
- If I read correctly, RFC 6690 implicitly requires that a response to
GET /.well-known/core MUST be encoded as described in RFC6690.

Minor issues:
Title: The document appears only to address the CoRE Web Links format
rather than any other. Should the title reflect this more precisely,
e.g.,
Representing CoRE Web Links Format in JSON and CBOR

s1.1: Concerning:
o The simplest thing that could possibly work

* Do not cater for RFC 5988 complications caused by HTTP
header
character set issues [RFC2047]

Having ferreted around in RFC 5988 and RFC 2047, I can't see what is
being referred to here. However, I observe later that the "title*"
attribute (with language specifier) does not appear to be supported
(It is missing from Table 1) - is this what is relevant here? If so it
needs clarification.
[Aside: I notice that the relevant ABNF in s5 of RFC 5998 is missing
external references to various productions (e.g., ext-value,
quoted-string) that are defined in other documents - in the given
examples RFC 2987, RFC 2616.]

s2.2/s5: This statement:
The resulting structure can be represented in CDDL
[I-D.greevenbosch-appsawg-cbor-cddl] as:

requires that the CDDL draft is a normative reference rather than
informative.
[Aside: Having skimmed the CDDL draft, I am of the opinion that a
good deal more work will be needed to get this ready for publication,
possibly to the extent that the CDDL quoted here becomes invalid.
Given the simplicity of the specification could it be done without the
use of CDDL?]

s2.2: There needs to be some discussion of handling of double quoted
and non-double quoted strings during conversion:
I think it works to require that...
- If the parameter value is a double quoted string then it should have
the double quotes stripped, any necessary JSON character encodings
performed and the double quotes repapplied.
- if the parameter value is anything else, then the necessary JSON
character encodings are done and the result enclosed in double
quotes.
[what about % encodings on the RFC 6690 side?]
- If the parameter value is a double quoted string, the double quotes
are stripped and the result used as the CBOR string type value.
- Otherwise, the parameter value is used as the CBOR string value.
[what about % encodings on the RFC 6690 side?]
- Remove the double quotes from the JSON string value and do any
necessary decoding and encoding. Reapply double quotes. Note that
this may result in values that were originally not enclosed in double
quotes in the RFC 6690 repreentation becoming enclosed in double
quotes. However, [AFAICS] this does not alter the semantics of any of
the predefined parameters. For example the ABNF productions mean that
ct=40 and ct="40" are equivalent (the second case is needed so that
one can also have ct="40 41 42"). What IS needed is a statement that
this must also apply to any application specific parameters. For
example the case in examples 4 and 5 of ..;foo="bar";foo=3;...
transforming to "foo":["bar","3"] and then back to
...;foo="bar";foo="3";.. MUST require that the two RFC 6690
representations are equivalent.
[Essentially the same process - decode/encode and apply double quotes.
The discussion of equivalent semantics is equally applicable.]

The conversion from CBOR to JSON or in reverse is similar.

s2.3: It is not stated whether a CBOR decoder should accept literal
use of the encodable parameters - i.e., if the encoded CBOR contains [
"href": "/mumble" ] rather than [1 : "mumble£ ] in CDDL format.
Similarly, should the use of the encoded values be mandatory on the
CBOR encoder?

s2.3, Table 1: Is the omission of title* from the list of parameter
names deliberate? If so the omission justifies a note and rationale.
Clearly the format of the value for a title* parameter is different
from all the others, which may have something to do with this.

s2.3/s5: eEfereences in Table 1 make RFC 7252 and RFC 7641 normative.

Nits/editorial comments:
s1: s/e.g. /e.g., / (two places)

s1.1: The term "round-tripping" and the associated text are opaque
jargon that would normally be applied to message transmission round a
loop rather than format conversion. A more explicit formulation would
help naive readers. Suggest (if I understand what was intended):
OLD:
o Canonical mapping

* lossless round-tripping with [RFC6690] and between JSON and
CBOR

* but not trying for bit-preserving (DER-style) round-tripping
NEW:
o Canonical mapping

* supporting inter-conversion in both directions between any
pair
of [RFC6690] format and the CBOR and JSON formats defined
here
with unaltered and unambiguous semantics

* but not attempting to ensure that a sequence of conversions
from
one of the formats through one or both of the others and back
to
the original would result in an identical representation
(c.f.,
as might be achieved by different BER transcoders rather than
by all
DER transcoders with ASN.1 [X.690]).
ENDS
This needs an informative reference to X.690 ... but I am not sure
that the DER comparison is essential.

s2.2: Suggest:
OLD:
We straightforwardly map:

o the outer collection to an array of links;

o each link to a JSON object or CBOR map, mapping attribute names
to
attribute values.

NEW:
We straightforwardly map:

o the outer collection to an array of parameterized web links;

o each parameterized web link to a JSON object or CBOR map,
mapping attribute names to
attribute values.
ENDS

s2.2:
OLD:
The resulting structure can be represented in CDDL
[I-D.greevenbosch-appsawg-cbor-cddl] as:
NEW:
The resulting structure can be represented in CBOR Data Definition
Language (CDDL)
[I-D.greevenbosch-appsawg-cbor-cddl] as shown in Figure 1.

s2.4: Note that the use of ct=40 in RFC 6690 is an anchronism. The ct
parameter appeared in earlier versions of the draft that led to RFC
6690 but was moved out to be used more generally in CoAP and is
actually defined in RFC 7252 as mentioned in Table 1 here. Thus use
of ct=40 in the example copied from RFC 6690 really needs an erratum
for 6690 but that is for another day!

[Carsten Bormann]

Hi Elwyn,

thank you for your review — that is a lot of good input.

Post by Elwyn Davies
Summary:Not ready for publication. There a number of issues that need
to be addressed as discussed below. In particular whether the
formats could be returned as the web link specification instead of RFC
6990 format in response to a GET /.well-known/core request.
Having thought about the quote stripping/addition issue cited in Adam
Roach's DISCUSS, I would take a slightly different view... see below.
Is it one of the intentions of this draft that a server should be able
to return web link descriptions using JSON or CBOR, specifically in
response to GET /.well-known/core?

Maybe not as much an intention as a possible direction that should remain open.

This draft defines two media types. RFC 6690 defined another media type.
From the point of RFC 6690’s registration of /.well-known/core, RFC 6690 was the only media type available, so the assumption there is that application/link-format is returned.
But if a client sends a CoAP Accept option for one of the two media types defined here, that should be returnable, too.
So we probably should say this explicitly (i.e., update RFC 6690 by saying this).

Post by Elwyn Davies
Content formats for the new
formats are registered (s3.2) - could a user ask for the alternative
formats by specifying at ct filter with the GET request? It strikes
me that if one has a constrained server of sufficiently limited
capabilities that it wants to use CBOR then having to encode the RFC
6690 format responses for the web links requests is wasting resources.
Some more thought needs to be given to this as an update to RFC 6690
- If I read correctly, RFC 6690 implicitly requires that a response to
GET /.well-known/core MUST be encoded as described in RFC6690.

That is one way to read it — however, if you apply the Web model and the fact that the Accept and Content-Format (integer version of media type + content coding) options are central to CoAP, a reading that RFC 6690 just specifies the initial media type for the well-known URI it defines becomes more likely.
But, again, we should make this explicit.

Post by Elwyn Davies
Title: The document appears only to address the CoRE Web Links format
rather than any other. Should the title reflect this more precisely,
e.g.,
Representing CoRE Web Links Format in JSON and CBOR

The RFC editor will force us to expand CoRE.
Probably even simpler:
Representing
Constrained RESTful Environments (CoRE) Link Format
in JSON and CBOR

(The middle line is the title of RFC 6690.)

Post by Elwyn Davies
o The simplest thing that could possibly work
* Do not cater for RFC 5988 complications caused by HTTP
header
character set issues [RFC2047]
Having ferreted around in RFC 5988 and RFC 2047, I can't see what is
being referred to here. However, I observe later that the "title*"
attribute (with language specifier) does not appear to be supported
(It is missing from Table 1) - is this what is relevant here? If so it
needs clarification.

Indeed.

Post by Elwyn Davies
[Aside: I notice that the relevant ABNF in s5 of RFC 5998 is missing
external references to various productions (e.g., ext-value,
quoted-string) that are defined in other documents - in the given
examples RFC 2987, RFC 2616.]
The resulting structure can be represented in CDDL
requires that the CDDL draft is a normative reference rather than
informative.

Well, this was meant to be interpreted as informative, but maybe that should be made more explicit.

Post by Elwyn Davies
[Aside: Having skimmed the CDDL draft, I am of the opinion that a
good deal more work will be needed to get this ready for publication,
possibly to the extent that the CDDL quoted here becomes invalid.

I don’t think so, but we would like to hear this opinion in the CBOR WG, where CDDL is being worked on.

Post by Elwyn Davies
Given the simplicity of the specification could it be done without the
use of CDDL?]

The intention was that all the normative information is in English, that’s why the CDDL reference is informative.

Post by Elwyn Davies
s2.2: There needs to be some discussion of handling of double quoted
I think it works to require that...
- If the parameter value is a double quoted string then it should have
the double quotes stripped, any necessary JSON character encodings
performed and the double quotes repapplied.

That’s not how the spec is written. The assumption is that you already have a JSON or CBOR implementation, so the spec is at the data model level; it is not going to tell you how to parse or generate JSON or CBOR. (Parsing and generating does, however, play a role for RFC6690. Compare the example implementation, which is 90 % RFC 6690 implementation…)

Post by Elwyn Davies
- if the parameter value is anything else, then the necessary JSON
character encodings are done and the result enclosed in double
quotes.
[what about % encodings on the RFC 6690 side?]

We are having a lovely discussion about percent-encoding right now in a thread over at art@, ietf@, ***@.
Let me cite this part from RFC 6690 so you can share the fun:

In
order to convert an HTTP Link Header field to this link format, first
the "Link:" HTTP header is removed, any linear whitespace (LWS) is
removed, the header value is converted to UTF-8, and any percent-
encodings are decoded.

(This obviously creates a limitation on RFC 6690; essentially it can’t represent URIs with percent-encoded reserved characters. Whether that limitation should mirror over to the JSON/CBOR side is to be discussed in that other discussion.)

Post by Elwyn Davies
- If the parameter value is a double quoted string, the double quotes
are stripped and the result used as the CBOR string type value.
- Otherwise, the parameter value is used as the CBOR string value.
[what about % encodings on the RFC 6690 side?]

(See above)

Post by Elwyn Davies
- Remove the double quotes from the JSON string value and do any
necessary decoding and encoding. Reapply double quotes. Note that
this may result in values that were originally not enclosed in double
quotes in the RFC 6690 repreentation becoming enclosed in double
quotes. However, [AFAICS] this does not alter the semantics of any of
the predefined parameters. For example the ABNF productions mean that
ct=40 and ct="40" are equivalent (the second case is needed so that
one can also have ct="40 41 42"). What IS needed is a statement that
this must also apply to any application specific parameters.

Yes, that was one of the points that Mark’s comments pointed out.

Post by Elwyn Davies
For
example the case in examples 4 and 5 of ..;foo="bar";foo=3;...
transforming to "foo":["bar","3"] and then back to
...;foo="bar";foo="3";.. MUST require that the two RFC 6690
representations are equivalent.

That is essentially an RFC 5988 limitation that RFC 6690 inherits and Mark’s RFC5988bis repairs by pretty much stating just this.

Post by Elwyn Davies
[Essentially the same process - decode/encode and apply double quotes.
The discussion of equivalent semantics is equally applicable.]
The conversion from CBOR to JSON or in reverse is similar.

(Ditto)

Post by Elwyn Davies
s2.3: It is not stated whether a CBOR decoder should accept literal
use of the encodable parameters - i.e., if the encoded CBOR contains [
"href": "/mumble" ] rather than [1 : "mumble£ ] in CDDL format.

It should not.

The above specification for JSON could be used as is for the CBOR
encoding as well. However, to further reduce message sizes, an extra
encoding step is performed: "href" and some commonly occurring
attribute names are encoded as small integers.

The “is”/“are" should be interpreted as MUST do that — maybe again this needs to be explicit.

Should a links-cbor decoder required to reject those 13 strings? Hmm.
Interoperability probably says yes, complexity says no.

Post by Elwyn Davies
Similarly, should the use of the encoded values be mandatory on the
CBOR encoder?

Yes.

Post by Elwyn Davies
s2.3, Table 1: Is the omission of title* from the list of parameter
names deliberate? If so the omission justifies a note and rationale.
Clearly the format of the value for a title* parameter is different
from all the others, which may have something to do with this.

Yes. I’m forgetting what title* is being used for over in the Big Web, so I’ll have to look this up again.

Post by Elwyn Davies
s2.3/s5: eEfereences in Table 1 make RFC 7252 and RFC 7641 normative.

Here, I fully disagree (sorry, pet peeve — we are way too lax with the concept of normative references in the IETF).
When specification B uses a string that is mentioned in specification A, without needing anything else from specification A, this doesn’t make specification A normative for B.
A is normative if you need to read it to implement B; that is not the case here.

Post by Elwyn Davies
s1: s/e.g. /e.g., / (two places)

Thanks, a favorite mistake of this non-native speaker.

Post by Elwyn Davies
s1.1: The term "round-tripping" and the associated text are opaque
jargon that would normally be applied to message transmission round a
loop rather than format conversion.

(Actually, for me that is a term of art in format conversion. But I only have worked on format conversions since 1982 :-)
Yes, we need to avoid jargon.

Post by Elwyn Davies
A more explicit formulation would
o Canonical mapping
* lossless round-tripping with [RFC6690] and between JSON and
CBOR
* but not trying for bit-preserving (DER-style) round-tripping
o Canonical mapping
* supporting inter-conversion in both directions between any
pair
of [RFC6690] format and the CBOR and JSON formats defined
here
with unaltered and unambiguous semantics
* but not attempting to ensure that a sequence of conversions
from
one of the formats through one or both of the others and back
to
the original would result in an identical representation
(c.f.,
as might be achieved by different BER transcoders rather than
by all
DER transcoders with ASN.1 [X.690]).
ENDS
This needs an informative reference to X.690 ... but I am not sure
that the DER comparison is essential.

(I hope, not. But thanks for the text suggestion, that will certainly help.)

Post by Elwyn Davies
o the outer collection to an array of links;
o each link to a JSON object or CBOR map, mapping attribute names
to
attribute values.
o the outer collection to an array of parameterized web links;
o each parameterized web link to a JSON object or CBOR map,
mapping attribute names to
attribute values.
ENDS

Hmm, do we need the term “parameterized web link” for what most of us call “link”?

Post by Elwyn Davies
The resulting structure can be represented in CDDL
The resulting structure can be represented in CBOR Data Definition
Language (CDDL)
[I-D.greevenbosch-appsawg-cbor-cddl] as shown in Figure 1.

Yes.

Post by Elwyn Davies
s2.4: Note that the use of ct=40 in RFC 6690 is an anchronism. The ct
parameter appeared in earlier versions of the draft that led to RFC
6690 but was moved out to be used more generally in CoAP and is
actually defined in RFC 7252 as mentioned in Table 1 here. Thus use
of ct=40 in the example copied from RFC 6690 really needs an erratum
for 6690 but that is for another day!

Actually, not quite, as “ct” is deliberately used in RFC 6690 in an example only — you wouldn’t look for a normative reference to a document defining “foo” if we had used that :-)

Again, thank you for that thoughtful feedback, this will help us significantly in making the specification better.

Grüße, Carsten

[Carsten Bormann]

Hi Elwyn,

we tried one round at your comments.

We didn’t tackle the interaction with /.well-known/core — I continue to believe what I said yesterday, but we still have to find a good way to put this into the document.

We added a note that we need to decide whether there is an onus on a receiving CBOR implementation to check for the absence of the 13 strings as names (“Adam’s second issue”).

The title* issue also requires some more thinking — do we even want to have language tags on a constrained device. Right now, the document simply leaves the whole subject out, but probably needs a position on that.

Finally, there is the issue that RFC 6690 percent-decodes and how that should be reflected in the JSON and CBOR variants.

We added a whole subsection on converting back to RFC 6690, which discusses the current pragmatic approach on solving the “to quote or not to quote” issue.

On the editorial side, we addressed the document title, added some language to make it clear that the CDDL is informative (and actually added build tool rules to check the examples against the CDDL, ouch), and quite a few nits. Thank you for the text suggestions (and no, we didn’t add a reference to X.690 yet :-). Based on Adam’s suggestions, we found a way to fix the bullet list in 2.2.

We still need to review the editorial comments on the detailed processing of strings etc. (see may previous comments why these didn’t just drop in).

Please have a look at the new text at:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-08.txt

Thank you!

Grüße, Carsten

[Alissa Cooper]

Elwyn, many thanks for your review. I’ve included it in my ballot position and am holding a DISCUSS while the major issue gets resolved.

Authors/WG, thanks for engaging with Elwyn’s review.

Alissa

Post by Elwyn Davies
Reviewer: Elwyn Davies
Review result: Not Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-core-links-json-07
Reviewer: Elwyn Davies
Review Date: 2017-04-25
IETF LC End Date: 2017-04-21
IESG Telechat date: 2017-04-27
Summary:Not ready for publication. There a number of issues that need
to be addressed as discussed below. In particular whether the
formats could be returned as the web link specification instead of RFC
6990 format in response to a GET /.well-known/core request.
Having thought about the quote stripping/addition issue cited in Adam
Roach's DISCUSS, I would take a slightly different view... see below.
Is it one of the intentions of this draft that a server should be able
to return web link descriptions using JSON or CBOR, specifically in
response to GET /.well-known/core? Content formats for the new
formats are registered (s3.2) - could a user ask for the alternative
formats by specifying at ct filter with the GET request? It strikes
me that if one has a constrained server of sufficiently limited
capabilities that it wants to use CBOR then having to encode the RFC
6690 format responses for the web links requests is wasting resources.
Some more thought needs to be given to this as an update to RFC 6690
- If I read correctly, RFC 6690 implicitly requires that a response to
GET /.well-known/core MUST be encoded as described in RFC6690.
Title: The document appears only to address the CoRE Web Links format
rather than any other. Should the title reflect this more precisely,
e.g.,
Representing CoRE Web Links Format in JSON and CBOR
o The simplest thing that could possibly work
* Do not cater for RFC 5988 complications caused by HTTP
header
character set issues [RFC2047]
Having ferreted around in RFC 5988 and RFC 2047, I can't see what is
being referred to here. However, I observe later that the "title*"
attribute (with language specifier) does not appear to be supported
(It is missing from Table 1) - is this what is relevant here? If so it
needs clarification.
[Aside: I notice that the relevant ABNF in s5 of RFC 5998 is missing
external references to various productions (e.g., ext-value,
quoted-string) that are defined in other documents - in the given
examples RFC 2987, RFC 2616.]
The resulting structure can be represented in CDDL
requires that the CDDL draft is a normative reference rather than
informative.
[Aside: Having skimmed the CDDL draft, I am of the opinion that a
good deal more work will be needed to get this ready for publication,
possibly to the extent that the CDDL quoted here becomes invalid.
Given the simplicity of the specification could it be done without the
use of CDDL?]
s2.2: There needs to be some discussion of handling of double quoted
I think it works to require that...
- If the parameter value is a double quoted string then it should have
the double quotes stripped, any necessary JSON character encodings
performed and the double quotes repapplied.
- if the parameter value is anything else, then the necessary JSON
character encodings are done and the result enclosed in double
quotes.
[what about % encodings on the RFC 6690 side?]
- If the parameter value is a double quoted string, the double quotes
are stripped and the result used as the CBOR string type value.
- Otherwise, the parameter value is used as the CBOR string value.
[what about % encodings on the RFC 6690 side?]
- Remove the double quotes from the JSON string value and do any
necessary decoding and encoding. Reapply double quotes. Note that
this may result in values that were originally not enclosed in double
quotes in the RFC 6690 repreentation becoming enclosed in double
quotes. However, [AFAICS] this does not alter the semantics of any of
the predefined parameters. For example the ABNF productions mean that
ct=40 and ct="40" are equivalent (the second case is needed so that
one can also have ct="40 41 42"). What IS needed is a statement that
this must also apply to any application specific parameters. For
example the case in examples 4 and 5 of ..;foo="bar";foo=3;...
transforming to "foo":["bar","3"] and then back to
...;foo="bar";foo="3";.. MUST require that the two RFC 6690
representations are equivalent.
[Essentially the same process - decode/encode and apply double quotes.
The discussion of equivalent semantics is equally applicable.]
The conversion from CBOR to JSON or in reverse is similar.
s2.3: It is not stated whether a CBOR decoder should accept literal
use of the encodable parameters - i.e., if the encoded CBOR contains [
"href": "/mumble" ] rather than [1 : "mumble£ ] in CDDL format.
Similarly, should the use of the encoded values be mandatory on the
CBOR encoder?
s2.3, Table 1: Is the omission of title* from the list of parameter
names deliberate? If so the omission justifies a note and rationale.
Clearly the format of the value for a title* parameter is different
from all the others, which may have something to do with this.
s2.3/s5: eEfereences in Table 1 make RFC 7252 and RFC 7641 normative.
s1: s/e.g. /e.g., / (two places)
s1.1: The term "round-tripping" and the associated text are opaque
jargon that would normally be applied to message transmission round a
loop rather than format conversion. A more explicit formulation would
o Canonical mapping
* lossless round-tripping with [RFC6690] and between JSON and
CBOR
* but not trying for bit-preserving (DER-style) round-tripping
o Canonical mapping
* supporting inter-conversion in both directions between any
pair
of [RFC6690] format and the CBOR and JSON formats defined
here
with unaltered and unambiguous semantics
* but not attempting to ensure that a sequence of conversions
from
one of the formats through one or both of the others and back
to
the original would result in an identical representation
(c.f.,
as might be achieved by different BER transcoders rather than
by all
DER transcoders with ASN.1 [X.690]).
ENDS
This needs an informative reference to X.690 ... but I am not sure
that the DER comparison is essential.
o the outer collection to an array of links;
o each link to a JSON object or CBOR map, mapping attribute names
to
attribute values.
o the outer collection to an array of parameterized web links;
o each parameterized web link to a JSON object or CBOR map,
mapping attribute names to
attribute values.
ENDS
The resulting structure can be represented in CDDL
The resulting structure can be represented in CBOR Data Definition
Language (CDDL)
[I-D.greevenbosch-appsawg-cbor-cddl] as shown in Figure 1.
s2.4: Note that the use of ct=40 in RFC 6690 is an anchronism. The ct
parameter appeared in earlier versions of the draft that led to RFC
6690 but was moved out to be used more generally in CoAP and is
actually defined in RFC 7252 as mentioned in Table 1 here. Thus use
of ct=40 in the example copied from RFC 6690 really needs an erratum
for 6690 but that is for another day!
_______________________________________________
Gen-art mailing list
https://www.ietf.org/mailman/listinfo/gen-art

_______________________________________________
core mailing list

[Adam Roach]

Post by Elwyn Davies
- Remove the double quotes from the JSON string value and do any
necessary decoding and encoding. Reapply double quotes. Note that
this may result in values that were originally not enclosed in double
quotes in the RFC 6690 repreentation becoming enclosed in double
quotes. However, [AFAICS] this does not alter the semantics of any of
the predefined parameters. For example the ABNF productions mean that
ct=40 and ct="40" are equivalent (the second case is needed so that
one can also have ct="40 41 42"). What IS needed is a statement that
this must also apply to any application specific parameters. For
example the case in examples 4 and 5 of ..;foo="bar";foo=3;...
transforming to "foo":["bar","3"] and then back to
...;foo="bar";foo="3";.. MUST require that the two RFC 6690
representations are equivalent.

This has the reciprocal problem that using quotes with (e.g.) sz and
hreflang is a violation of the ABNF in RFC6690.

/a

[Carsten Bormann]

This has the reciprocal problem that using quotes with (e.g.) sz and hreflang is a violation of the ABNF in RFC6690.

Yes. Using ABNF for the serialization of an item that should be described at the data model level (as in 5988bis) is now generally considered a mistake. To stay compatible with the letter of RFC 6690 (which probably continues to be a good idea), the reference implementation in Appendix A of links-json uses the quote-less form whenever the value is a ptoken, i.e. a sequence of one or more ptokenchar characters(*). Should we require this, and if yes, should this be a SHOULD or a MUST?

Grüße, Carsten

(*)
ptoken = 1*ptokenchar
ptokenchar = "!" / "#" / "$" / "%" / "&" / "'" / "("
/ ")" / "*" / "+" / "-" / "." / "/" / DIGIT
/ ":" / "<" / "=" / ">" / "?" / "@" / ALPHA
/ "[" / "]" / "^" / "_" / "`" / "{" / "|"
/ "}" / "~"