Stub for security, interoperability and fragment identifier considera…

[ioggstream]

This PR

• adds stubs for the various consideration sections.

Note

• the text is just a placeholder

---

Preview | Diff

[ioggstream]

Note: here we could

• import application/yaml fragid considerations
• replace the text below after investigating yaml-ld specificities. See Fragment identifier #31

[gkellogg]

Again, JSON-LD puts this in IANA Considerations and describes it as being equivalent to other RDF syntaxes. The closest analogy is probably with XML and RDFa, where there is overlap between markup identifiers and fragment identifiers.

Note JSON-LD does not have any direct relationship to JSON Pointers.

We do need to consider and reconcile the overlap between the different YAML fragment identifiers, and the use of fragments in RDF, in general, which do not necessarily require that a fragment be directly associated with a marker in the document.

[ioggstream]

@gkellogg my proposal is

1- let's write down the stuff in these sections as specified in https://datatracker.ietf.org/doc/html/rfc8126#section-1.1
2- if the text just results in a series of references to external documents, we can just reference things into the IANA considerations
3- if the text is longer, we reference the document section

WDYT?

[gkellogg]

We need to reconcile with #27. Maybe merge that first and then apply any updates after the fact. Or, this could be a PR into the branch for #27.

[gkellogg]

(Assuming there’s overlap)

[ioggstream]

I'll rebase when needed :) In the meanwhile let's talk on the content.

[gkellogg]

Approved, but subject to further refinement and reconciliation.

[gkellogg]

This duplicates/will duplicate the section in #27 IANA Considerations. The JSON-LD spec has this section, but links a reference to its own sub-section within IANA Considerations. We should probably do the same.

See, Security Considerations in § A. IANA Considerations.

[ioggstream]

IANA Security considerations should reference this section.

[gkellogg]

IANA Security considerations should reference this section.

That makes it inconsistent with how it's done in JSON-LD. That may be fine if we're internally consistent, but it is different.

[ioggstream]

In the past I have been pointed to https://datatracker.ietf.org/doc/html/rfc8126#section-1.1

The purpose of having a dedicated IANA Considerations section is to
provide a single place to collect clear and concise information and
instructions for IANA. Technical documentation should reside in
other parts of the document; the IANA Considerations should refer to
these other sections by reference only (as needed).

For example, see https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-binary-message-05#section-7 .

[gkellogg]

Okay, wish we had known that when we did the JSON-LD IANA considerations, of course, that was way back in the 1.0 timeframe in 2014, so we should go with your division. We'll need to follow up after both PRs are merged. (I usually wait a week for comments to come in before merging with the consensus opinions).

[ioggstream]

Honestly, I didn't know that either:) that's all stuff I learned thanks to the reviews of the httpwg folks :)))

[gkellogg]

Either treat the same as security considerations, and reference the sub-section in IANA Considerations, have that reference this part, or duplicate content.

[ioggstream]

See above comment from RFC8126

[gkellogg]

Again, JSON-LD puts this in IANA Considerations and describes it as being equivalent to other RDF syntaxes. The closest analogy is probably with XML and RDFa, where there is overlap between markup identifiers and fragment identifiers.

Note JSON-LD does not have any direct relationship to JSON Pointers.

We do need to consider and reconcile the overlap between the different YAML fragment identifiers, and the use of fragments in RDF, in general, which do not necessarily require that a fragment be directly associated with a marker in the document.