Re: [Netconf] SSE and HTTP/2 in restcon-notif

[Qin Wu <[e-mail]>]

>    I envision the variation being relatively
>    minor, something along the line of:
>
>      if 1.1, then SSE.
>      if 2.0, client MAY open a stream first.
>
> 3) resource URIs
>
>    This is likely where we need to spend the most time. We know that
>    establish-subscription returns a dynamically created URI, comparable
>    to what a client might get from ietf-restconf-monitoring:restconf-state\
>    /streams/stream/access/location.

But it is not quite comparable.  In the 8040 solution, the location
url is static, and then query parameters are provided by the client
in the POST to the SSE location.  Thus, the server can free any
resources associated with the filter when the connection is
terminated.


The RESTCONF procedure starts with the client
examining /restconf-state/streams to determine stream and its location URL
How does this monitoring information relate to the new solution?
I assume both the old and new procedures can be supported by the same server.
Is it just ignored for a new subscription?

Since all SSE data is always media type test/event-stream, each stream entry indicates
its secondary encoding format. This leaf is type string, and only 'xml' and 'json' are supported
in RFC 8040. The establish-subscription RPC has its own leaf for this purpose.


[Qin]: I am lost, should resource URIs returned by establish-subscription same as location URL obtained from
ietf-restconf-monitoring:restconf-state\/streams/stream/access/location.
My understanding is if SSE is supported, let’s say HTTP 1.1, we will use location URL returned from
ietf-restconf-monitoring:restconf-state\/streams/stream/access/location
as input parameter to trigger SSE. In case of SSE being supported, HTTP GET(URI) is not needed ? wrong?
But if SSE is not supported, let’s say HTTP/2, location URL is not needed. HTTP POST(URI) is required.
Please correct me, if I am wrong.