Skip to content

Commit b6e0c8c

Browse files
author
ID Bot
committed
Script updating archive at 2025-01-16T01:21:41Z. [ci skip]
1 parent 39fa5ad commit b6e0c8c

File tree

1 file changed

+95
-36
lines changed

1 file changed

+95
-36
lines changed

‎archive.json

+95-36
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"magic": "E!vIA5L86J2I",
3-
"timestamp": "2025-01-14T01:20:32.452693+00:00",
3+
"timestamp": "2025-01-16T01:21:37.890676+00:00",
44
"repo": "core-wg/coap-pubsub",
55
"labels": [
66
{
@@ -129,15 +129,15 @@
129129
"id": "MDU6SXNzdWUyMTgwNTg3MjI=",
130130
"title": "Response code for stale published value or empty response, \"no content\"",
131131
"url": "https://github.com/core-wg/coap-pubsub/issues/4",
132-
"state": "OPEN",
132+
"state": "CLOSED",
133133
"author": "mjkoster",
134134
"authorAssociation": "CONTRIBUTOR",
135135
"assignees": [],
136136
"labels": [],
137137
"body": "Currently we define a \"no content\" response, such as when a GET is done on a value which has expired its lifetime, with 2.04. We should probably define a new response code like 2.06 for this instead of trying to overload the 2.04 when used as a \"changed\" response to POST or PUT.",
138138
"createdAt": "2017-03-30T01:53:44Z",
139-
"updatedAt": "2018-07-18T21:52:06Z",
140-
"closedAt": null,
139+
"updatedAt": "2025-01-14T07:41:00Z",
140+
"closedAt": "2025-01-14T07:41:00Z",
141141
"comments": [
142142
{
143143
"author": "mjkoster",
@@ -152,6 +152,13 @@
152152
"body": "Suggest we create an equivalent response code to HTTP 202 Accepted\r\n\r\n202 Accepted\r\nThe request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.\r\n\r\nSuggest using 2.07\r\n\r\n",
153153
"createdAt": "2018-07-18T21:52:06Z",
154154
"updatedAt": "2018-07-18T21:52:06Z"
155+
},
156+
{
157+
"author": "jaimejim",
158+
"authorAssociation": "MEMBER",
159+
"body": "This issue IMO might be something to be handled in another document.",
160+
"createdAt": "2025-01-14T07:41:00Z",
161+
"updatedAt": "2025-01-14T07:41:00Z"
155162
}
156163
]
157164
},
@@ -160,7 +167,7 @@
160167
"id": "MDU6SXNzdWUyMTgwNjEzMjc=",
161168
"title": "POST for queueing doesn't solve the QoS issue with missed publications ",
162169
"url": "https://github.com/core-wg/coap-pubsub/issues/5",
163-
"state": "OPEN",
170+
"state": "CLOSED",
164171
"author": "mjkoster",
165172
"authorAssociation": "CONTRIBUTOR",
166173
"assignees": [],
@@ -169,9 +176,17 @@
169176
],
170177
"body": "If a client subscribes using Observe, there is no handshake on the observe response to indicate that the notification was received by the subscriber. Creating a list of published representations in the broker using POST only covers the case where the broker can't keep up with sending notifications. The notifications are still \"best effort\".\r\n\r\nTo solve the QoS issue, we should have the subscriber create a queueing resource on the broker, which is specific to that subscriber, for each subscribed topic for which more than \"best effort\" QoS is desired. This resource will store published representations until the subscriber can retrieve or accept them. \r\n\r\nThe subscriber may use GET to return the representation of the queueing resource, receiving a list of links to published representations which may then be fetched using GET. The subscriber would be responsible for removing the representations it has fetched.\r\n\r\nThis enables sleepy subscribers and subscribers behind NAT firewalls to receive notifications without data loss. \r\n\r\nWe may also provide a resource that may be observed which returns and removes representations from the queue, in published order, using GET or Observe. Using GET, the broker would return \"no data\" upon fetches to an empty queue.\r\n\r\nA sleepy subscriber could wake up, subscribe, receive notifications, unsubscribe, and sleep again.\r\n\r\nWe may also provide a means for the subscriber to request a push or \"web callback\" using PUT or POST to update a resource on the subscriber upon notifications.\r\n\r\nWe could keep \"simple pubsub\" as it is, and allow queueing pubsub as an optional feature for enhanced QoS, sleepy subscribers, etc.\r\n",
171178
"createdAt": "2017-03-30T02:14:21Z",
172-
"updatedAt": "2018-07-18T21:15:02Z",
173-
"closedAt": null,
174-
"comments": []
179+
"updatedAt": "2025-01-14T07:46:01Z",
180+
"closedAt": "2025-01-14T07:46:01Z",
181+
"comments": [
182+
{
183+
"author": "jaimejim",
184+
"authorAssociation": "MEMBER",
185+
"body": "The comment refers to the previous version of the document at the time, which has gone through major changes. \r\nSee diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-core-coap-pubsub-01&url2=draft-ietf-core-coap-pubsub-15&difftype=--html\r\n\r\nThe current architecture has topic configuration parameters to handle topic expirations, maximum number of subscribers, topic history, etc.",
186+
"createdAt": "2025-01-14T07:46:01Z",
187+
"updatedAt": "2025-01-14T07:46:01Z"
188+
}
189+
]
175190
},
176191
{
177192
"number": 8,
@@ -287,7 +302,7 @@
287302
"id": "MDU6SXNzdWUyNzkzNDg0NzA=",
288303
"title": "Notification information to publisher",
289304
"url": "https://github.com/core-wg/coap-pubsub/issues/12",
290-
"state": "OPEN",
305+
"state": "CLOSED",
291306
"author": "lauri-piikivi",
292307
"authorAssociation": "NONE",
293308
"assignees": [],
@@ -296,8 +311,8 @@
296311
],
297312
"body": "Hi,\r\n\r\nMore of a feature wish. If a client subscribes for notifications, I would like to have an option that allows the broker to forward the notification attributes -- the greater than, less than, minimum period etc -- to the publishing client. The publishing client can use those to adjust it's own publishing. ",
298313
"createdAt": "2017-12-05T11:56:32Z",
299-
"updatedAt": "2018-07-18T21:12:12Z",
300-
"closedAt": null,
314+
"updatedAt": "2025-01-14T07:54:16Z",
315+
"closedAt": "2025-01-14T07:54:16Z",
301316
"comments": [
302317
{
303318
"author": "akeranen",
@@ -392,33 +407,39 @@
392407
"id": "MDU6SXNzdWUzMDY1OTI4MDc=",
393408
"title": "How does a client use Conditional Notification parameters (CoRE Dynlink)?",
394409
"url": "https://github.com/core-wg/coap-pubsub/issues/22",
395-
"state": "OPEN",
410+
"state": "CLOSED",
396411
"author": "mjkoster",
397412
"authorAssociation": "CONTRIBUTOR",
398413
"assignees": [],
399-
"labels": [
400-
"for-future-docs"
401-
],
414+
"labels": [],
402415
"body": "Should we support conditional notification on subscriptions? If so, how should we enable it? Can it only support pmin and pmax since we only forward representations?",
403416
"createdAt": "2018-03-19T19:03:44Z",
404-
"updatedAt": "2018-07-18T21:04:08Z",
405-
"closedAt": null,
406-
"comments": []
417+
"updatedAt": "2025-01-14T07:53:42Z",
418+
"closedAt": "2025-01-14T07:53:35Z",
419+
"comments": [
420+
{
421+
"author": "jaimejim",
422+
"authorAssociation": "MEMBER",
423+
"body": "Pmin is now on [draft-ietf-core-conditional-attributes](https://datatracker.ietf.org/doc/draft-ietf-core-conditional-attributes/). Conditional Control Attributes and Conditional Notification Attributes.\r\n\r\nSince the Subscription works as with any CoAP server, it should behave according to the support of the server at the time, getting 3.05 if the observatioj was accepted.\r\n\r\nSo if you use for example `GET /CO2?c.gt=1000` with `Obs: 0` to a topic-data, you should get just the notifications for that resource when lower than 1000.\r\n\r\nhttps://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-15#name-subscribe",
424+
"createdAt": "2025-01-14T07:53:35Z",
425+
"updatedAt": "2025-01-14T07:53:35Z"
426+
}
427+
]
407428
},
408429
{
409430
"number": 24,
410431
"id": "MDU6SXNzdWUzMDY2Mzg4NzQ=",
411432
"title": "What happens when a client tries to create a topic that already exists?",
412433
"url": "https://github.com/core-wg/coap-pubsub/issues/24",
413-
"state": "OPEN",
434+
"state": "CLOSED",
414435
"author": "mjkoster",
415436
"authorAssociation": "CONTRIBUTOR",
416437
"assignees": [],
417438
"labels": [],
418439
"body": "Should we return 4.09 Conflict for the case when the client tries to create a topic that already exists? \r\n\r\n**Indicates that the request could not be processed because of conflict in the request, such as an edit conflict between multiple simultaneous updates.**\r\n\r\nThe draft currently specifies 4.03\r\n\r\n**The request was valid, but the server is refusing action. The user might not have the necessary permissions for a resource, or may need an account of some sort.**\r\n",
419440
"createdAt": "2018-03-19T21:16:20Z",
420-
"updatedAt": "2023-10-02T16:19:05Z",
421-
"closedAt": null,
441+
"updatedAt": "2025-01-14T07:54:46Z",
442+
"closedAt": "2025-01-14T07:54:46Z",
422443
"comments": [
423444
{
424445
"author": "akeranen",
@@ -511,18 +532,20 @@
511532
"id": "MDU6SXNzdWU1MTQ5Mjc5MTI=",
512533
"title": "Why do topics need to be created?",
513534
"url": "https://github.com/core-wg/coap-pubsub/issues/40",
514-
"state": "OPEN",
535+
"state": "CLOSED",
515536
"author": "bdamm",
516537
"authorAssociation": "NONE",
517538
"assignees": [
518539
"cabo",
519540
"marco-tiloca-sics"
520541
],
521-
"labels": [],
542+
"labels": [
543+
"for-future-docs"
544+
],
522545
"body": "The protocol requires that publishers and subscribers create topics before publishing or subscribing to topics. There is an option for a single-shot topic creation with publish, but no option for subscribing to a topic that hasn't been created yet.\r\n\r\nThe result is that if you have a very large tree of potential but not realized topics, subscribers need to actually create a topic before subscribing, regardless of whether the topic will actually be used or not. This converts potential topics into actual topics, which is a major resource burden in the case where there is a large number of potential topics but a small number of actual topics within that potential topic tree.\r\n",
523546
"createdAt": "2019-10-30T19:30:25Z",
524-
"updatedAt": "2023-10-02T14:00:26Z",
525-
"closedAt": null,
547+
"updatedAt": "2025-01-14T07:58:20Z",
548+
"closedAt": "2025-01-14T07:58:20Z",
526549
"comments": [
527550
{
528551
"author": "jaimejim",
@@ -538,7 +561,7 @@
538561
"id": "MDU6SXNzdWU1MTQ5MzA4MTI=",
539562
"title": "Messages are always retained",
540563
"url": "https://github.com/core-wg/coap-pubsub/issues/41",
541-
"state": "OPEN",
564+
"state": "CLOSED",
542565
"author": "bdamm",
543566
"authorAssociation": "NONE",
544567
"assignees": [
@@ -547,8 +570,8 @@
547570
"labels": [],
548571
"body": "The pubsub protocol -09 requires the broker to always provide the most recent message to a subscriber. Why? The message might be very out-dated. Also, this requires the broker to retain the most recent message for every topic. If the topic tree is large and the broker is acting as an exchange point for millions of devices then the requirement that all topics have a cached message puts a big burden on the broker.",
549572
"createdAt": "2019-10-30T19:35:39Z",
550-
"updatedAt": "2023-10-04T13:14:34Z",
551-
"closedAt": null,
573+
"updatedAt": "2025-01-14T07:59:25Z",
574+
"closedAt": "2025-01-14T07:59:25Z",
552575
"comments": [
553576
{
554577
"author": "jaimejim",
@@ -564,7 +587,7 @@
564587
"id": "MDU6SXNzdWU1MTQ5ODAxMTQ=",
565588
"title": "No way to wildcard subscriptions or subscribe to subtrees",
566589
"url": "https://github.com/core-wg/coap-pubsub/issues/42",
567-
"state": "OPEN",
590+
"state": "CLOSED",
568591
"author": "bdamm",
569592
"authorAssociation": "NONE",
570593
"assignees": [
@@ -574,8 +597,8 @@
574597
"labels": [],
575598
"body": "Suppose there is a topic structure such as /${tenant-id}/${device-mac}/${event-id}\r\n\r\nSuppose a subscriber wants to receive all events with a specific ID. There is no way to do that in this protocol.\r\n\r\nSuppose a subscriber wants to receive all events from a specific device-mac. \r\nSuppose a subscriber wants to receive all events from a specific tenant-id.\r\n\r\nHow could this be efficiently realized at all, even with complete freedom to structure the topic tree in any way? With the current protocol I don't see how to do it. Subscribers would need to subscribe to millions of potential topics, even though there may not be millions of actual topics. Even worse, subscribers would need intimate knowledge of all possible topics (all possible IDs and MACs) which may not even be possible.",
576599
"createdAt": "2019-10-30T21:01:44Z",
577-
"updatedAt": "2023-10-04T12:48:16Z",
578-
"closedAt": null,
600+
"updatedAt": "2025-01-14T07:59:58Z",
601+
"closedAt": "2025-01-14T07:59:58Z",
579602
"comments": [
580603
{
581604
"author": "mattaylor",
@@ -630,7 +653,7 @@
630653
"id": "I_kwDOBEc_t86GLS4j",
631654
"title": "Feature requests",
632655
"url": "https://github.com/core-wg/coap-pubsub/issues/56",
633-
"state": "OPEN",
656+
"state": "CLOSED",
634657
"author": "jaimejim",
635658
"authorAssociation": "MEMBER",
636659
"assignees": [],
@@ -639,8 +662,8 @@
639662
],
640663
"body": "As per email discussions:\r\n\r\n\r\nThe features requested were:\r\n\r\n1. CoAP client should subscribe by default without getting a 4.04 in every case.\r\n2. One-shot publication and topic creation.\r\n\r\nMy approach to do this would be:\r\n\r\n1. Making sure that topic-data path can be created/selected by the client. Which is something want enabled anyways.\r\n\r\n2. Populating topic-data with an empty string. This would in principle not be the way the broker works now, so it is either something we enable in a boolean parameter like \"initialize : true\" or we change the behaviour, I would prefer to have it as a parameter choice.\r\n\r\n\r\nThe following CoAP communication would then be possible:\r\n\r\nClient ---> Broker : one-shot topic creation\r\n```sh\r\n\u276f ./client.py -m POST coap://127.0.0.1:5683/ps --payload \"{\\\"topic-name\\\": \\\"Room Temperature Sensor\\\", \\\"resource-type\\\": \\\"core.ps.conf\\\", \\\"media-type\\\": \\\"application/json\\\", \\\"topic-type\\\": \\\"temperature\\\", \\\"expiration-date\\\": \\\"2023-04-05T23:59:59Z\\\", \\\"max-subscribers\\\": 200, \\\"observer-check\\\": 86400, \\\"topic-data\\\": \\\"david-topic\\\", \\\"initialize\\\": true}\"\r\n```\r\n\r\nBroker ---> Client\r\n\r\n```sh\r\nResponse arrived from different address; base URI is coap://127.0.0.1/ps\r\nLocation options indicate new resource: /ps/4309ab\r\n\r\nJSON re-formated and indented\r\n{\r\n \"topic-name\": \"Room Temperature Sensor\",\r\n \"topic-data\": \"david-topic\",\r\n \"resource-type\": \"core.ps.conf\",\r\n \"media-type\": \"application/json\",\r\n \"topic-type\": \"temperature\",\r\n \"expiration-date\": \"2023-04-05T23:59:59Z\",\r\n \"max-subscribers\": 200,\r\n \"observer-check\": 86400,\r\n \"initialize\": true\r\n}\r\n``````\r\nSubscriber ---> Broker : subscription before publication\r\n```sh\r\n\u276f ./client.py -m GET --observe 'coap://127.0.0.1:5683/david-topic'\r\nResponse arrived from different address; base URI is coap://127.0.0.1/david-topic\r\n```\r\nPublisher ---> Broker\r\n```sh\r\n\u276f ./client.py -m PUT coap://127.0.0.1:5683/david-topic --payload \"{\"n\": \"temperature\",\"u\": \"Cel\",\"t\": 1621452122,\"v\": 22}\"\r\nResponse arrived from different address; base URI is coap://127.0.0.1/david-topic\r\n{n: temperature,u: Cel,t: 1621452122,v: 22}\r\n```\r\n\r\nAfter which the client get the following notification\r\n\r\nSubscriber ---> Broker\r\n```sh\r\n\u276f ./client.py -m GET --observe 'coap://127.0.0.1:5683/david-topic'\r\nResponse arrived from different address; base URI is coap://127.0.0.1/david-topic\r\n\r\n---\r\n{n: temperature,u: Cel,t: 1621452122,v: 22}\r\n```",
641664
"createdAt": "2024-04-18T16:27:31Z",
642-
"updatedAt": "2024-10-20T12:05:05Z",
643-
"closedAt": null,
665+
"updatedAt": "2025-01-14T08:00:21Z",
666+
"closedAt": "2025-01-14T08:00:21Z",
644667
"comments": [
645668
{
646669
"author": "jaimejim",
@@ -1840,20 +1863,56 @@
18401863
"id": "PR_kwDOBEc_t86HjsRV",
18411864
"title": "Nits (beyond -15)",
18421865
"url": "https://github.com/core-wg/coap-pubsub/pull/59",
1843-
"state": "OPEN",
1866+
"state": "MERGED",
18441867
"author": "cabo",
18451868
"authorAssociation": "MEMBER",
18461869
"assignees": [],
18471870
"labels": [],
18481871
"body": "",
18491872
"createdAt": "2025-01-13T16:02:35Z",
1850-
"updatedAt": "2025-01-13T16:02:35Z",
1873+
"updatedAt": "2025-01-14T07:37:09Z",
18511874
"baseRepository": "core-wg/coap-pubsub",
18521875
"baseRefName": "main",
18531876
"baseRefOid": "f06a085b4dce2211588084921f4e4723ec8d9887",
18541877
"headRepository": "core-wg/coap-pubsub",
18551878
"headRefName": "nits15",
18561879
"headRefOid": "696f426b706daf033225508c5c7a21a1f42693a4",
1880+
"closedAt": "2025-01-14T07:37:09Z",
1881+
"mergedAt": "2025-01-14T07:37:09Z",
1882+
"mergedBy": "jaimejim",
1883+
"mergeCommit": {
1884+
"oid": "514c2691335de371f63a519d747003432e0d0782"
1885+
},
1886+
"comments": [
1887+
{
1888+
"author": "jaimejim",
1889+
"authorAssociation": "MEMBER",
1890+
"body": "Thanks for the nits Carsten, merging now.",
1891+
"createdAt": "2025-01-14T07:36:09Z",
1892+
"updatedAt": "2025-01-14T07:36:09Z"
1893+
}
1894+
],
1895+
"reviews": []
1896+
},
1897+
{
1898+
"number": 60,
1899+
"id": "PR_kwDOBEc_t86HvOyY",
1900+
"title": "Fix terminology and a broken sentence.",
1901+
"url": "https://github.com/core-wg/coap-pubsub/pull/60",
1902+
"state": "OPEN",
1903+
"author": "cabo",
1904+
"authorAssociation": "MEMBER",
1905+
"assignees": [],
1906+
"labels": [],
1907+
"body": "(Contents still to be fixed.)",
1908+
"createdAt": "2025-01-14T16:50:27Z",
1909+
"updatedAt": "2025-01-14T16:50:27Z",
1910+
"baseRepository": "core-wg/coap-pubsub",
1911+
"baseRefName": "main",
1912+
"baseRefOid": "514c2691335de371f63a519d747003432e0d0782",
1913+
"headRepository": "cabo/coap-pubsub",
1914+
"headRefName": "iana",
1915+
"headRefOid": "aa37e8951419324eeccc58cdc5759ad4443840a4",
18571916
"closedAt": null,
18581917
"mergedAt": null,
18591918
"mergedBy": null,

0 commit comments

Comments
 (0)