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
"body": "There are (probably) 3 different styles used for topic property names. E.g.:\n\n* 'topic-data'\n* \"topic-data\"\n* topic-data\n\nThis issue is to remind to make this consistent. Using some form of quotes is preferred to avoid confusion with regular words.\nDouble quotes is used most at this moment.\n\nCan be done before or after WGLC start!\nFYI @jaimejim ",
688
+
"createdAt": "2025-02-27T08:06:01Z",
689
+
"updatedAt": "2025-02-27T13:16:16Z",
690
+
"closedAt": "2025-02-27T12:54:52Z",
691
+
"comments": [
692
+
{
693
+
"author": "jaimejim",
694
+
"authorAssociation": "MEMBER",
695
+
"body": "We choose double quotes.",
696
+
"createdAt": "2025-02-27T12:39:50Z",
697
+
"updatedAt": "2025-02-27T12:39:50Z"
698
+
},
699
+
{
700
+
"author": "EskoDijk",
701
+
"authorAssociation": "CONTRIBUTOR",
702
+
"body": "@jaimejim The commit has a (some?) errors. The term \"topic-data resource\" is a valid term and replacing this with `\"topic-data\" resource` isn't correct.",
703
+
"createdAt": "2025-02-27T13:16:16Z",
704
+
"updatedAt": "2025-02-27T13:16:16Z"
705
+
}
706
+
]
707
+
},
708
+
{
709
+
"number": 65,
710
+
"id": "I_kwDOBEc_t86r48nn",
711
+
"title": "Section 2.3.3 \"Topic Discovery\" uses well-known/core, but 2.3.2 says this is not mandatory to support",
"body": "This looks inconsistent:\n\n* 2.3.2 says topics don't need to go under \"well-known/core\"\n* 2.3.3 says you use \"well-known/core\" to discovery topics \n\nThis looks inconsistent. If topics are not under \"well-known/core\" an implementation that uses this only to discover topics will fail. (Or do I miss something?)\n\nMaybe to resolve during WGLC ...?\nFYI @jaimejim ",
719
+
"createdAt": "2025-02-27T08:44:58Z",
720
+
"updatedAt": "2025-02-28T21:19:25Z",
721
+
"closedAt": "2025-02-28T21:19:24Z",
722
+
"comments": [
723
+
{
724
+
"author": "jaimejim",
725
+
"authorAssociation": "MEMBER",
726
+
"body": "I thought of not making it mandatory for every broker to offer\"well-known/core\" topic discovery, you may have other mechanisms for discovery. \n\nSo a broker **SHOULD** offer a topic discovery entry point to enable clients to find topics of interest and if you choose to do topic discovery with \"well-known/core\" to discover topics, then 2.3.3 explains how.\n\nI could add a **MAY** in 2.3.3 to make it more clear. That is unless the group wants it to be mandatory to store topics under \"well-known/core\", in which case we should change **SHOULD** with **MUST**. ",
727
+
"createdAt": "2025-02-27T11:51:12Z",
728
+
"updatedAt": "2025-02-27T12:38:39Z"
729
+
},
730
+
{
731
+
"author": "EskoDijk",
732
+
"authorAssociation": "CONTRIBUTOR",
733
+
"body": "Agree, we can make it optional (MAY) to offer topic resources via well-known/core. One example where the server does not offer in this way is when the topics are only available to certain authenticated clients. (I.e. via the 2.4.1 method.)\n\nThen 2.3.3 should be clear that this approach might fail and say it's much better to use the 2.4.1 method! (to achieve the same)\nThe 2.4.1 is a MUST for a server to implement.\n\nSome text is needed to make this clear.",
734
+
"createdAt": "2025-02-27T13:13:39Z",
735
+
"updatedAt": "2025-02-27T13:13:39Z"
736
+
},
737
+
{
738
+
"author": "jaimejim",
739
+
"authorAssociation": "MEMBER",
740
+
"body": "Closing based on PR",
741
+
"createdAt": "2025-02-28T21:19:24Z",
742
+
"updatedAt": "2025-02-28T21:19:24Z"
743
+
}
744
+
]
745
+
},
746
+
{
747
+
"number": 66,
748
+
"id": "I_kwDOBEc_t86r5DCw",
749
+
"title": "Use of relative URIs in the \"topic-data\" URI field",
"body": "All examples use a relative URI in the \"topic-data\" topic property, e.g.:\n\n```\n/ topic-data / 1: \"ps/data/1bd0d6d\",\n```\n\nIt's not fully clear here what the base URI (RFC 3986) is against which the relative reference is resolved.\nSection 1.1 says the base URI is the URI of the topic collection resource. In that case, given that /ps is the topic collection resource used as example in the document, the topic-data resource should be rather:\n\n```\n/ topic-data / 1: \"data/1bd0d6d\",\n```\n\nif a relative URI is used.\n\nOr, if absolute URI is used it would be:\n\n```\n/ topic-data / 1: \"/ps/data/1bd0d6d\",\n```\n\nFYI @jaimejim \n",
757
+
"createdAt": "2025-02-27T08:56:53Z",
758
+
"updatedAt": "2025-02-28T21:19:14Z",
759
+
"closedAt": "2025-02-28T21:19:13Z",
760
+
"comments": [
761
+
{
762
+
"author": "jaimejim",
763
+
"authorAssociation": "MEMBER",
764
+
"body": "\nActually my example was terrible. Relative path with `ps/data...` is plain wrong, it would resolve to `/ps/ps/data/...` \n\nIs it even allowed to use absolute paths if we indicate a base URI? ",
765
+
"createdAt": "2025-02-27T12:36:36Z",
766
+
"updatedAt": "2025-02-27T12:36:36Z"
767
+
},
768
+
{
769
+
"author": "EskoDijk",
770
+
"authorAssociation": "CONTRIBUTOR",
771
+
"body": "Both absolute or relative URIs could be used (since we don't forbid the one or the other). Relative seems to have the benefit of compactness, but it does need a clearly defined base URI to resolve against. So the base URI can always be defined and is only used to resolve the relative URI reference.\n\nAlthough Section 1.1 defines a base URI, it's a bit hidden in the terminology section and also it says it's only the base URI for all topic resources. This is not the same as a base URI for all **topic-data** resources.",
772
+
"createdAt": "2025-02-27T22:03:52Z",
773
+
"updatedAt": "2025-02-27T22:03:52Z"
774
+
},
775
+
{
776
+
"author": "jaimejim",
777
+
"authorAssociation": "MEMBER",
778
+
"body": "Let's use absolute URI to accommodate the general case where the topic-data resource might not be hosted at the broker.",
779
+
"createdAt": "2025-02-28T20:59:36Z",
780
+
"updatedAt": "2025-02-28T20:59:36Z"
781
+
},
782
+
{
783
+
"author": "jaimejim",
784
+
"authorAssociation": "MEMBER",
785
+
"body": "Closing based on PR",
786
+
"createdAt": "2025-02-28T21:19:13Z",
787
+
"updatedAt": "2025-02-28T21:19:13Z"
788
+
}
789
+
]
790
+
},
791
+
{
792
+
"number": 67,
793
+
"id": "I_kwDOBEc_t86r5Nif",
794
+
"title": "CBOR diag notation is sometimes using final comma at last item in map",
"body": "For example this one:\n\n```\n~~~~\n Request:\n\n Header: FETCH (Code=0.05)\n Uri-Path: \"ps\"\n Uri-Path: \"h9392\"\n Content-Format: TBD606 (application/core-pubsub+cbor)\n Payload (in CBOR diagnostic notation):\n {\n / conf-filter / 10: [\"topic-data\", \"media-type\"]\n }\n\n Response:\n\n Header: Content (Code=2.05)\n Content-Format: TBD606 (application/core-pubsub+cbor)\n Payload (in CBOR diagnostic notation):\n {\n / topic-data / 1: \"ps/data/1bd0d6d\",\n / topic-content-format / 3: 112,\n }\n~~~~\n```\n\nShould we make that comma usage consistent?",
802
+
"createdAt": "2025-02-27T09:13:57Z",
803
+
"updatedAt": "2025-02-27T11:41:03Z",
804
+
"closedAt": "2025-02-27T11:36:57Z",
805
+
"comments": [
806
+
{
807
+
"author": "cabo",
808
+
"authorAssociation": "MEMBER",
809
+
"body": "Yes, you should check the examples with an old tool like those in cbor-diag.\n\nThe new syntax, which allows these commas, is currently stuck in the CBOR WG because of an unrelated issue around implementation preferences.",
810
+
"createdAt": "2025-02-27T10:18:17Z",
811
+
"updatedAt": "2025-02-27T10:18:17Z"
812
+
},
813
+
{
814
+
"author": "jaimejim",
815
+
"authorAssociation": "MEMBER",
816
+
"body": "I will remove the last comma to fix the example.",
817
+
"createdAt": "2025-02-27T11:32:08Z",
818
+
"updatedAt": "2025-02-27T11:32:08Z"
819
+
},
820
+
{
821
+
"author": "cabo",
822
+
"authorAssociation": "MEMBER",
823
+
"body": "There really should be a small test suite to check the examples.\nE.g., kramdown-rfc-extract-sourcecode \u2794 a little shim that removes everything before the payload \u2794 diag2diag.rb\n",
824
+
"createdAt": "2025-02-27T11:41:01Z",
825
+
"updatedAt": "2025-02-27T11:41:01Z"
826
+
}
827
+
]
676
828
}
677
829
],
678
830
"pulls": [
@@ -2013,6 +2165,78 @@
2013
2165
},
2014
2166
"comments": [],
2015
2167
"reviews": []
2168
+
},
2169
+
{
2170
+
"number": 68,
2171
+
"id": "PR_kwDOBEc_t86MxA4o",
2172
+
"title": "Explain better optimization of attributes; broker MAY include any attribute",
"body": "Explain better the optimization of attributes and that broker MAY include any attributes, per CoRE interim discussion of 2025-02-26.\r\n\r\nAlso some terminology fixes (nits).",
"body": "Doing this change distinguishes better between the concepts\r\n\r\n* topic-data resource , as defined in Terminology\r\n* \"topic-data\" topic property, one of the fields of configuration which is inside the topic resource.\r\n\r\nThe latter is also sometimes abbreviated as \"topic-data\" path or \"topic-data\" URI to point to the value of this property while keeping the sentences short. (This was already used.)",
0 commit comments