Stream: fhircast-github
Topic: fhircast-docs / Issue #208 May 2019 Ballot Comment:
Github Notifications (FHIRcast) (Apr 30 2019 at 19:53):
hl7-fhircast-bot opened Issue #208
## May 2019 Ballot Comment:
Submitted by Anthony Julian
Chapter/section: Event Notification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: I would think using these statuses to track synchronization state would be a best practice(SHOULD) not may.
Existing wording: The subscriber MUST respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber MUST respond with an HTTP 200; otherwise, the subscriber MUST respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
Proposed wording: The subscriber SHALL respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber SHALL respond with an HTTP 200; otherwise, the subscriber SHALL respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:53):
hl7-fhircast-bot labeled Issue #208
## May 2019 Ballot Comment:
Submitted by Anthony Julian
Chapter/section: Event Notification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: I would think using these statuses to track synchronization state would be a best practice(SHOULD) not may.
Existing wording: The subscriber MUST respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber MUST respond with an HTTP 200; otherwise, the subscriber MUST respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
Proposed wording: The subscriber SHALL respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber SHALL respond with an HTTP 200; otherwise, the subscriber SHALL respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:53):
hl7-fhircast-bot labeled Issue #208
## May 2019 Ballot Comment:
Submitted by Anthony Julian
Chapter/section: Event Notification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: I would think using these statuses to track synchronization state would be a best practice(SHOULD) not may.
Existing wording: The subscriber MUST respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber MUST respond with an HTTP 200; otherwise, the subscriber MUST respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
Proposed wording: The subscriber SHALL respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber SHALL respond with an HTTP 200; otherwise, the subscriber SHALL respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:53):
hl7-fhircast-bot labeled Issue #208
## May 2019 Ballot Comment:
Submitted by Anthony Julian
Chapter/section: Event Notification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: I would think using these statuses to track synchronization state would be a best practice(SHOULD) not may.
Existing wording: The subscriber MUST respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber MUST respond with an HTTP 200; otherwise, the subscriber MUST respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
Proposed wording: The subscriber SHALL respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber SHALL respond with an HTTP 200; otherwise, the subscriber SHALL respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 07 2019 at 12:58):
wmaethner labeled Issue #208
## May 2019 Ballot Comment:
Submitted by Anthony Julian
Chapter/section: Event Notification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: I would think using these statuses to track synchronization state would be a best practice(SHOULD) not may.
Existing wording: The subscriber MUST respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber MUST respond with an HTTP 200; otherwise, the subscriber MUST respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
Proposed wording: The subscriber SHALL respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber SHALL respond with an HTTP 200; otherwise, the subscriber SHALL respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 07 2019 at 12:59):
wmaethner commented on Issue #208
This change (along with the ANSI modal ones) seem fair. The purpose of the error statuses or to inform subscribers of issues so saying they SHOULD use them to track state makes sense. Any concerns @isaacvetter @NiklasSvenzen?
Github Notifications (FHIRcast) (May 07 2019 at 16:16):
NiklasSvenzen commented on Issue #208
Yes, I would bundle this with the other ANSI modal comments.
Github Notifications (FHIRcast) (May 08 2019 at 15:19):
NiklasSvenzen unlabeled Issue #208
## May 2019 Ballot Comment:
Submitted by Anthony Julian
Chapter/section: Event Notification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: I would think using these statuses to track synchronization state would be a best practice(SHOULD) not may.
Existing wording: The subscriber MUST respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber MUST respond with an HTTP 200; otherwise, the subscriber MUST respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
Proposed wording: The subscriber SHALL respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber SHALL respond with an HTTP 200; otherwise, the subscriber SHALL respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 08 2019 at 15:19):
NiklasSvenzen labeled Issue #208
## May 2019 Ballot Comment:
Submitted by Anthony Julian
Chapter/section: Event Notification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: I would think using these statuses to track synchronization state would be a best practice(SHOULD) not may.
Existing wording: The subscriber MUST respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber MUST respond with an HTTP 200; otherwise, the subscriber MUST respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
Proposed wording: The subscriber SHALL respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber SHALL respond with an HTTP 200; otherwise, the subscriber SHALL respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 08 2019 at 17:53):
wmaethner commented on Issue #208
## Montreal May 2019 Working Group Vote
Isaac moved the following disposition, seconded by Niklas
Disposition: Persuasive
Disposition Comment: Will fix:+1: For: 10
:expressionless: Abstain: 0
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (May 08 2019 at 17:53):
wmaethner labeled Issue #208
## May 2019 Ballot Comment:
Submitted by Anthony Julian
Chapter/section: Event Notification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: I would think using these statuses to track synchronization state would be a best practice(SHOULD) not may.
Existing wording: The subscriber MUST respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber MUST respond with an HTTP 200; otherwise, the subscriber MUST respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
Proposed wording: The subscriber SHALL respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber SHALL respond with an HTTP 200; otherwise, the subscriber SHALL respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Sep 11 2019 at 20:38):
wmaethner closed Issue #208:
May 2019 Ballot Comment:
Submitted by Anthony Julian
Chapter/section: Event Notification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: I would think using these statuses to track synchronization state would be a best practice(SHOULD) not may.
Existing wording: The subscriber MUST respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber MUST respond with an HTTP 200; otherwise, the subscriber MUST respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
Proposed wording: The subscriber SHALL respond to the notification with an appropriate HTTP status code. In the case of a successful notification, the subscriber SHALL respond with an HTTP 200; otherwise, the subscriber SHALL respond with an HTTP error status code. The Hub MAY use these statuses to track synchronization state.
_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
