Re: [Last-Call] [httpapi] Last Call: <draft-ietf-httpapi-rfc7807bis-04.txt> (Problem Details for HTTP APIs) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> all true, no doubt. i never understood why you wouldn't support fragment identifiers on those pages for the obvious usefulness this would provide, but that's a different discussion.

Ultimately, that’s where we want to get.  We have been talking about making IANA registries more accessible to non-humans for half a decade or more.
(There is a lot of automation that should be using IANA registries but can’t because they are currently not fully machine-readable.
This probably shouldn’t target the HTML in general, but the dereferencing target for 7807bis appears to be HTML.)

> the question then is whether we want to include guidance that we know will not be properly supported at the fragment identifier level. we could say it's kind of ok because you will end up on the correct page and will probably figure it out, but that certainly isn't technically what should be happening.

The fragment identifier is really only used to distinguish different type URIs, not to find their place in the HTML page.
That is possibly more surprising than we want.

> either we remove the guidance, or we can add a note saying that for those URIs, fragment identification will not work. my preference is for the latter, because it would be useful to end up on the registry page.

Yes, we can take away the surprise by saying that.

Grüße, Carsten

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux