Stream: fhircast-github
Topic: fhircast-docs / Issue #92 May 2019 Ballot Comment: Clarif...
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot opened Issue #92
## May 2019 Ballot Comment: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Subscription Request
Url:
Type: A-S ClarificationSummary: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Comment: It's a little ambiguous what "new parameters" actually refers to here. The WebSub intent is to preserve client defined querystring params when the Hub adds it's own params. The Hub isn't responsible for tracking previous client-defined params and combining those with new, client-defined params.
Existing wording: Hubs MUST preserve the query string during subscription verification by appending new parameters to the end of the list using the & (ampersand) character to join.
Proposed wording: Hubs MUST preserve the query string during subscription verification by appending new, Hub-defined parameters to the end of the list using the & (ampersand) character to join.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot labeled Issue #92
## May 2019 Ballot Comment: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Subscription Request
Url:
Type: A-S ClarificationSummary: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Comment: It's a little ambiguous what "new parameters" actually refers to here. The WebSub intent is to preserve client defined querystring params when the Hub adds it's own params. The Hub isn't responsible for tracking previous client-defined params and combining those with new, client-defined params.
Existing wording: Hubs MUST preserve the query string during subscription verification by appending new parameters to the end of the list using the & (ampersand) character to join.
Proposed wording: Hubs MUST preserve the query string during subscription verification by appending new, Hub-defined parameters to the end of the list using the & (ampersand) character to join.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot edited Issue #92
## May 2019 Ballot Comment: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Subscription Request
Url:
Type: A-S ClarificationSummary: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Comment: It's a little ambiguous what "new parameters" actually refers to here. The WebSub intent is to preserve client defined querystring params when the Hub adds it's own params. The Hub isn't responsible for tracking previous client-defined params and combining those with new, client-defined params.
Existing wording: Hubs MUST preserve the query string during subscription verification by appending new parameters to the end of the list using the & (ampersand) character to join.
Proposed wording: Hubs MUST preserve the query string during subscription verification by appending new, Hub-defined parameters to the end of the list using the & (ampersand) character to join.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 30 2019 at 03:25):
isaacvetter commented on Issue #92:
Proposed resolution: Persuasive
Proposed resolution comment: Will update wording as suggested.
Github Notifications (FHIRcast) (May 30 2019 at 03:25):
isaacvetter labeled Issue #92:
## May 2019 Ballot Comment: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Subscription Request
Url:
Type: A-S ClarificationSummary: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Comment: It's a little ambiguous what "new parameters" actually refers to here. The WebSub intent is to preserve client defined querystring params when the Hub adds it's own params. The Hub isn't responsible for tracking previous client-defined params and combining those with new, client-defined params.
Existing wording: Hubs MUST preserve the query string during subscription verification by appending new parameters to the end of the list using the & (ampersand) character to join.
Proposed wording: Hubs MUST preserve the query string during subscription verification by appending new, Hub-defined parameters to the end of the list using the & (ampersand) character to join.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Jun 18 2019 at 15:52):
wmaethner labeled Issue #92:
## May 2019 Ballot Comment: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Subscription Request
Url:
Type: A-S ClarificationSummary: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Comment: It's a little ambiguous what "new parameters" actually refers to here. The WebSub intent is to preserve client defined querystring params when the Hub adds it's own params. The Hub isn't responsible for tracking previous client-defined params and combining those with new, client-defined params.
Existing wording: Hubs MUST preserve the query string during subscription verification by appending new parameters to the end of the list using the & (ampersand) character to join.
Proposed wording: Hubs MUST preserve the query string during subscription verification by appending new, Hub-defined parameters to the end of the list using the & (ampersand) character to join.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Jun 18 2019 at 15:52):
wmaethner commented on Issue #92:
## :landline: II Working Group Vote (6-18-2019)
Block vote@isaacvetter moved the following disposition, seconded by Ricardo Quintano Neira
Disposition: Persuasive
Disposition Comment: Will fix as described in the issue comments or by the commenter:+1: For: 10
:expressionless: Abstain: 2
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (Jun 28 2019 at 14:15):
wmaethner labeled Issue #92:
## May 2019 Ballot Comment: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Subscription Request
Url:
Type: A-S ClarificationSummary: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Comment: It's a little ambiguous what "new parameters" actually refers to here. The WebSub intent is to preserve client defined querystring params when the Hub adds it's own params. The Hub isn't responsible for tracking previous client-defined params and combining those with new, client-defined params.
Existing wording: Hubs MUST preserve the query string during subscription verification by appending new parameters to the end of the list using the & (ampersand) character to join.
Proposed wording: Hubs MUST preserve the query string during subscription verification by appending new, Hub-defined parameters to the end of the list using the & (ampersand) character to join.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Aug 19 2019 at 14:08):
wmaethner closed Issue #92:
May 2019 Ballot Comment: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Subscription Request
Url:
Type: A-S ClarificationSummary: Clarify that Hub isn't responsible for tracking client querystring parameters on updated callback url.
Comment: It's a little ambiguous what "new parameters" actually refers to here. The WebSub intent is to preserve client defined querystring params when the Hub adds it's own params. The Hub isn't responsible for tracking previous client-defined params and combining those with new, client-defined params.
Existing wording: Hubs MUST preserve the query string during subscription verification by appending new parameters to the end of the list using the & (ampersand) character to join.
Proposed wording: Hubs MUST preserve the query string during subscription verification by appending new, Hub-defined parameters to the end of the list using the & (ampersand) character to join.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Last updated: Apr 12 2022 at 19:14 UTC
