Additional details are needed for the logistical utilization of subscriptions

[RickBullotta]

For subscriptions, we should add a flag with the initial subscription request to indicate whether the provider should send "most recent values" or just wait for new values to arrive

What is the scope of subscription IDs? How durable are they (e.g. Are they ephemeral or would they survive a server/provider restart?)

Is there any type of keep-alive mechanism? I think that it is essential.

We should clarify how both ends should handle communications errors, broken connections, etc... (e.g. When to automatically unsubscribe a client, when to resubscribe vs just reconnect, etc)

We need some type of wildcarding mechanism for subscriptions. Having to enumerate all of the elementIds is not ideal in large systems, plus it isn't "adaptive" when new objects are added that would satisfy the wildcard expression

Wildcard expressions would also be useful for reads

[matthewGEA]

@RickBullotta
Including most recent values on subscription creation
I prefer to keep the READ function and SUBSCRIBE function separate, where a client can do a READ asynchronously at any time to get the LastKnownValue, even at the start of a subscription.

Durability of subscriptionIDs
This is undefined. I proposed a harmonization of QoS0 and QoS2 methods with this issue, which could provide some overlap with MQTT Persistent Sessions. Assuming the server creates a GUID subscriptionID, it would be up to the client to persist that unique ID across reboots, and would also require adding a requiremnet in the spec for a server to maintain subscriptionIDs across reboots

Keep alive
I don't believe this has been defined. Please confirm that this would only be needed for QoS0 method, as the QoS2 method is the client contacting the server so no keep alive is required?

Define reconnect behavior
Yes, this will need to be done in the spec

Subscription Wildcards
Request you remove that item from this issue and track on #135 ?

[RickBullotta]

There's a latency/race condition potentially with that approach Matt (separate subscription/read).

Keep-alives are good practice always, if for no other reason than detecting a broken TCP connection (which many OS's and languages don't handle well unless you actively try to transmit)

[jwise-mfg]

Wildcard feature tracked as #135
Other feature requests can be discussed in vNext