Re: [core] [Cbor] [httpapi] WG Last Call on draft-ietf-core-problem-details

[Carsten Bormann <[e-mail]>]

Hi Roberto,

this is indeed a rather intriguing question.
Thank you for dragging this out in the open.

> In the media type registration, there's
> 
>>  Fragment identifier considerations:  The syntax and semantics of
>>     fragment identifiers is as specified for "application/cbor".  (At
>>     publication of RFC XXXX, there is no fragment identification
>>     syntax defined for "application/cbor".)
> 
> With the registration of application/yaml and the +yaml structured
> syntax suffix [1], we thought to
> detach fragment identifier consideration of subtypes from the
> application/yaml and +yaml.
> 
> For example: should a future fragment identifier spec for application/cbor be
> compatible with all subtypes delegating it to the application/cbor?

I believe it should.

But then, we haven’t identified a common CBOR fragment identifier syntax yet.

My personal expectation is that we will eventually define something like a CBOR-oriented version of JSONPath [1], which will give rise to a natural fragment identifier syntax at the CBOR structural level.  One major point will be transforming this into a fragment identifier syntax in such a way that foo+cbor can extend this with fragment identifier syntax that is e.g. referencing foo+cbor’s information model.
So there should be something in application/cbor’s fragment syntax that branches out to application specific fragment identifier syntaxes.

This is all fiction at the moment, but it is the reason why I like what we have written above — problem-details doesn’t define its own fragment identifier syntax, but as soon as application/cbor has one, we can use that.

Re your draft: I think PDF’s #page=12 is better than a #12 would have been (and I would prefer YAML’s to be #a=bar instead of #bar so application/foo+yaml can still define #x=4711 and let #a=bar stand from the general fragment identifier considerations.

Grüße, Carsten


[1]: https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-05.html