Secretary: Mark Nottingham
Note taker: Mike Bishop
Approaching WGLC; one open issue on mailing list to discuss.
Should JSON representation include multi-lingual titles?
Consistency vs. complexity trade-off
Should take to list; not all stakeholders are present.
Phil: Implemented as-is, wasn't a problem; would prefer it not change now.
Mark: Need to dig in more.
Conversation returned to list.
Close to WGLC after these issues are dealt with.
HTTP status code for multiple statuses is "quite obscure"
Recommendation is "pick one to surface"; some support on issue, but unsure on consensus
Sanjay: Lack of support for multiple errors has led us to custom error responses in the past. Bad for acceptance of 7807.
Mark: Unclear whether that's because of lack of guidance or because it's actually needed.
Darrel: MS follows from OData, but not much used. Mostly seen on batched operations where some succeed and some fail; not generalized.
Mike A.: Pick first and stop there. Don't invent something that messes with status codes.
Mark: Advice about granularity is probably useful here.
Jayadeba: Could not use 7807 for this reason; supporting this would aid adoption.
Sanjay: Multiple instances is more common; multiple problems is limited.
Mark will author a PR to see if that gets consensus.
HTTP or URN prefix?
Max: Linked to error page; would this make that impossible?
Mark: This isn't for custom errors. Advertisement for registry versus potential load issue and compactness.
Jayadeba: This could be used for non-HTTP protocols; is HTTP appropriate?
Mark: Just an identifier; no dereferencing. Also, this is HTTPAPI.
Sanjay: HTTP response might come from another source.
Mike A.: URN is less likely to be dereferenced accidentally.
Mark will try URN and see if it sticks.
7807 doesn't allow new fields, for better or worse.
Derk-Jan: Encourage people to make docs resolvable. Put in Link header or a new member with a short name.
Mark: If your docs aren't intended to be resolvable, use a URN.
Sanjay: Separate Link header might not help; should be with the object. Should help consumer resolve the issue.
Derk-Jan: Link indicates resolvable; use URN if it's not resolvable.
Mike: Use URN when it shouldn't be resolvable.
Keep default that type is resolvable to docs. Refine text to clarify principles.
Lots of similar approaches to this problem, including Post-Once-Exactly. Draft standardizes header usage.
Several users already.
Should it return the result of the previous operation, or the current state if it has changed since?
Proposal: Previous result; client can make conditional GET to check if state is current.
Should the status code indicate whether the request has already been made?
Proposal: Previous status code; just indicate that it was done.
Should the server retry when the previous status was a recoverable error?
Proposal: Want to clarify that server has option to retry.
Will invite OASIS to discuss with WG on how they align.
Mark: History shows cross-SDO standards are rough. Invite OASIS folks here or our folks can go there, but joint efforts are fraught.
Rich: Agree, different rules for participation.
Will discuss other approaches in appendix.
Mike A.: Examples so far rely on server state; conditional requests have been around for a while.
Mark: New conditional request mechanism isn't trivial; need to involve HTTP WG.
Mike A.: Talking about applying to POST, not creating new ones.
Mike & Mark will sync about http-core.
Please review discussions at https://github.com/ietf-wg-httpapi/discussion/discussions