Reservation and validity of colon-prefixed header keys

In a recent thread, Roberto Peon suggested that I may represent the END_SEGMENT flag using an :end-segment header, according to the current spec. Is this indeed compliant, or are keys of the form “:xyz” reserved (perhaps just for future expansion) to HTTP?

The draft §8.1.3.1 #HttpRequest seems to restrict usage, but on second thought it appears that “HTTP” is written where “HTTP/1.1” is intended:

> Header field names that start with a colon are only valid in the HTTP/2 context. These are not HTTP header fields. Implementations MUST NOT generate header fields that start with a colon, but they MUST ignore any header field that starts with a colon. In particular, header fields with names starting with a colon MUST NOT be exposed as HTTP header fields.
> 


Is it legal to transmit a user-defined, colon-prefixed header? Would an :end-segment API potentially alias another valid message? I’d prefer to avoid that, it smells like a backdoor for a malicious user to inject segmentation to defeat padding.