[rfc-i] v3imp #9 Is "cbor" a type?

Sean Leonard dev+ietf at seantek.com
Fri Jan 23 01:09:28 PST 2015

Minor Improvement Need
#9 Is "cbor" a type?

This improvement questions the classification system of Section 2.49.5, 
the <sourcecode> @type.

The type "cbor" probably refers to CBOR diagnostic notation. CBOR is a 
binary format, so <sourcecode> that is literally CBOR would have to show 
or represent actual octets. Compare "asn.1" vs. "ber/cer/der" (or "x.690").

As with things like this, the problem is that now there is an informal 
registry that is supposed to be maintained by the RFC Editor. I am not 
in favor of a formal IANA registry. I am also not in favor of delegating 
the classification to media types, as many perfectly legitimate 
<sourcecode> types do not have media types (c++, c, perl, pseudocode, 
python, etc.). However we should recognize that "The RFC Editor will 
maintain a complete list of the preferred values on its web site, and 
that list is expected to be updated over time." is basically a registry 
by another name.

I suggest that @type be de-formalized, by permitting file extensions in 
widespread use. Thus "javascript" -> "js", "perl" -> "pl", "python" -> 
"py". One could add filenames to <sourcecode> elements (which was the 
original draft premise of Improvement #5); however, I think the point of 
<sourcecode> is for exemplary purposes with fragments (see Improvement 
#8). Therefore if file extensions are used, perhaps type=".js" (i.e., 
prefix with a period) makes that really clear. I believe this has the 
right level of (in)formality, and doesn't get into esoteric things like 
"are we referring to Vernacular JavaScript 1.0 from the '90s or Strict 
ECMAScript 5".

Of course the RFC Editor can still maintain lists of commonly used 
things, as well as things that are not file extensions per-se but still 
have identification value ("pseudocode").

Oh yeah, "bash" -> ".sh". I found 


More information about the rfc-interest mailing list