Skip to content

Commit 316bed2

Browse files
jaimejimjaimejim
committed
IANA update
1 parent 98ed2e2 commit 316bed2

File tree

1 file changed

+69
-83
lines changed

1 file changed

+69
-83
lines changed

‎draft-ietf-core-coap-pubsub.md

+69-83
Original file line numberDiff line numberDiff line change
@@ -41,6 +41,7 @@ normative:
4141
RFC9176:
4242
RFC7641:
4343
RFC8126:
44+
RFC6838:
4445

4546
informative:
4647
RFC8613:
@@ -955,20 +956,6 @@ The server hosting the topic-data may have to handle a potentially large number
955956

956957
In this situation, if a publisher is sending publications too fast, the server SHOULD return a 4.29 (Too Many Requests) response {{RFC8516}}. As described in {{RFC8516}}, the Max-Age option {{RFC7252}} in this response indicates the number of seconds after which the client may retry. The broker MAY also stop publishing messages from that publisher for the indicated time.
957958

958-
<!--
959-
TODO DISCUSS
960-
* "The broker MAY also stop publishing messages from that publisher for the indicated time."
961-
962-
It's not necessarily the broker, but rather the server hosting the topic-data resource.
963-
964-
What does "stop publishing" practically mean? Suppose that the client sends a new PUT request right away? What error response does the server send?
965-
966-
(note that this opens for the server to keep more state about the publishers, which in turn requires pairwise secure association in order to identify them)
967-
968-
This does not contradict the next, legitimate paragraph on forbidding a client to do so.
969-
970-
-->
971-
972959
When a publisher receives a 4.29 (Too Many Requests) response, it MUST NOT send any new publication requests to the same topic-data resource before the time indicated by the Max-Age option has passed.
973960

974961
# CoAP Pubsub Parameters {#pubsub-parameters}
@@ -977,25 +964,26 @@ This document defines parameters used in the messages exchanged between a client
977964

978965
Note that the media type application/core-pubsub+cbor MUST be used when these parameters are transported in the respective message fields.
979966

980-
~~~~
981-
+------------------+-----------+-----------+------------+
982-
| Name | CBOR Key | CBOR Type | Reference |
983-
|------------------|-----------|-----------|------------|
984-
| topic-name | TBD1 | tstr | [RFC-XXXX] |
985-
| topic-data | TBD2 | tstr | [RFC-XXXX] |
986-
| resource-type | TBD3 | tstr | [RFC-XXXX] |
987-
| topic-content-format | TBD4 | uint | [RFC-XXXX] |
988-
| topic-type | TBD5 | tstr | [RFC-XXXX] |
989-
| expiration-date | TBD6 | tstr | [RFC-XXXX] |
990-
| max-subscribers | TBD7 | uint | [RFC-XXXX] |
991-
| observer-check | TBD8 | uint | [RFC-XXXX] |
992-
| topic-history | TBD9 | uint | [RFC-XXXX] |
993-
| initialize | TBD10 | bool | [RFC-XXXX] |
994-
| conf-filter | TBD11 | array | [RFC-XXXX] |
995-
+------------------+-----------+-----------+------------+
996-
~~~~
967+
~~~~~~~~~~~
968+
+----------------------+----------+-----------+------------+
969+
| Name | CBOR Key | CBOR Type | Reference |
970+
| -------------------- | -------- | --------- | ---------- |
971+
| topic-name | TBD1 | tstr | [RFC-XXXX] |
972+
| topic-data | TBD2 | tstr | [RFC-XXXX] |
973+
| resource-type | TBD3 | tstr | [RFC-XXXX] |
974+
| topic-content-format | TBD4 | uint | [RFC-XXXX] |
975+
| topic-type | TBD5 | tstr | [RFC-XXXX] |
976+
| expiration-date | TBD6 | tstr | [RFC-XXXX] |
977+
| max-subscribers | TBD7 | uint | [RFC-XXXX] |
978+
| observer-check | TBD8 | uint | [RFC-XXXX] |
979+
| topic-history | TBD9 | uint | [RFC-XXXX] |
980+
| initialize | TBD10 | bool | [RFC-XXXX] |
981+
| conf-filter | TBD11 | array | [RFC-XXXX] |
982+
+----------------------+----------+-----------+------------+
983+
~~~~~~~~~~~
997984
{: #fig-CoAP-Pubsub-Parameters title="CoAP Pubsub Parameters" artwork-align="center"}
998985

986+
999987
# Security Considerations {#seccons}
1000988

1001989
The architecture presented in this document inherits the security considerations from CoAP {{RFC7252}} and Observe {{RFC7641}}, as well as from Web Linking {{RFC8288}}, Link-Format {{RFC6690}}, and the CoRE Resource Directory {{RFC9176}}.
@@ -1012,97 +1000,82 @@ In particular, the application profile above relies on the ACE framework for Aut
10121000

10131001
# IANA Considerations {#iana}
10141002

1003+
<!-- We register:
1004+
media type: application/core-pubsub+cbor
1005+
content format/type: application/core-pubsub+cbor
1006+
subregistry for the topic config
1007+
-->
1008+
10151009
This document has the following actions for IANA.
10161010

10171011
Note to RFC Editor: Please replace all occurrences of "{{&SELF}}" with the RFC number of this specification and delete this paragraph.
10181012

1019-
## Media Type
1013+
## Media Type Registrations {#media-type}
1014+
1015+
This specification registers the 'application/core-pubsub+cbor' media type for messages of the protocols defined in this document and carrying parameters encoded in CBOR. This registration follows the procedures specified in {{RFC6838}}.
10201016

1021-
IANA is requested to add the following Media-Type to the "Media Types"
1022-
registry {{!IANA.media-types}}.
1017+
Type name: application
10231018

1024-
| Name | Template | Reference |
1025-
| core-pubsub+cbor | application/core-pubsub+cbor | RFC XXXX, {{media-type}} |
1026-
{: #new-media-type align="left" title="New Media Type application/core-pubsub+cbor"}
1019+
Subtype name: core-pubsub+cbor
10271020

1028-
{:compact}
1029-
Type name:
1030-
: application
1021+
Required parameters: N/A
10311022

1032-
Subtype name:
1033-
: core-pubsub+cbor
1023+
Optional parameters: N/A
10341024

1035-
Required parameters:
1036-
: N/A
1025+
Encoding considerations: Must be encoded as a CBOR map containing the parameters defined in {{&SELF}}.
10371026

1038-
Optional parameters:
1039-
: N/A
1027+
Security considerations: See {{sec-cons}} of {{&SELF}}.
10401028

1041-
Encoding considerations:
1042-
: binary (CBOR data item)
1029+
Interoperability considerations: none
10431030

1044-
Security considerations:
1045-
: {{seccons}} of RFC XXXX
1031+
Published specification: {{&SELF}}
10461032

1047-
Interoperability considerations:
1048-
: none
1033+
Applications that use this media type: This type is used by clients that create, retrieve, and update topic-configurations at servers acting as a broker.
10491034

1050-
Published specification:
1051-
: {{media-type}} of RFC XXXX
1035+
Fragment identifier considerations: N/A
10521036

1053-
Applications that use this media type:
1054-
: This type is used by clients that create, retrieve, and update topic-configurations at servers acting as a pub-sub broker.
1037+
Additional information: N/A
10551038

1056-
Fragment identifier considerations:
1057-
: N/A
1039+
Person & email address to contact for further information: CoRE WG mailing list (core@ietf.org),
1040+
or IETF Web and Internet Transport (WIT) Area (wit@ietf.org)
10581041

1059-
Person & email address to contact for further information:
1060-
: CoRE WG mailing list (core@ietf.org),
1061-
or IETF Applications and Real-Time Area (art@ietf.org)
1042+
Intended usage: COMMON
10621043

1063-
Intended usage:
1064-
: COMMON
1044+
Restrictions on usage: none
10651045

1066-
Restrictions on usage:
1067-
: none
1046+
Author/Change controller: IETF
10681047

1069-
Author/Change controller:
1070-
: IETF
1048+
Provisional registration: no
10711049

1072-
Provisional registration:
1073-
: no
1050+
## CoAP Content-Formats {#content-type}
10741051

1075-
## Content-Format
1052+
IANA is asked to register the following entry to the "CoAP Content-Formats" registry within the "CoRE Parameters" registry group.
10761053

1077-
IANA has added the following Content-Formats to the
1078-
{{content-formats ("CoAP Content-Formats")<IANA.core-parameters}}
1079-
sub-registry, within the "Constrained RESTful Environments (CoRE)
1080-
Parameters" Registry {{!IANA.core-parameters}}, as follows:
1054+
Content Type: application/core-pubsub+cbor
10811055

1082-
| Content Type | Content Coding | ID | Reference |
1083-
| application/core-pubsub+cbor | - | TBD9 | RFC XXXX |
1084-
{: align="left" title="New Content-Format"}
1056+
Content Coding: -
10851057

1086-
TBD9 is to be assigned from the space 256..999.
1058+
ID: TBD
1059+
1060+
Reference: {{&SELF}}
10871061

10881062
## CoAP Pubsub Parameters {#iana-coap-pubsub-parameters}
10891063

1090-
IANA is asked to register the following entries in the subregistry of the "Constrained RESTful Environments (CoRE) Parameters" registry group.
1064+
This specification establishes the "CoAP Pubsub topic-configuration Parameters" IANA subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.
10911065

1092-
This specification establishes the "Pubsub Topic Configuration Parameters" IANA registry within the "Constrained RESTful Environments (CoRE)
1093-
Parameters" registry group.
1066+
The registry has been created to use the "Expert Review" registration procedure {{RFC8126}}. Expert review guidelines are provided in {{review}}. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.
10941067

10951068
The columns of this registry are:
10961069

10971070
* Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding.
10981071

1099-
* CBOR Key: This is the value used as CBOR key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies {{RFC8126}}. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".
1072+
* CBOR Key: This is the value used as the CBOR key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies {{RFC8126}}. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".
11001073

11011074
* CBOR Type: This contains the CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item.
11021075

11031076
* Reference: This contains a pointer to the public specification for the item.
11041077

1105-
The registry is initially populated with the entries in {{fig-CoAP-Pubsub-Parameters}} of {{pubsub-parameters}}.
1078+
This registry has been initially populated with the values in {{fig-CoAP-Pubsub-Parameters}}.
11061079

11071080
## Resource Types {#iana-rt}
11081081

@@ -1126,6 +1099,19 @@ Description: Topic-data resource of a broker
11261099
Reference: [RFC-XXXX]
11271100
~~~
11281101

1102+
## Expert Review Instructions {#review}
1103+
1104+
The IANA Registries established in this document are defined as expert review.
1105+
This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude.
1106+
1107+
Expert reviewers should take into consideration the following points:
1108+
1109+
* Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments, code points in other ranges should not be assigned for testing.
1110+
1111+
* Specifications are required for the standards track range of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
1112+
1113+
* Experts should take into account the expected usage of fields when approving point assignments. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.
1114+
11291115
--- back
11301116

11311117
# Document Updates # {#sec-document-updates}

0 commit comments

Comments
 (0)