Optionality of Hub Support of hub.channel.type

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIRCast (FHIR)
    • 0.1 [deprecated]
    • Infrastructure & Messaging
    • (NA)
    • http://fhircast.org/specification/Feb2020Ballot Section: Subscription Response
    • Hide

      Will update spec to clarify that:

      A FHIRcast Hub SHALL support websockets and MAY support rest-hooks. Will also clarify, as author suggests, that a Hub may reject a subscription with hub.channel.type=rest-hooks, if the Hub does not support this channel type. 

       

      Show
      Will update spec to clarify that: A FHIRcast Hub SHALL support websockets and MAY support rest-hooks. Will also clarify, as author suggests, that a Hub may reject a subscription with hub.channel.type=rest-hooks, if the Hub does not support this channel type.   
    • Eric Martin / Will Maethner: 9-0-0
    • Enhancement
    • Compatible, substantive

      Should FHIRcast Hubs be able to support only a single channel type or is it mandatory that they support both webhook and websocket channels?

      Assuming support for one or the other channel type being optional, should we explicitly mention in 'Subscription Response' section that one reason for denying a subscription request is that the Hub does not support the requested hub.channel.type? For example, add the quoted and italicized text:

      was received and will now be verified by the Hub. "Since support of both Hub channel types is not required the Hub may reject the subscription request if the requested hub.channel.type is not supported." If using websockets

            Assignee:
            William Maethner
            Reporter:
            ericmartinatsiemens
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: