Add Stream ID

[FragLegs]

This PR does a number of things:

• Most notably, it implements the changed described in issue #4 - Adding a Stream ID
• It reorders the sections so that information about creating/updating/deleting the stream comes before information about setting/getting the stream status
• It adds Shayne Miel as a coauthor
• It adds some info to the README to help others who might work on the spec

[FragLegs]

However, there is a slight wrinkle with the stream ID that I didn't foresee. How should we indicate to transmitters and receivers that they need a way to identify which stream is being POLLed or PUSHed?

For PUSH it is easy - we can leave it up to the Receiver to set either a URL param in the endpoint or use a specific endpoint that dictates the stream ID. It is a little complicated though since the Receiver does not know the stream ID when creating the stream, which would force them to provide the "delivery" info during a second request. How much of this should we call out in the spec?

For POLL it is up to the Transmitter to do the right thing and add a URL param or a specific endpoint for each stream. Do we need to call that out in the spec?

A third option would be to extend the POLL spec to include a stream_id parameter, but that seems like a big lift.

[adeinega]

As an (almost) completely random comment, it would be great to keep only *.md documents in the repo, for example, openid-sse-framework-1_0.md, and then

1. use https://github.com/cabo/kramdown-rfc to convert .md to .xml
2. convert *.xml using xml2rfc to txt and HTML files when you they need to be published in other (external) places

It'll allow keeping the number of changes very low and easily review them. Moreover, Markdown files are convenient to edit even though the Web UI of GitHub.

[timcappalli]

As an (almost) completely random comment, it would be great to keep only *.md documents in the repo, for example, openid-sse-framework-1_0.md, and then

1. use https://github.com/cabo/kramdown-rfc to convert .md to .xml
2. convert *.xml using xml2rfc to txt and HTML files when you they need to be published in other (external) places

It'll allow keeping the number of changes very low and easily review them. Moreover, Markdown files are convenient to edit even though the Web UI of GitHub.

that's the plan. Just haven't had a change to convert the others to MD and then set up GH actions

[FragLegs]

However, there is a slight wrinkle with the stream ID that I didn't foresee. How should we indicate to transmitters and receivers that they need a way to identify which stream is being POLLed or PUSHed?

For PUSH it is easy - we can leave it up to the Receiver to set either a URL param in the endpoint or use a specific endpoint that dictates the stream ID. It is a little complicated though since the Receiver does not know the stream ID when creating the stream, which would force them to provide the "delivery" info during a second request. How much of this should we call out in the spec?

For POLL it is up to the Transmitter to do the right thing and add a URL param or a specific endpoint for each stream. Do we need to call that out in the spec?

A third option would be to extend the POLL spec to include a stream_id parameter, but that seems like a big lift.

I added notes in the PUSH/POLL section to indicate the uniqueness needs of the URLs.

[tulshi]

In the Transmitter Configuration Metadata, should we modify the "delivery methods supported" to include the POLL URL if the method is POLL?

On Tue, Sep 13, 2022 at 6:34 AM FragLegs @.***> wrote:

However, there is a slight wrinkle with the stream ID that I didn't foresee. How should we indicate to transmitters and receivers that they need a way to identify which stream is being POLLed or PUSHed?

For PUSH it is easy - we can leave it up to the Receiver to set either a URL param in the endpoint or use a specific endpoint that dictates the stream ID. It is a little complicated though since the Receiver does not know the stream ID when creating the stream, which would force them to provide the "delivery" info during a second request. How much of this should we call out in the spec?

For POLL it is up to the Transmitter to do the right thing and add a URL param or a specific endpoint for each stream. Do we need to call that out in the spec?

A third option would be to extend the POLL spec to include a stream_id parameter, but that seems like a big lift.

I added notes in the PUSH/POLL section to indicate the uniqueness needs of the URLs.

— Reply to this email directly, view it on GitHub https://github.com/openid/sse/pull/9#issuecomment-1245422445, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB55UGYF2DEXPXDTHOW7SKDV6B7F7ANCNFSM5VC65TEA . You are receiving this because your review was requested.Message ID: @.***>

[FragLegs]

That’s a good idea, but can we make it a separate issue/PR? I think there’s enough to discuss there to warrant a separate issue.

On Thu, Sep 15, 2022 at 7:54 PM Atul Tulshibagwale @.***> wrote:

In the Transmitter Configuration Metadata, should we modify the "delivery methods supported" to include the POLL URL if the method is POLL?

On Tue, Sep 13, 2022 at 6:34 AM FragLegs @.***> wrote:

However, there is a slight wrinkle with the stream ID that I didn't foresee. How should we indicate to transmitters and receivers that they need a way to identify which stream is being POLLed or PUSHed?

For PUSH it is easy - we can leave it up to the Receiver to set either a URL param in the endpoint or use a specific endpoint that dictates the stream ID. It is a little complicated though since the Receiver does not know the stream ID when creating the stream, which would force them to provide the "delivery" info during a second request. How much of this should we call out in the spec?

For POLL it is up to the Transmitter to do the right thing and add a URL param or a specific endpoint for each stream. Do we need to call that out in the spec?

A third option would be to extend the POLL spec to include a stream_id parameter, but that seems like a big lift.

I added notes in the PUSH/POLL section to indicate the uniqueness needs of the URLs.

— Reply to this email directly, view it on GitHub https://github.com/openid/sse/pull/9#issuecomment-1245422445, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB55UGYF2DEXPXDTHOW7SKDV6B7F7ANCNFSM5VC65TEA

. You are receiving this because your review was requested.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/openid/sse/pull/9#issuecomment-1248764410, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHK3GG52J755CCR5DAO2D3V6OZJPANCNFSM5VC65TEA . You are receiving this because you authored the thread.Message ID: @.***>