Note relative URL-reference resolution ambiguity

[handrews]

This explicitly lists out the cases and notes which ones were (as far as we can recall) intended to behave like $ref, but could be reasonably read to behave like API URLs.

See:

• Fix description vs document terminology #4100 (comment)

[mikekistler]

Looks good! 👍

I think the wording as is conveys the key information, but I left an alternate wording that I think might read better in the spec. I'll leave it up to you if you prefer the original text.

[mikekistler]

How about this slightly more concise wording:

Suggested change

	The wording above is intended to distinguish between API URLs (which use the Server Object to determine the base URI or the prefix for the URL path template), and OAD URLs (which use the current document's base URI per RFC3986).
	However, only `$ref` was mentioned explicitly in versions 3.0.0 through 3.0.3 of this specification, leaving the behavior of the following fields ambiguous: the `operationRef` field of the [Link Object](#link-object), the URI form of the `mapping` field of the [Discriminator Object](#discriminator-object), the `externalValue` field of the [Example Object](#example-object), and the `url` fields of the [External Documentation](#external-documentation-object), [Contact](#contact-object), and [License](#license-object) Objects.
	Therefore, which of the above two rules is used for each of these fields is _implementation-defined_, although it is RECOMMENDED to use the `$ref` process for all of them for compatibility with future versions of this specification.
	Resolution of relative references in the `operationRef` field of the [Link Object](#link-object), the URI form of the `mapping` field of the [Discriminator Object](#discriminator-object), the `externalValue` field of the [Example Object](#example-object), and the `url` fields of the [External Documentation](#external-documentation-object), [Contact](#contact-object), and [License](#license-object) Objects is _implementation-defined_. For compatibility with future versions of this specification, It is RECOMMENDED to use the same process as $ref, but MAY instead use the URLs defined in the [Server Object](#server-object) as a Base URI, as either interpretation was possible in previous versions of this specification.

[handrews]

@mikekistler I like most of the wording change but want to tweak it a bit further- will update shortly.

Waiting for @handrews' improvements

[handrews]

@mikekistler see how you like this latest change. I kept most of your deletions, but decided to entirely drop mention of previous drafts, and kept wording that highlights two important points:

• It is only implementation-defined which of the two alternatives is used; it is not implementation-defined without constraint
• The each / all wording indicates that tools don't have to choose the same process for every keyword in the list. For example, @darrelmiller (in our conversation after the TDC call) drew the line in a different place, which would put some in the list using Server Objects and some using the $ref process, and we don't want to invalidate that either

[mikekistler]

Looks good! 👍

[handrews]

Two TSC approvals, so I'm hitting the merge button.