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

Reconciling MAY/can vs. SHOULD #101

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
4 participants
@MikeBishop
Copy link
Contributor

commented Oct 6, 2015

Client MAY (2.2) vs. SHOULD (2.4) use alternatives they're aware of; clients "can" (2.4) vs. SHOULD (5) include the Alt-Used header. Reconciling these both to SHOULDs.

Reconciling MAY/can and SHOULD
Client MAY (2.2) vs. SHOULD (2.4) use alternatives they're aware of;
clients "can" (2.4) vs. SHOULD (5) include the Alt-Used header.
Reconciling these both to SHOULDs.
@martinthomson

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2015

LGTM

@reschke reschke added the alt-svc label Oct 7, 2015

@reschke

This comment has been minimized.

Copy link

commented on draft-ietf-httpbis-alt-svc.xml in e70e63e Oct 7, 2015

That's intentional because it's just a forward reference to the spec text with the normative SHOULD (which we do not want to duplicate).

@reschke

This comment has been minimized.

Copy link

commented on draft-ietf-httpbis-alt-svc.xml in e70e63e Oct 7, 2015

  1. Alt-Svc is optional, so we can't put a SHOULD in here. 2) That being said, this is just an intro with the detail being in section 2.4, so I believe we should say "can" here.

@mnot mnot added the design label Nov 2, 2015

@mnot

This comment has been minimized.

Copy link
Member

commented Nov 2, 2015

Discussed in Yokohama; this pull request seems reasonable.

reschke added a commit that referenced this pull request Nov 4, 2015

@reschke

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2015

There are unfortunately 2 change request here, one of which I partly agree with, the other I disagree with.

The first one is caused by having normative language spread over 2.2 and 2.4; I tried to address this in acc3ae3.

The second one is about adding a duplicate requirement; I continue to believe we shouldn't do that. We can mention requirements multiple times, but only one place should have the magic keyword (otherwise we risk ending up with exactly the kind of inconsistencies this pull request is about).

@MikeBishop are you ok with the change?

@mnot

This comment has been minimized.

Copy link
Member

commented Feb 4, 2016

I think this is resolved, but if you disagree, please open a new issue ASAP.

@mnot mnot closed this Feb 4, 2016

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.