Last chance for comments

[richsalz]

Please see https://mailarchive.ietf.org/arch/msg/httpapi/VlX_Excs5jhWsnxgZxZkwOOrx_E/

This is a two-week Working Group Last Call. If you have objections or
concerns about this document, please post them by the end of the month. 
Thank you.

[darrelmiller]

The document is looking good to me. One minor possible nit in section 3.1.1.

Consumers MUST use the "type" URI (after resolution, if necessary) problem's primary identifier.

@mnot Should the above actually say?

Consumers MUST use the "type" URI (after resolution, if necessary) as the problem's primary identifier.

[asbjornu]

Dear chairs @darrelmiller @richsalz, I have a request to add an informal section to the spec to have #10 resolved. It should not be a large change; as it is only an informative section, it should also not be controversial. I have been inhibited from working on a PR due to a rather exhausting parental leave, but I'm finally easing back to work so I now have some time on my hands and the ability to contribute. I'll get to work on the PR and hope you'll accept it although the two-week last call is long surpassed. 🙏🏼

[darrelmiller]

@asbjornu Thank you for this contribution. Can you help me understand why it is valuable to add a description of how JSON-LD users should use http-problem into the http-problem specification? Wouldn't it be a more scalable solution to document in JSON-LD documentation how http-problem can be used? What about how http-problem can be used in JSON:API, OData, gRPC, GraphQL,etc? Documenting how to use JSON-LD in the http-problem specification feels inverted to how this should actually be done.

[asbjornu]

If this was only about documenting usage, I would completely agree, @darrelmiller. But this is also about establishing a shared vocabulary, such that all JSON-LD-capable consumers of rfc7807bis interpret it in the same way. None of the formats or protocols you mention have a concept of shared vocabulary or namespace, and as such, they are not affected by this issue.

Not defining the shared vocabulary within rfc7807bis is like RFC 4287 not defining its own namespace URI to be http://www.w3.org/2005/Atom, but instead, leaving that part up to every producer and consumer of Atom. Needless to say, that would have caused a lot of compatibility issues with Atom implementations, where I suppose some namespace URIs would become de facto standards every consumer would have to support. However, since RFC 4287 does define its own namespace URI, that whole compatibility conundrum is avoided.

What is needed in rfc7807bis to establish this shared vocabulary is just to mint a URI. That's it. We've explored many different options (URNs, URIs, URLs), but IETF does not have a procedure to mint URIs meant for such namespace-like usage and to have W3C mint such a URL for us (like they did for Atom) seems like a difficult task. I have no contacts in W3C to ask, at least.

[mnot]

Hey @asbjornu. When we discussed this at IETF114, concern was expressed that we might not get it right, because we don't have broad expertise in JSON-LD, and also that baking it into an immutable RFC doesn't allow for easy adjustment later.

Given that, I think the relevant question is why it's important to establish a shared vocabulary in this document -- keeping in mind that most users of this document will not be using JSON-LD (unlike your example of the Atom namespace).

[dret]

On 2022-08-10 04:16, Mark Nottingham wrote:

Given that, I think the relevant question is why it's important to establish a shared vocabulary in /this/ document -- keeping in mind that most users of this document will /not/ be using JSON-LD (unlike your example of the Atom namespace).

it just seems like an odd thing to give a non-normative JSON-LD context. if it's non-normative, it's simply showing how to use JSON-LD and that seems to be something that applies to any JSON out there.

in my mind, to make sense this would need to be a normative context so that the RDF community would have a model to represent problem reports. for that it seems like it would make more sense for the RDF community to work on such a vocabulary, publish it, and then provide a JSON-LD with it.

[asbjornu]

Given that, I think the relevant question is why it's important to establish a shared vocabulary in this document -- keeping in mind that most users of this document will not be using JSON-LD (unlike your example of the Atom namespace).

Ok, please allow me to explore a thought experiment. A lot of XML was and is consumed without any care for XML namespaces. For those XML processors, it wouldn't matter whether RFC 4287 declared an official namespace URI or not. Authors of these processors could even argue that it's not their problem that someone wants to burden their simple XML processors with XMLNS and that those who want to process XML with namespaces should do so by minting their own namespace URI outside the scope of RFC 4287.

Now, which would you say is the natural authority to assume the task of registering a namespace URI for RFC 4287? How do you ensure there's no fragmentation? That everyone that wants to consume Atom with XMLNS uses the same URI?

I don't think those questions have clear or good answers if RFC 4287 did not mint its own XMLNS and I think the same applies to rfc8707bis if it doesn't mint its own URI. I would even be happy about leaving JSON-LD in the dust and for the JSON-LD community to figure out and just having rfc8707bis declare something like:

For applications that require Problem Details for HTTP to be identified by a URI, the following can be used: https://example.com/ns/problem#

[darrelmiller]

@asbjornu The abstract of RFC 4287 says

This document specifies Atom, an XML-based Web content and metadata syndication format.

The Atom format takes a normative dependency on XML and therefore has an obligation to play by the rules of XML and define an official namespace.

RFC 7807 says,

this specification defines simple JSON and XML document formats and a HTTP field to describe the specifics of problem(s) encountered -- "problem details".

It doesn't say it is the authoritative source for a JSON-LD format. I don't think adding a non-normative appendix for JSON-LD is the right solution to the problem as a) it is not authoritative and b) it doesn't scale.

[dret]

On 2022-08-19 16:04, Darrel wrote:

The Atom format takes a normative dependency on XML and therefore has an obligation to play by the rules of XML and define an official namespace.

RFC 7807 says,

this specification defines simple JSON and XML document formats and
a HTTP field to describe the specifics of problem(s) encountered --
"problem details".

It doesn't say it is the authoritative source for a JSON-LD format. I don't think adding a non-normative appendix for JSON-LD is the right solution to the problem as a) it is not authoritative and b) it doesn't scale.

because RFC 7807 does define an XML format it does define a namespace for it.

https://www.rfc-editor.org/rfc/rfc7807#appendix-A

but that's for the XML vocabulary of RFC 7807. there's no mention of namespaces/identifiers for RDF vocabularies in either RFC 4287 or RFC

7807. both specs are simply not concerned with RDF representations.

[asbjornu]

@darrelmiller:

The Atom format takes a normative dependency on XML and therefore has an obligation to play by the rules of XML and define an official namespace.

Namespaces are an optional addition to XML. Swathes of XML doesn't contain a single xmlns attribute and there are a plethora of XML processors that don't grok namespaces at all. XML existed for a year before XMLNS was a thing and it took a while before the most widespread processors caught on to it. Although it was considered good (perhaps even best) practice, there was afaik nothing that forced us to mint a namespace for Atom when we developed it.

It doesn't say it is the authoritative source for a JSON-LD format. I don't think adding a non-normative appendix for JSON-LD is the right solution to the problem as a) it is not authoritative and b) it doesn't scale.

I can come to terms with that if you please consider what I suggested in https://github.com/ietf-wg-httpapi/rfc7807bis/issues/46#issuecomment-1212578885:

I would even be happy about leaving JSON-LD in the dust and for the JSON-LD community to figure out and just having rfc8707bis declare something like:

For applications that require Problem Details for HTTP to be identified by a URI, the following can be used: https://example.com/ns/problem#

@dret:

because RFC 7807 does define an XML format it does define a namespace for it. https://www.rfc-editor.org/rfc/rfc7807#appendix-A

Indeed, but as we've discussed urn:ietf:rfc:7807 is not extensible. It is impossible for a JSON-LD context to state that status is urn:ietf:rfc:7807:status or urn:ietf:rfc:7807#status for instance.

there's no mention of namespaces/identifiers for RDF vocabularies in either RFC 4287 or RFC 7807. both specs are simply not concerned with RDF representations.

Nor does rfc7807bis have to be, either. It just needs to provide an extensible URI that JSON-LD and XML consumers can use to say "this is the authoritative URI that represents rfc7807bis". Is it nothing we can do about the urn:ietf:rfc:7807 URI to allow this sort of extensibility?

[dret]

On 2022-08-25 23:21, Asbjørn Ulsberg wrote:

Indeed, but as we've discussed |urn:ietf:rfc:7807| is not extensible. It is impossible for a JSON-LD context to state that |status| is |urn:ietf:rfc:7807:status| or |urn:ietf:rfc:7807#status| for instance.

that URI is the XML namespace URI and was never intended or never claimed to be more than that.

Nor does rfc7807bis have to be, either. It just needs to provide an extensible URI that JSON-LD and XML consumers can use to say "this is the authoritative URI that represents rfc7807bis". Is it nothing we can do about the |urn:ietf:rfc:7807| URI to allow this sort of extensibility?

that ship sailed six years ago with RFC 7807. since our explicit goal is to not break things, changing the XML namespace URI is not an option.

[asbjornu]

that ship sailed six years ago with RFC 7807. since our explicit goal is to not break things, changing the XML namespace URI is not an option.

I'm not asking to change the XML namespace URI (in the XML context), I'm asking to reuse and expand it in other contexts. The fact that JSON-LD expands status to urn:ietf:rfc:7807:status is not going to affect the XML serialization or processing of rfc7807bis.