FHIR Chat · fhircast-docs / Issue #245 May 2019 Ballot Comment: · fhircast-github

Stream: fhircast-github

Topic: fhircast-docs / Issue #245 May 2019 Ballot Comment:


view this post on Zulip Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):

hl7-fhircast-bot opened Issue #245

## May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):

hl7-fhircast-bot labeled Issue #245

## May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):

hl7-fhircast-bot labeled Issue #245

## May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):

hl7-fhircast-bot labeled Issue #245

## May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):

hl7-fhircast-bot edited Issue #245

## May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (May 05 2019 at 01:14):

NiklasSvenzen labeled Issue #245

## May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (May 05 2019 at 02:13):

NiklasSvenzen labeled Issue #245

## May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (May 09 2019 at 13:52):

isaacvetter commented on Issue #245

Hey @euvitudo, The 2,048 character limitation is about IE specifically, right?

Note that this is a backend web service call not occurring through a browser.

Do you know what the length limitations are in this case.

view this post on Zulip Github Notifications (FHIRcast) (May 09 2019 at 17:45):

euvitudo commented on Issue #245

Hi @isaacvetter, yes, that's a good point.

However, IIS has this (default) limit: https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/requestlimits/
i.e., 2048 for the query string, 4096 for the URL. We ran into this limitation when running queries against Epic in an IIS configuration!

Apache defaults the URL to 8190: https://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline

Tomcat appears to have a parameter-based limit (i.e., 10k parameters) versus length of the query string (see maxParameterCount here: https://tomcat.apache.org/tomcat-8.0-doc/config/http.html)

view this post on Zulip Github Notifications (FHIRcast) (May 16 2019 at 07:18):

lbergnehr commented on Issue #245:

This is actually mentioned in general terms in WebSub:

The spec uses GET vs POST to differentiate between the confirmation/denial of the subscription request and delivering the content. While this is not considered "best practice" from a web architecture perspective, it does make implementation of the callback URL simpler. Since the POST body of the content distribution request may be any arbitrary content type and only includes the actual content of the document, using the GET vs POST distinction to switch between handling these two modes makes implementations simpler.

It's also discussed in https://github.com/w3c/websub/issues/28. I've asked if they ever considered the url length issue when discussing GET vs. POST.

view this post on Zulip Github Notifications (FHIRcast) (May 16 2019 at 07:20):

lbergnehr assigned Issue #245:

## May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (May 16 2019 at 20:59):

crertel commented on Issue #245:

Please don't put everything into a URL query param.

Especially as queries grow, it's usually better to think of it as "create a new query object or request", and then POST makes more sense. You'll also spare yourself inevitable URL encoding issues.

view this post on Zulip Github Notifications (FHIRcast) (May 23 2019 at 15:06):

isaacvetter commented on Issue #245:

Hey @euvitudo ,

Breaking this down, here's the parameter's on the Intent Verification Request HTTP GET request:

HTTP GET param explanation length
hub.mode=unsubscribe fixed string 20 characters
hub.topic={16 character guid} session topic, likely a guid 26 characters
hub.events={comma-delimited list of events} This is the unbounded parameter. From our current Event Catalog, the human-readable event names are around 20 characters each. ~30 to infinite number of characters
hub.challenge=meu3we944ix80ox randomly generated secret ~30 characters
hub.lease_seconds=604800 Number of seconds in a week 24

So, the verification of a simple subscription to a single event has a querystring length of ~130 characters. Each additional event adds around 20 characters. If we adhere to the defaulted IIS querystring length of 2048, this would leave 1918 characters for additional events. Based on our expected event name length of 20 characters, this would allow another ~96 events.

That seems like a lot. We currently have 7 events defined, and are likely dropping two of those events as part of the ballot.

Phil, I agree with your sentiment and design philosophy. If we weren't basing FHIRcast on the published WebSub spec, this would be a slam dunk. I don't think that the two concerns:
1) HTTP GET querystring length is limited to 2048 characters
2) Url-encoding inevitably causes implementers problems
are sufficient justification for breaking compatibility with WebSub. Further, WebSub does provide a rationale for their non-RESTful use of HTTP methods:

NOTE
The spec uses GET vs POST to differentiate between the confirmation/denial of the subscription request and delivering the content. While this is not considered "best practice" from a web architecture perspective, it does make implementation of the callback URL simpler. Since the POST body of the content distribution request may be any arbitrary content type and only includes the actual content of the document, using the GET vs POST distinction to switch between handling these two modes makes implementations simpler.

And the discussion in the w3c/websub issue #28 elaborates on this design decision (as Leo points out).

@certel, my impression is that you are unlikely to ever implement FHIRcast and are simply providing helpful advice based upon your experience with Websub. I'd encourage you to continue to give this feedback directly to Websub.

Proposed resolution: Persuasive with Mod
Proposed resolution comments: We should probably steal WebSub's note explaining our non-RESTful handling of HTTP methods.

view this post on Zulip Github Notifications (FHIRcast) (May 23 2019 at 15:06):

isaacvetter labeled Issue #245 (assigned to lbergnehr):

## May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (May 23 2019 at 15:47):

crertel commented on Issue #245:

@isaacvetter your impression is correct, because a lot of us don't have, say, Epic's resources to throw at overengineered specs. :)

view this post on Zulip Github Notifications (FHIRcast) (May 23 2019 at 15:48):

crertel edited a comment on Issue #245:

@isaacvetter your impression is correct, because a lot of us don't have, say, Epic's resources to throw at overengineered and somewhat wrong specs. :)

view this post on Zulip Github Notifications (FHIRcast) (May 23 2019 at 15:48):

euvitudo commented on Issue #245:

Hey @isaacvetter,
This discussion brings up the following questions:

  • Why is FHIRcast "modeled on" WebSub?
  • Should FHIRcast simply be an extension to WebSub? (would certainly limit the wording in the spec)
  • Is FHIRcast more simply an implementation of WebSub versus a complete (seemingly independent, though not completely independent) spec?
  • If arguments are to fallback on WebSub's choices, then why even have a new spec?

view this post on Zulip Github Notifications (FHIRcast) (May 23 2019 at 17:12):

isaacvetter commented on Issue #245:

Hey Phil,

The upcoming ballot resolution calls are listed in confluence. If you're able to make one or more, we could prioritize review of your ballot comments on that call.

Isaac

view this post on Zulip Github Notifications (FHIRcast) (May 24 2019 at 07:11):

lbergnehr commented on Issue #245:

@euvitudo, there are inevitable details in FHIRcast that could never be relevant in WebSub, e.g. SMART launch and FHIR resources as data models. Modeling on exiting W3C specs and infrastructure has proven successful in many other standards, both in healthcare and more generally.

Whether it should be clearer how FHIRcast relates to WebSub is a fair question. Would you mind opening a new issue for that if you would like to pursue it further?

view this post on Zulip Github Notifications (FHIRcast) (Jun 27 2019 at 14:12):

isaacvetter commented on Issue #245:

## :telephone_receiver: II Working Group Vote (6-27-2019)

Meeting notes: https://confluence.hl7.org/display/IMIN/Teleconferences

@NiklasSvenzen moved the following disposition, seconded by Martin Bellehumeur

Disposition: Persuasive with Mod
Disposition Comment: We should probably steal WebSub's note explaining our non-RESTful handling of HTTP methods.

:+1: For: 9
:expressionless: Abstain: 0
:-1: Against: 0

:tada: The motion passed! :tada:

view this post on Zulip Github Notifications (FHIRcast) (Jun 27 2019 at 14:13):

wmaethner labeled Issue #245 (assigned to lbergnehr):

## May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (Sep 10 2019 at 18:11):

isaacvetter closed Issue #245 (assigned to lbergnehr):

May 2019 Ballot Comment:

Submitted by @euvitudo
Chapter/section: Intent Verification Response
Url: https://fhircast.hl7.org/specification/May2019Ballot/#subscribing-and-unsubscribing
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:

Summary:

Comment: The hub.events table entry indicates that the value can be a comma-separated list of events from the Event Catalog. With GET, this could be potentially limiting, as the URL maximum length is 2083 characters. While it is arguable that this limit might not be reached, it's certainly not a scalable option.

Existing wording: hub.events Required string A comma-separated list of events from the Event Catalog corresponding to the events string given in the corresponding subscription request.


_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