Remove extension mechanism from base spec.

[dgeb]

Instead of rushing the extension mechanism into the 1.0 release, we are
marking it as experimental and removing it from the base spec.

This allows us to solidify the extension concepts for a future release.

[bintoro]

Okay, so will extensions use a completely different media type eventually, or how does this work in terms of 1.0 implementations and their lack of awareness of the ext parameter?

[dgeb]

1.0 client implementations won't be aware of the ext parameter or any media type parameters.

We should probably explicitly declare that media type parameters must be ignored. I was debating where to place such a statement.

[dgeb]

I am working on wording in the base spec regarding the ext parameter to ensure that it's future compatible. Will update soon...

[dgeb]

I've introduced a media type negotiation section in the base spec - please review carefully 85d8386

[ethanresnick]

Can we start the sentence that says "The supported-ext and ext..." with the clause "Currently, ", to suggest that the parameters may change?

[ethanresnick]

@dgeb Thanks for punting on extensions for now, so that we can both get the mechanism right and still get 1.0 out tonight! That seems like the right call.

A couple other things:

1. Any chance that punting on extensions means we have the bandwidth to further consider the attempted-"best of all worlds" proposal I made for include rules? I responded to your last comment earlier. If you agree with the solution in concept, then I can work up the PR!
2. Once we tag 1.0 tonight, what are your thoughts on having a delay of a week or so before doing any big 1.0 promo campaigns? That would give client libraries, which I suspect are almost all be broken now, given the rapid changes over the last two days, a chance to catch up.

[dgeb]

Any chance that punting on extensions means we have the bandwidth to further consider the attempted-"best of all worlds" proposal I made for include rules?

Commented

what are your thoughts on having a delay of a week or so before doing any big 1.0 promo campaigns?

Lines up well with #661 :)

[tkellen]

Nicely done @dgeb! I'm really glad we've decided to take this approach. 👍 from me.

[ethanresnick]

Thanks @dgeb! Also, any comments on #660 (comment)?

[dgeb]

@ethanresnick see #660 (comment)

We now have a little time to ensure the correctness and readability of this section.

[bintoro]

The new section on media type negotiation distinguishes between ext and other parameters. Is this mainly to allow proprietary parameters for versioning and such?

[dgeb]

The intent is to reserve the ext parameter as a way to request an extension. 1.0 servers won't support extensions and therefore need to reject all such requests (which may come from 1.1 clients that use ext).

[bintoro]

@dgeb Sorry, I phrased that poorly. What I mean is, why not put a blanket ban on all parameters? I'm assuming this is because we want to allow APIs to use the same header for their own stuff, too. This is fine, but it also implies that JSON API will never use anything besides ext.

[dgeb]

This is fine, but it also implies that JSON API will never use anything besides ext.

@bintoro Given the current requirements on the server, I think this could more accurately be said "JSON API will never use another media type parameter besides ext to negotiate an extension".

Since this PR is now merged, please open an issue to discuss this further if you like. I'm not sure it's a major problem, but we should be clear-eyed about the implications and alternatives.