This is from RFC 3749 (Transport Layer Security Protocol Compression Methods):
Compression Methods
TLS [2] includes the following compression method structure in sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6:
enum { null(0), (255) } CompressionMethod;
I'm not really familiar with C, but I know enough to mark it as resemblant of C enum. What I can't understand though, are the null(0) and (255) parts. I can't seem to find anywhere what parentheses and null would mean in this context.
(I seems hard to even come up with a (Google?) search pattern that would consist of something less ubiquitous than "rfc", "null", "c", "parentheses" and would lead me to other places than questions on "null function pointer" or the most fundamental basics.)
So what do these notations mean syntactically?
Why is 255 in parentheses?
Why null looks like a function call?
Is this even supposed to be C? Or is it a common notation shared across RFCs? And if it's C, is it specific to enum?
How is this different from enum { 0, 255 } CompressionMethod; or enum { NULL, 255 } CompressionMethod;?
You may be overreasoning a bit here :)
You should have quoted the lines that follow your quote:
which allows for later specification of up to 256 different
compression methods.
That already explains what the line means. Now, if you follow the [2] to the list of references, you'll notice it refers to RFC 2246. And that document contains the following paragraph:
4. Presentation language
This document deals with the formatting of data in an external
representation. The following very basic and somewhat casually
defined presentation syntax will be used. The syntax draws from
several sources in its structure. Although it resembles the
programming language "C" in its syntax and XDR [XDR] in both its
syntax and intent, it would be risky to draw too many parallels. The
purpose of this presentation language is to document TLS only, not to
have general application beyond that particular goal.
So, the authors of that RFC seem to have concocted a simple syntax from familiar elements to simplify the representation of the subject of the RFC, namely TLS. For enumerateds, they specify the language used in 4.5:
4.5. Enumerateds
An additional sparse data type is available called enum. A field of
type enum can only assume the values declared in the definition.
Each definition is a different type. Only enumerateds of the same
type may be assigned or compared. Every element of an enumerated must
be assigned a value, as demonstrated in the following example. Since
the elements of the enumerated are not ordered, they can be assigned
any unique value, in any order.
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
Enumerateds occupy as much space in the byte stream as would its
maximal defined ordinal value. The following definition would cause
one byte to be used to carry fields of type Color.
enum { red(3), blue(5), white(7) } Color;
One may optionally specify a value without its associated tag to
force the width definition without defining a superfluous element.
In the following example, Taste will consume two bytes in the data
stream but can only assume the values 1, 2 or 4.
enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
The names of the elements of an enumeration are scoped within the
defined type. In the first example, a fully qualified reference to
the second element of the enumeration would be Color.blue. Such
qualification is not required if the target of the assignment is well
specified.
Color color = Color.blue; /* overspecified, legal */
Color color = blue; /* correct, type implicit */
For enumerateds that are never converted to external representation,
the numerical information may be omitted.
enum { low, medium, high } Amount;