Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

need to define extensibility for alt-svc parameters #69

Closed
reschke opened this issue May 9, 2015 · 9 comments

Comments

Projects
None yet
3 participants
@reschke
Copy link
Contributor

commented May 9, 2015

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

@reschke reschke added the alt-svc label May 9, 2015

@mnot mnot added the design label May 27, 2015

@enygren

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2015

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 17, 2015

@mnot

This comment has been minimized.

Copy link
Member

commented Jul 17, 2015

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

@mnot

This comment has been minimized.

Copy link
Member

commented Jul 21, 2015

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.

@mnot mnot added the editor-ready label Aug 24, 2015

@reschke

This comment has been minimized.

Copy link
Contributor Author

commented Sep 1, 2015

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

@mnot

This comment has been minimized.

Copy link
Member

commented Sep 2, 2015

yes.

@reschke

This comment has been minimized.

Copy link
Contributor Author

commented Sep 2, 2015

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

@mnot

This comment has been minimized.

Copy link
Member

commented Sep 2, 2015

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

@reschke

This comment has been minimized.

Copy link
Contributor Author

commented Sep 19, 2015

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

reschke added a commit that referenced this issue Sep 19, 2015

@reschke reschke closed this Sep 19, 2015

@reschke reschke reopened this Sep 20, 2015

@reschke reschke closed this Sep 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.