Skip to content

Commit 53bd19d

Browse files
hintjenshintjens
committed
Corrected and added states on RFCs
1 parent f96fd9d commit 53bd19d

21 files changed

+36
-39
lines changed

‎spec_1.txt

+1
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,7 @@ SPB is a minimalist format for framing opaque binary blobs. The blobs have no p
22

33
* Name: rfc.zeromq.org/spec:1/SPB
44
* Editor: Martin Sustrik <[email protected]>
5+
* State: deprecated
56

67
++ License
78

‎spec_10.txt

+1
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,7 @@ The Freelance Protocol (FLP) defines brokerless reliable request-reply dialogs a
22

33
* Name: rfc.zeromq.org/spec:10/FLP
44
* Editor: Pieter Hintjens <[email protected]>
5+
* State: stable
56

67
++ License
78

‎spec_11.txt

+1
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,7 @@ This document proposes a Message Transport Layer (MTL), a connection-oriented pr
22

33
* Name: rfc.zeromq.org/spec:11/MTL
44
* Editor: Pieter Hintjens <[email protected]>
5+
* State: draft
56

67
++ License
78

‎spec_12.txt

+1
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,7 @@ The Clustered Hashmap Protocol (CHP) defines a cluster-wide key-value hashmap, a
22

33
* Name: rfc.zeromq.org/spec:12/CHP
44
* Editor: Pieter Hintjens <[email protected]>
5+
* State: stable
56

67
++ License
78

‎spec_13.txt

+1-1
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@ The ZeroMQ Message Transport Protocol (ZMTP) is a transport layer protocol for e
22

33
* Name: rfc.zeromq.org/spec:13/ZMTP
44
* Editor: Pieter Hintjens <[email protected]>
5-
* State: stable
5+
* State: legacy
66

77
++ License
88

‎spec_14.txt

+1
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,7 @@ Worker-Manager Protocol is a generalization of request-reply pattern, allowing m
33
* Name: rfc.zeromq.org/spec:14/WMP
44
* Editor: Brugeman Artur <[email protected]>
55
* Contributors: none yet
6+
* State: raw
67

78
++ License
89

‎spec_15.txt

+1-1
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ The ZeroMQ Message Transport Protocol (ZMTP) is a transport layer protocol for e
33
* Name: rfc.zeromq.org/spec:15/ZMTP
44
* Editor: Pieter Hintjens <[email protected]>
55
* Contributors: Martin Hurton <[email protected]>, Paul Colomiets <[email protected]>
6-
* State: draft
6+
* State: stable
77

88
++ License
99

‎spec_16.txt

+4
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,9 @@
11
The Collective Code Construction Contract (C4) is an evolution of the github.com [http://help.github.com/send-pull-requests/ Fork + Pull Model], aimed at providing an optimal collaboration model for free software projects. C4 is derived from the ZeroMQ contribution policy of early 2012.
22

3+
* Name: rfc.zeromq.org/spec:16/C4
4+
* Editor: Pieter Hintjens <[email protected]>
5+
* State: deprecated
6+
37
++ Language
48

59
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[((bibcite rfc2119))].

‎spec_17.txt

+5-21
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,9 @@
11
The ZeroMQ Device Configuration File (ZDCF) specifies a standard language for configuring 0MQ devices. It provides information to configure a 0MQ context, and a set of 0MQ sockets. This specification aims to make it easier to build, share, and reuse 0MQ devices and build systems for device administration.
22

3-
* Name: rfc.zeromq.org/spec:[nbr]/zdcf
3+
* Name: rfc.zeromq.org/spec:17/zdcf
44
* Editor: Pieter Hintjens <[email protected]>
55
* Contributors: Steffen Mueller <[email protected]>
6-
* State: draft
7-
* Specification version: 1.0001
6+
* State: stable
87

98
++ License
109

@@ -56,7 +55,7 @@ Here is a typical example of a ZDCF file expressed in JSON:
5655

5756
[[code]]
5857
{
59-
"version": 1.0001,
58+
"version": 1.0,
6059
"apps": {
6160
"listener": {
6261
"context": {
@@ -89,7 +88,7 @@ Here is a typical example of a ZDCF file expressed in JSON:
8988
Here is the same property tree expressed in ZPL[((bibcite zpl))]:
9089

9190
[[code]]
92-
version = 1.0001
91+
version = 1.0
9392
apps
9493
listener
9594
context
@@ -113,7 +112,7 @@ And in simple XML:
113112

114113
[[code]]
115114
<zdcf>
116-
<version>0.1001</version>
115+
<version>1.0</version>
117116
<apps>
118117
<context iothreads = "1" verbose = "1" />
119118
<main type = "zmq_queue">
@@ -235,21 +234,6 @@ A software that consumes ZDCF content must adhere to the following rules:
235234

236235
In other words, you are free to implement backwards-compatibility with older versions of the specification, but please don't silently try to accept content that was written against a specification that you did not implement. Your users will thank you for it. If at the time of implementation, the specification version that you had access to is 5.3, then you may accept content written against 5.4 assuming it's a specification change that is backwards compatible. ZDCF 6.0, however, you should reject until you've updated your implementation to handle it.
237236

238-
++ Specification Change History
239-
240-
This section has a list of all significant changes in the ZDCF specification. For details on what changed, you will have to look at the revision history at [http://rfc.zeromq.org].
241-
242-
+++ 0.1
243-
244-
ZDCF 0.1 is the first version that introduced versioning. Its only change is the introduction of versioning.
245-
246-
+++ 1.0
247-
248-
* ZDCF 1.0 adds the notion of "apps" as a top-level, above-context dictionary.
249-
* It also moves devices and sockets out of their respective parent dictionaries (top level dictionary and the device dictionary respectively) into "devices" and "sockets" dictionaries to avoid future name collisions.
250-
* Renames "xrep" and "xreq" socket types to "router" and "dealer".
251-
* Specifying device types becomes optional.
252-
253237
++ References
254238

255239
[[bibliography]]

‎spec_18.txt

+1
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,7 @@ The Majordomo Protocol (MDP) defines a reliable service-oriented request-reply d
33
* Name: rfc.zeromq.org/spec:18/MDP
44
* Editor: Pieter Hintjens <[email protected]>
55
* Contributors: Chuck Remes <[email protected]>, Guido Goldstein <[email protected]>
6+
* State: draft
67

78
++ License
89

‎spec_2.txt

+1-1
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@ SPB is a minimalist format for framing opaque binary blobs. The blobs have no p
22

33
* Name: rfc.zeromq.org/spec:2/SPB
44
* Editor: Pieter Hintjens <[email protected]>
5-
* State: stable
5+
* State: deprecated
66

77
++ License
88

‎spec_21.txt

+1-1
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@ The C Language Style for Scalability (CLASS) defines a consistent style and orga
22

33
* Name: rfc.zeromq.org/spec:21/CLASS
44
* Editor: Pieter Hintjens <[email protected]>
5-
* State: draft
5+
* State: stable
66

77
++ License
88

‎spec_22.txt

+4
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,9 @@
11
The Collective Code Construction Contract (C4) is an evolution of the github.com [http://help.github.com/send-pull-requests/ Fork + Pull Model], aimed at providing an optimal collaboration model for free software projects. This is revision 1 of the C4 specification.
22

3+
* Name: rfc.zeromq.org/spec:22/C4.1
4+
* Editor: Pieter Hintjens <[email protected]>
5+
* State: stable
6+
37
++ Language
48

59
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[((bibcite rfc2119))].

‎spec_23.txt

+6-6
Original file line numberDiff line numberDiff line change
@@ -228,13 +228,13 @@ The value SHALL be 0 to 2^31-1 octets of opaque binary data. Zero-sized values a
228228

229229
The security mechanism SHALL provide a way for peers to exchange metadata in the form of a key-value dictionary. The precise encoding of the metadata depends on the mechanism.
230230

231-
All implementations SHALL provide at least these metadata properties:
231+
These metadata properties are defined:
232232

233-
* "Socket-Type", which specifies the sender's socket type. See the section "The Socket Type Property" below.
233+
* "Socket-Type", which specifies the sender's socket type. See the section "The Socket Type Property" below. The sender SHOULD specify the Socket-Type.
234234

235-
* "Identity", which specifies the sender's socket identity. See the section "The Identity Property" below.
235+
* "Identity", which specifies the sender's socket identity. See the section "The Identity Property" below. The sender MAY specify an Identity.
236236

237-
* "Resource", which specifies the a resource to connect to. See the section "The Resource Property" below.
237+
* "Resource", which specifies the a resource to connect to. See the section "The Resource Property" below. The sender MAY specify a Resource.
238238

239239
The implementation MAY provide other metadata properties such as implementation name, platform name, and so on. For interoperability, metadata names and semantics MAY be defined as RFCs.
240240

@@ -311,9 +311,9 @@ From ZMTP v v2.0[((bibcite zmtp20))] onwards, the protocol contains the version
311311

312312
* Wait for the other peer to send its greeting.
313313

314-
* If this has the version number 1 or 2, the peer is using ZMTP v2.0, so send the ZMTP v2.0 socket type and identity and continue with ZMTP v2.0.
314+
* If the peer version number is 1 or 2, the peer is using ZMTP v2.0, so send the ZMTP v2.0 socket type and identity and continue with ZMTP v2.0.
315315

316-
* If this has the version number 3, the peer is using ZMTP, so send the rest of the greeting and continue with ZMTP v3.0.
316+
* If the peer version number is 3 or higher, the peer is using ZMTP v3.0, so send the rest of the greeting and continue with ZMTP v3.0.
317317

318318
+++ Detecting ZMTP v1.0 Peers
319319

‎spec_3.txt

+1-2
Original file line numberDiff line numberDiff line change
@@ -2,8 +2,7 @@ The ZeroMQ Device Configuration File format (ZDCF) specifies a standard syntax f
22

33
* Name: rfc.zeromq.org/spec:3/zdcf
44
* Editor: Pieter Hintjens <[email protected]>
5-
* Contributors:
6-
* State: draft
5+
* State: deprecated
76

87
++ License
98

‎spec_4.txt

+1-2
Original file line numberDiff line numberDiff line change
@@ -2,8 +2,7 @@ The ZeroMQ Property Language (ZPL) defines a minimalistic framing language for s
22

33
* Name: rfc.zeromq.org/spec:4/zpl
44
* Editor: Pieter Hintjens <[email protected]>
5-
* Contributors:
6-
* State: draft
5+
* State: stable
76

87
++ License
98

‎spec_5.txt

+1-2
Original file line numberDiff line numberDiff line change
@@ -2,8 +2,7 @@ The ZeroMQ Device Configuration File (ZDCF) specifies a standard language for co
22

33
* Name: rfc.zeromq.org/spec:5/zdcf
44
* Editor: Pieter Hintjens <[email protected]>
5-
* Contributors:
6-
* State: draft
5+
* State: deprecated
76

87
++ License
98

‎spec_6.txt

+1
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,7 @@ The Paranoid Pirate Protocol (PPP) defines a reliable request-reply dialog betwe
22

33
* Name: rfc.zeromq.org/spec:6/PPP
44
* Editor: Pieter Hintjens <[email protected]>
5+
* State: stable
56

67
++ License
78

‎spec_7.txt

+1
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,7 @@ The Majordomo Protocol (MDP) defines a reliable service-oriented request-reply d
33
* Name: rfc.zeromq.org/spec:7/MDP
44
* Editor: Pieter Hintjens <[email protected]>
55
* Contributors: Chuck Remes <[email protected]>, Guido Goldstein <[email protected]>
6+
* State: legacy
67

78
++ License
89

‎spec_8.txt

+1-1
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@ The Majordomo Management Interface (MMI) defines a namespace and set of manageme
22

33
* Name: rfc.zeromq.org/spec:8/MMI
44
* Editor: Pieter Hintjens <[email protected]>
5-
* Contributors: none
5+
* State: stable
66

77
++ License
88

‎spec_9.txt

+1-1
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@ The Titanic Service Protocol (SP) defines a set of services, requests, and repli
22

33
* Name: rfc.zeromq.org/spec:9/TSP
44
* Editor: Pieter Hintjens <[email protected]>
5-
* Contributors: none
5+
* State: stable
66

77
++ License
88

0 commit comments

Comments
 (0)