Add JSON-LD Context

[asbjornu]

Resolves #10. Awaits approval by chairs (see https://github.com/ietf-wg-httpapi/rfc7807bis/issues/46#issuecomment-1195126352).

[dret]

On 2022-07-26 16:24, Asbjørn Ulsberg wrote:

@.**** commented on this pull request.

• @.***": {
• "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
• "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
• "type": { @.": "rdf:type", @.": @.***" },
• "status": "urn:ietf:rfc:7807:status",

I'm a bit unsure about |status| being mapped to the URN |urn:ietf:rfc:7807:status|. First, is the colon a fine separator for |:status| @dret https://github.com/dret @mnot https://github.com/mnot? Also, is RFC 7807 the right RFC to reference or should we reference the HTTP RFC 9110 instead?

what in either of those standards would justify to use that URN? RFC 9110 defines the concept of an HTTP status, RFC 7807 defines the string "status" as a JSON member of a problem report. neither of them define these as URN or with that specific URN namespace.

[asbjornu]

what in either of those standards would justify to use that URN? RFC 9110 defines the concept of an HTTP status, RFC 7807 defines the string "status" as a JSON member of a problem report.

@dret, the URN will change – at least once the RFC number of rfc7807bis is minted, if we agree that we should use rfc7807bis as the namespace provider for status. Referencing RFC 9110 would be easier, since it has a final RFC number minted already.

neither of them define these as URN or with that specific URN namespace.

Is it a requirement that an RFC defines a URN for "itself" in order for other specifications to reference it? If we go with rfc7807bis, we can define the URN urn:rfc:7807bis within the scope of the spec itself. For RFC 9110, we have no such flexibility, so if the URN needs to be predefined, we can't use it.

[dret]

On 2022-07-26 17:25, Asbjørn Ulsberg wrote:

@dret https://github.com/dret, the URN will change – at least once the RFC number of rfc7807bis is minted, if we agree that we should use rfc7807bis as the namespace provider for |status|. Referencing RFC 9110 would be easier, since it has a final RFC number minted already.

neither of those make any claims or statements about their concepts being identified through URNs. that's quite an assumption to make, in my mind.

Is it a requirement that an RFC defines a URN for "itself" in order for other specifications to reference it? If we go with rfc7807bis, we can define the URN |urn:rfc:7807bis| within the scope of the spec itself. For RFC 9110, we have no such flexibility, so if the URN needs to be predefined, we can't use it.

of course nobody can keep third parties from inventing any identifier that they want (assuming they're ok with those being private identifiers and not claiming any authority to mint public ones). it's a bit different when we add those to a specification itself, in my mind.

[darrelmiller]

I added a comment here https://github.com/ietf-wg-httpapi/rfc7807bis/issues/46#issuecomment-1195126352 This content feels like it is in the wrong place to me.

[asbjornu]

As further proof for IETF needing to figure out how to do namespacing, here's how Microsoft ASP.NET now by default responds for 404 errors in controllers decorated with [ApiController]:

{
  "type": "https://tools.ietf.org/html/rfc7231#section-6.5.4",
  "title": "Not Found",
  "status": 404,
  "traceId": "…"
}

Notice how type has the value https://tools.ietf.org/html/rfc7231#section-6.5.4. Is this usage condoned by IETF? If so, can't we do the same in rfc7807bis itself?

[mnot]

Given that tools.ietf.org is no longer functional, no. This is a great illustration of why you shouldn't use someone else's name space without their permission...

The IETF certainly can manage name spaces -- that's what IANA is for. However, we need to agree on it and document it, both of which will require work. The best thing to do would be to write a problem statement (in an Internet-Draft or an email) and take it to DISPATCH for further discussion.

[asbjornu]

Given that tools.ietf.org is no longer functional, no.

That was my thought too. As someone who works within the company that has made this default implementation, what's your thoughts on this, @darrelmiller?

This is a great illustration of why you shouldn't use someone else's name space without their permission...

Exactly.

The IETF certainly can manage name spaces -- that's what IANA is for. However, we need to agree on it and document it, both of which will require work.

I see.

The best thing to do would be to write a problem statement (in an Internet-Draft or an email) and take it to DISPATCH for further discussion.

Okay. Sounds like something that rfc7807bis can't wait for, though.

[dret]

hello asbjørn.

On Sep 23, 2022, at 05:09, Asbjørn Ulsberg @.***> wrote:

As further proof for IETF needing to figure out how to do namespacing, here's how Microsoft ASP.NET now by default responds for 404 errors in controllers decorated with [ApiController]:

{ "type": "https://tools.ietf.org/html/rfc7231#section-6.5.4", "title": "Not Found", "status": 404, "traceId": "…" } Notice how type has the value https://tools.ietf.org/html/rfc7231#section-6.5.4. Is this usage condoned by IETF? If so, can't we do the same for status in RFC 7807?

it's not nentioned or encouraged and doesn't make a lot of sense because essentially "type" only repeats the "status" (at least that looks like the intent), instead of providing additional information regarding the type of problem.

cheers,

dret.

[asbjornu]

it's not nentioned or encouraged and doesn't make a lot of sense because essentially "type" only repeats the "status" (at least that looks like the intent), instead of providing additional information regarding the type of problem. cheers, dret.

Agreed. But it does underscore the need for IETF to establish a namespace architecture for these sorts of things.