Stream: fhircast-github
Topic: fhircast-docs / Issue #246 May 2019 Ballot Comment:
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot opened Issue #246
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Event Notification Request
Url: https://fhircast.hl7.org/specification/May2019Ballot/#event-notification
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Overloading the meaning of the event identifier may be problematic, especially considering that the table in the "Event Notification Request Details" section indicates "Event identifier used to recognize retried notifications. This id MUST be globally unique for the Hub, SHOULD be opaque to the subscriber and MAY be a GUID."
The latter part of this indicates that (basically) the subscriber shouldn't rely on interpretation of the id. This belongs in the discussion outside the table if it must remain (see #19 wrt this point).
Existing wording: The event identifier should be used to differentiate retried messages from user actions.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot labeled Issue #246
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Event Notification Request
Url: https://fhircast.hl7.org/specification/May2019Ballot/#event-notification
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Overloading the meaning of the event identifier may be problematic, especially considering that the table in the "Event Notification Request Details" section indicates "Event identifier used to recognize retried notifications. This id MUST be globally unique for the Hub, SHOULD be opaque to the subscriber and MAY be a GUID."
The latter part of this indicates that (basically) the subscriber shouldn't rely on interpretation of the id. This belongs in the discussion outside the table if it must remain (see #19 wrt this point).
Existing wording: The event identifier should be used to differentiate retried messages from user actions.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot labeled Issue #246
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Event Notification Request
Url: https://fhircast.hl7.org/specification/May2019Ballot/#event-notification
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Overloading the meaning of the event identifier may be problematic, especially considering that the table in the "Event Notification Request Details" section indicates "Event identifier used to recognize retried notifications. This id MUST be globally unique for the Hub, SHOULD be opaque to the subscriber and MAY be a GUID."
The latter part of this indicates that (basically) the subscriber shouldn't rely on interpretation of the id. This belongs in the discussion outside the table if it must remain (see #19 wrt this point).
Existing wording: The event identifier should be used to differentiate retried messages from user actions.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot labeled Issue #246
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Event Notification Request
Url: https://fhircast.hl7.org/specification/May2019Ballot/#event-notification
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Overloading the meaning of the event identifier may be problematic, especially considering that the table in the "Event Notification Request Details" section indicates "Event identifier used to recognize retried notifications. This id MUST be globally unique for the Hub, SHOULD be opaque to the subscriber and MAY be a GUID."
The latter part of this indicates that (basically) the subscriber shouldn't rely on interpretation of the id. This belongs in the discussion outside the table if it must remain (see #19 wrt this point).
Existing wording: The event identifier should be used to differentiate retried messages from user actions.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot edited Issue #246
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Event Notification Request
Url: https://fhircast.hl7.org/specification/May2019Ballot/#event-notification
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Overloading the meaning of the event identifier may be problematic, especially considering that the table in the "Event Notification Request Details" section indicates "Event identifier used to recognize retried notifications. This id MUST be globally unique for the Hub, SHOULD be opaque to the subscriber and MAY be a GUID."
The latter part of this indicates that (basically) the subscriber shouldn't rely on interpretation of the id. This belongs in the discussion outside the table if it must remain (see #19 wrt this point).
Existing wording: The event identifier should be used to differentiate retried messages from user actions.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 05 2019 at 01:11):
NiklasSvenzen labeled Issue #246
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Event Notification Request
Url: https://fhircast.hl7.org/specification/May2019Ballot/#event-notification
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Overloading the meaning of the event identifier may be problematic, especially considering that the table in the "Event Notification Request Details" section indicates "Event identifier used to recognize retried notifications. This id MUST be globally unique for the Hub, SHOULD be opaque to the subscriber and MAY be a GUID."
The latter part of this indicates that (basically) the subscriber shouldn't rely on interpretation of the id. This belongs in the discussion outside the table if it must remain (see #19 wrt this point).
Existing wording: The event identifier should be used to differentiate retried messages from user actions.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 23 2019 at 13:21):
wmaethner labeled Issue #246:
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Event Notification Request
Url: https://fhircast.hl7.org/specification/May2019Ballot/#event-notification
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Overloading the meaning of the event identifier may be problematic, especially considering that the table in the "Event Notification Request Details" section indicates "Event identifier used to recognize retried notifications. This id MUST be globally unique for the Hub, SHOULD be opaque to the subscriber and MAY be a GUID."
The latter part of this indicates that (basically) the subscriber shouldn't rely on interpretation of the id. This belongs in the discussion outside the table if it must remain (see #19 wrt this point).
Existing wording: The event identifier should be used to differentiate retried messages from user actions.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 23 2019 at 13:21):
wmaethner commented on Issue #246:
Hey @euvitudo,
We were wondering if this issue is a duplicate of #247, or does it bring up a different issue? If so do you have any proposed wording (also keeping in mind that we are planning on updating this text a bit as described in #247). Otherwise we are planning on marking this as Persuasive with Mod and resolving it along with #247.
Github Notifications (FHIRcast) (May 23 2019 at 15:33):
euvitudo commented on Issue #246:
Hi @wmaethner,
#247 was regarding the subscriber perspective--i.e., that the text mentions the subscriber shouldn't be able to gain information from the ID; this was addressed by @isaacvetter's proposed wording.This issue, however, is more focused on the event ID. Basically it seems irrelevant that the ID is used by the hub to identify retried notifications as that seems to be an implementation detail in the hub. As such it seems to me that it doesn't belong in the spec.
I also noticed that a couple paragraphs above, it states: "The event identifier should be used to differentiate retried messages from user actions." Is there a use case laid out in the spec (or some supporting document) that discusses this? If not, then I think there should be; otherwise I see two options: either (1) the wording can be updated to 'may' versus 'should', or (2) it should remain an implementation detail of the hub and shouldn't be part of the spec.
Github Notifications (FHIRcast) (May 28 2019 at 14:57):
isaacvetter commented on Issue #246:
## :telephone_receiver: II Working Group Vote (5-28-2019)
Meeting notes: https://confluence.hl7.org/display/IMIN/Teleconferences
@isaacvetter moved the following disposition, seconded by @wmaethner
Disposition: Persuasive with Mod
Disposition Comment: Adopt proposed wording. We will also clarify in theRequest Context Changesection that the requester'sidshall be preserved when the hub broadcasts an event.
Current wording: The event identifier should be used to differentiate retried messages from user actions.
Proposed wording: The event identifier may be used to differentiate retried messages from user actions.:+1: For: 9
:expressionless: Abstain: 0
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (May 28 2019 at 14:57):
wmaethner labeled Issue #246:
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Event Notification Request
Url: https://fhircast.hl7.org/specification/May2019Ballot/#event-notification
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Overloading the meaning of the event identifier may be problematic, especially considering that the table in the "Event Notification Request Details" section indicates "Event identifier used to recognize retried notifications. This id MUST be globally unique for the Hub, SHOULD be opaque to the subscriber and MAY be a GUID."
The latter part of this indicates that (basically) the subscriber shouldn't rely on interpretation of the id. This belongs in the discussion outside the table if it must remain (see #19 wrt this point).
Existing wording: The event identifier should be used to differentiate retried messages from user actions.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Sep 10 2019 at 18:23):
isaacvetter closed Issue #246:
May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Event Notification Request
Url: https://fhircast.hl7.org/specification/May2019Ballot/#event-notification
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Overloading the meaning of the event identifier may be problematic, especially considering that the table in the "Event Notification Request Details" section indicates "Event identifier used to recognize retried notifications. This id MUST be globally unique for the Hub, SHOULD be opaque to the subscriber and MAY be a GUID."
The latter part of this indicates that (basically) the subscriber shouldn't rely on interpretation of the id. This belongs in the discussion outside the table if it must remain (see #19 wrt this point).
Existing wording: The event identifier should be used to differentiate retried messages from user actions.
_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
