search

ietf-wg-httpapi / rfc7807bis

Revision of RFC7807: HTTP Problem Details
Other
20 stars 8 forks source link

Resolvability of IANA URIs #62

Closed mnot closed 1 year ago

mnot commented 2 years ago

As discussed in Carsten's feedback, we should note that IANA URLs with fragment identifiers are currently not resolveable to the fragment identifier.

asbjornu commented 2 years ago

Can we assist IANA in making this a supported use case? From the outset, it seems like supporting fragment identifiers is trivial. I saw the discussion about not being able to mandate an HTML structure and I don't really know enough about IANA's inner workings or process to understand what the problem of supporting fragment identifiers really is. If anyone can elaborate on that, I'd be grateful.

mnot commented 2 years ago

We can start that discussion this week, but it's a much larger coordination (they'll want to do it for all registries), so we shouldn't take a dependency on it.

asbjornu commented 2 years ago

I see. Yeah, that makes sense. How does this fit in with the general UX and design work I've seen IETF has been RFQ-ing about lately? Does the scope of that work include any of IANA's areas? If not, perhaps we can piggyback on the general IETF design to improve the look, feel and UX of IANA's registries?

mnot commented 2 years ago

There is a lot of friction there, but we'll see. Please be patient :)

dret commented 2 years ago

On 2022-11-08 01:33, Asbjørn Ulsberg wrote:

Can we assist IANA in making this a supported use case? From the outset, it seems like supporting fragment identifiers is trivial. I saw the discussion about not being able to mandate an HTML structure and I don't really know enough about IANA's inner workings or process to understand what the problem of supporting fragment identifiers really is. If anyone can elaborate on that, I'd be grateful.

iirc this debate has been going on for many years now. i am afraid that if we make this draft depend on it being resolved, this will probably delay any further progress for a very long period of time.

i would still love to see the IANA registry pages being created so that they can be more reliably processed. but i think we should strictly separate what's possible today for RFC7807bis, and what we'd ideally like to see for the IANA registry pages.

dret commented 2 years ago

On 2022-11-08 01:51, Asbjørn Ulsberg wrote:

I see. Yeah, that makes sense. How does this fit in with the general UX and design work I've seen IETF has been RFQ-ing about lately? Does the scope of that work include any of IANA's areas? If not, perhaps we can piggyback on the general IETF design to improve the look, feel and UX of IANA's registries?

just piggybacking on a recent trend in the API space i think what we should really try to do is improve the DX of their registry pages: i.e., given that there isn't an actual registry API (there isn't, right?), then it would be reasonable and probably the easiest way forward to turn their registry pages into their API.

they have some good start because they're using XHTML. a long time ago i did experiment a bit with simply processing everything as one XML API. that didn't go great but sort of worked after a bit of clean-up and adding some special case rules. i think improving this wouldn't be too hard, if they're willing to make that a goal.

sazzer commented 2 years ago

It's not a small change, but I wonder if theres any benefit in making those pages instead be just XML files that then link to an appropriate XSLT stylesheet whichi re-renders them as HTML for browsers? That way, API consumers could get the XML version instead and have a slightly easier time parsing them, whilst human consumers still get to see them in an easier-to-read format in their browsers.

Cheers -- Graham Cox

On Tue, 8 Nov 2022 at 10:20, Erik Wilde @.***> wrote:

On 2022-11-08 01:51, Asbjørn Ulsberg wrote:

I see. Yeah, that makes sense. How does this fit in with the general UX and design work I've seen IETF has been RFQ-ing about lately? Does the scope of that work include any of IANA's areas? If not, perhaps we can piggyback on the general IETF design to improve the look, feel and UX of IANA's registries?

just piggybacking on a recent trend in the API space i think what we should really try to do is improve the DX of their registry pages: i.e., given that there isn't an actual registry API (there isn't, right?), then it would be reasonable and probably the easiest way forward to turn their registry pages into their API.

they have some good start because they're using XHTML. a long time ago i did experiment a bit with simply processing everything as one XML API. that didn't go great but sort of worked after a bit of clean-up and adding some special case rules. i think improving this wouldn't be too hard, if they're willing to make that a goal.

— Reply to this email directly, view it on GitHub https://github.com/ietf-wg-httpapi/rfc7807bis/issues/62#issuecomment-1306973043, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQEGDI3PNEWTET36Z66JTWHISPZANCNFSM6AAAAAARYPAIZM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

mnot commented 2 years ago

Please understand that how IANA does its job is regulated by a contract and some oversight bodies, and so we can't go in and say 'do it this way.' We can start that process but it's not going to happen on this issue. Let's constrain this discussion to what should happen in this specification.

sdatspun2 commented 1 year ago

As discussed in Carsten's feedback, we should note that IANA URLs with fragment identifiers are currently not resolveable to the fragment identifier.

Record keeping nit: is there a link to that discussion which can be addd to this issue?

darrelmiller commented 1 year ago

@sdatspun2 I believe this is the thread https://mailarchive.ietf.org/arch/msg/httpapi/AGCGu1xzdZdJ3ntsfzwUnxo4LNY/