need to define extensibility for alt-svc parameters

[reschke]

must ignore? how to register new ones? IANA registry?

[enygren]

From discussions in various threads, it is sounding like "must ignore" is a better default behavior for unknown parameters. Otherwise trying to guess which combinations of parameters will cause an AltSvc to be ignored becomes impossibly unwieldy. If "manditory to understand before using a service" parameters are necessary, Martin has the good suggestion of adding a parameter that lists those extension parameters where not understanding them should cause a client to ignore a service. For example a parameter:
must="manditory1,manditory2"
such that:
Alt-Svc: h2=":443"; ma=60; manditory1=1; manditory2="foo"; optional1="bar"; must="manditory1,manditory2"

Would cause the service to be ignored if the client didn't understand manditory1 or manditory2, but optional1 would be ignored if not understood.

[reschke]

I've seen that before in http://greenbytes.de/tech/webdav/rfc2774.html#end-to-end.extensions :-)

[mnot]

... which was promptly ignored by the whole world (except for spawning SOAP, and we know how that went...)

[mnot]

Discussed in Prague; sense of the room is to have extensibility at the parameter level. Also, sense was to go ahead and establish a registry.

[reschke]

So must-ignore-unknown parameters (but process what remains), and add registry, right?

[mnot]

yes.

[reschke]

"IETF review", I guess? (would be the same as Cache-Control)

[mnot]

Let's talk on-list. I think that bar might be a bit high.

[reschke]

Changes done in eed78be, let's discuss IANA details separately when needed.