You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Topic-data interactions are publish, subscribe, unsubscribe, read, and delete. These operations are oriented on how data is transferred from a publisher to a subscriber.
146
146
147
-
<!--
148
-
Throughout the document there is a number of TBDs that need updating, mostly content formats or cbor data representations
149
-
-->
150
-
151
147
## Managing Topics {#managing-topics}
152
148
153
149
{{fig-api}} shows the resources related to a Topic Collection that can be managed at the Broker.
@@ -296,10 +292,6 @@ Each topic collection is associated with a group of topic resources, each detail
296
292
297
293
Below is an example of discovery via /.well-known/core with rt=core.ps.conf that returns a list of topics, as the list of links to the corresponding topic resources.
298
294
299
-
<!--
300
-
TODO: add the ct part in IANA and add the example here:
301
-
- If you want to indicate ct= in one of this links, then it should be ct=X, where is the the Content-Format identifier for application/core-pubsub+cbor
302
-
-->
303
295
304
296
~~~~
305
297
Request:
@@ -320,15 +312,6 @@ TODO: add the ct part in IANA and add the example here:
320
312
321
313
### Topic-Data Discovery
322
314
323
-
<!--
324
-
TODO DISCUSS Decide on this section
325
-
326
-
Also, as based on {{ection 1.2.2 of RFC6690}}, I'd realistically expect to have located by /.well-known/core certainly the topic collection resources and MAYBE the topic resources (and likely limited only to "perpetual", hence well-known topics).
327
-
328
-
Instead, I'd expect to discover the links to the topic resources mostly by GET/FETCH accessing the topic collection resource.
329
-
330
-
Practically, you may have to literally *discover* the broker, its collection resource, and a particular topic resource. At that point, you just *learn* the URI of the topic-data resource, from the corresponding parameter within the exact, corresponding topic resource.
331
-
-->
332
315
333
316
Within a topic, there is the topic-data property containing the URI of the topic-data resource that a CoAP client can subscribe and publish to. Resources exposing resources of the topic-data type are expected to use the resource type 'core.ps.data'.
334
317
@@ -441,7 +424,7 @@ The broker MUST issue a 4.00 (Bad Request) error if a received parameter is inva
@@ -698,11 +681,6 @@ URIs for topic resources are broker-generated (see {{topic-create}}). There is n
698
681
699
682
When a topic is newly created, it is first placed by the broker into the HALF CREATED state (see {{fig-life}}). In this state, a client can read and update the configuration of the topic and delete the topic. A publisher can publish to the topic-data resource. However, a subscriber cannot yet subscribe to the topic-data resource nor read the latest data.
700
683
701
-
<!--
702
-
TODO I got a comment that mqtt folks my want to pre-subscribe to topics, so they'd like to be able to place an observation even if the resource is not "fully created"
703
-
704
-
Also, we might want to restrict the discovery part ONLY for FULLY created topics. If so, let's mention it.
705
-
-->
706
684
707
685
~~~~ aasvg
708
686
HALF FULLY
@@ -729,15 +707,6 @@ When a client deletes a topic-data, the topic is placed into the HALF CREATED st
See comments above. I'm not sure whether the client should have any say on where the topic-data resource is hosted.
735
-
736
-
It'd already be difficult to have some sort of coordination between the broker and the separate server hosting the topic-data resource, let alone involving the client as yet another actor in the process.
737
-
738
-
JJ: Also note that the broker has no way to know anything about a topic-data hosted elsewhere.
739
-
-->
740
-
741
710
Interactions with the topic-data resource are covered in this section.
742
711
743
712
### Publish {#publish}
@@ -807,14 +776,6 @@ On success, the server hosting the topic-data resource MUST return 2.05 (Content
807
776
808
777
If the topic is not yet in the fully created state (see {{topic-lifecycle}}) the broker MUST return a response code 4.04 (Not Found).
809
778
810
-
<!--
811
-
TODO: After a publisher publishes to the topic-data for the first time, the topic is placed into the FULLY CREATED state.
812
-
813
-
This is a problem if the topic-data is hosted elsewhere and not in the broker, how does the broker know when to put it in fully created state if the pub/sub mechanism is happening directly btw pub and sub?
814
-
815
-
Shall I add: The topic-data URI may link to resources that are not hosted directly by the broker as shown in {{fig-external-server}}.
816
-
Thus, subscribers would use the broker for discovery only.
817
-
-->
818
779
819
780
The following response codes are defined for the Subscribe operation:
820
781
@@ -826,9 +787,6 @@ Failure:
826
787
827
788
If the 'max-subscribers' parameter has been reached, the broker must treat that as specified in {{Section 4.1 of RFC7641}}. The response MUST NOT include an Observe Option, the absence of which signals to the subscriber that the subscription failed.
828
789
829
-
<!--
830
-
TODO Right. However, how can this work when the server hosting the topic-data resource is not the broker? The broker knows the maximum number of subscribers, but that separate server does not. Is it just up to a not-specified-here synchronization protocol between the broker and that server?
831
-
-->
832
790
833
791
Example of a successful subscription followed by one update:
834
792
@@ -878,24 +836,13 @@ As per {{RFC7641}} a server that transmits notifications mostly in non-confirmab
878
836
879
837
This value can be modified at the broker by the administrator of a topic by modifying the parameter "observer-check" on {{topic-resource-representation}}. This would allow changing the rate at which different implementations verify that a subscriber is still interested in observing a topic-data resource.
880
838
881
-
<!--
882
-
TODO: another item that points to make topic-data a broker thing only.
883
-
884
-
Yes, and again, what if the topic-data resource is not hosted at the broker but at a different server? Is it just up to a not-specified-here synchronization protocol between the broker and that server?
885
-
-->
886
839
887
840
### Delete topic-data {#delete-topic-data}
888
841
889
842
A publisher MAY delete a topic by making a CoAP DELETE request on the topic-data URI.
890
843
891
844
On success, the broker returns a 2.02 (Deleted) response.
892
845
893
-
894
-
<!--
895
-
Q: Same question here, why is this a SHOULD (see comment above).
896
-
A: Changed to MUST but I think we could discuss it. Could the broker have reasons to keep the uri of the topic-data path for later reuse in some cases? for example the broker could also implement a different behaviour for the topic-data deletion, sending back 2.02 but keeping the resource in fully created state without returning a final 4.04 to cancel existing observations BUT still having the resource addressable to allow normal GET on it, for example for retrieving the last published/historical value/s. I am ambivalent here and would welcome guidance from others. I think MUST should not be used if there are no interoperability issues cause by using SHOULD.
897
-
-->
898
-
899
846
When a topic-data resource is deleted, the broker MUST also delete the topic-data parameter in the topic resource, unsubscribe all subscribers by removing them from the list of observers and return a final 4.04 (Not Found) response as per {{Section 3.2 of RFC7641}}. The topic is then set back to the half created state as per {{topic-lifecycle}}.
900
847
901
848
Example of a successful deletion:
@@ -946,15 +893,6 @@ Example:
946
893
}
947
894
~~~~
948
895
949
-
<!--
950
-
TODO: Do we add wildcards here?
951
-
https://github.com/core-wg/coap-pubsub/issues/42
952
-
953
-
### Subscribe to a subset of topic-data resources {#wildcard}
954
-
955
-
Some implementations may want to subscribe to multiple topic-data resources with one single request. That is possible by using FETCH with
956
-
957
-
-->
958
896
959
897
## Rate Limiting {#rate-limit}
960
898
@@ -970,23 +908,21 @@ This document defines parameters used in the messages exchanged between a client
970
908
971
909
Note that the media type application/core-pubsub+cbor MUST be used when these parameters are transported in the respective message fields.
972
910
973
-
<!-- To be registerd in IANA: TODO Populate the TBDs non-negative unsigned -->
0 commit comments