Define "undefined" and "implementation-defined" (3.0.4)

[handrews]

• Fixes Codify the meaning of "undefined" and "implementation-defined" #3775

Undefined means "don't use this even if it seems to work, as there are cases where it won't." Implementation-defined means "this isn't portable or interoperable, but it is still correct."

[notEthan]

This is confusing to me, both my general understanding of how the term 'undefined behavior' is used and as defined here. In particular the description "likely to contradict the specification" - my understanding has been that undefined behavior, either explicitly stated as undefined or by a lack of explicit specification, has no expectation for the outcome of that behavior. That would mean there's nothing specified for behavior to contradict.

And the statement "Implementations MAY support undefined scenarios" seems at odds with that behavior being likely to contradict specification. Combining the two, to my interpretation, results in "Implementations MAY have behavior that probably contradicts the specification" or so.

[notEthan]

Having since been reading related issues that led to this (on structural interoperability), this is making more sense - it seems not the undefined behavior itself (treating references' resolved objects as one type when their structural placement indicates another type) that will contradict the spec, but the natural result of doing that in some circumstances (not detecting schema $ids, not having the correct base URI).

Wording that distinguishes the undefined-but-allowed behavior from the possible specified-disallowed result might be clearer, though I'm not sure quite how that would be worded.

[handrews]

Thanks, @notEthan , I'll try to think about better wording.

Wording that distinguishes the undefined-but-allowed behavior from the possible specified-disallowed result might be clearer, though I'm not sure quite how that would be worded.

That's specifically what I'm trying to avoid doing. Or, rather, I have laid out the specifics before and had people refuse to read it for being too long or complicated. One person complained that the topics are so obscure that "only four or five people" could probably even understand it.

It's much easier to say "just don't do anything like this" than try to explain all of the different things that have to happen for it to not work.

Allowing for implementations that do it anyway is just a concession to reality: Many tools do not implement 3.1 Schema Object reference parsing correctly, and are likely to ignore a directive to rip out their incorrect support. And given that it was not obvious to most how the specifications require different behavior in 3.1, I hesitate to penalize them.

If they have something that works for them and their customers, the most likely outcome is that they keep doing it. But changing the wording in the spec makes it clear that if there is a problem, it's not a spec problem (aside from past lack of clarity). It's outside the spec, and we know it won't work sometimes.

It's a difficult situation to articulate, really.

[notEthan]

Maybe just "Behavior described as undefined is likely, at least in some circumstances, to result in outcomes that contradict the specification." or so. Undefined behavior itself isn't contradicting the spec but its result likely will - if that isn't too much indirection for one sentence.

I don't know, the wording that goes into spec authorship is hard (much respect for all you have put into various specs my work relies on).

[handrews]

@notEthan @kevinswiber @ralfhandl in light of @notEthan 's comments, I'm wondering if "undefined" is really the right word to use. I was using it thinking of the following from RFC 7231 §4.3.1 GET

A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.

Here is the analogous text from RFC 9110 §9.3.1 GET:

Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

What both of these have in common with what I'm trying to do is that they don't require an error, even though they note that an error might occur. Basically, they boil down to "if you want to do this and it seems to work, we're not stopping you, but it quite likely won't work." 9110 gets a bit more detailed in its recommendation, including allowing that a server might indicate that it accepts a GET body. But it also notes that intermediaries might not be aware of such agreements, indicating that you might not be able to get your GET body through to the server even if it is willing to accept it.

That seems to fit with my general desire to say "you can do this if you really want to, and maybe a tool documents that it works in some cases, but there might be reasons it still won't work because you don't control everything here."

Notably, RFC 2616 did not include anything about GET request bodies/content, so I assume that it was added after people did unexpected things with it, and it was necessary to discourage without invalidating. Which is very similar to some situations in OAS.

Propose to accept @notEthan's proposal

[lornajane]

I think this is pretty clear. Thanks everyone for the input and the revisions!