[rfc-i] How to indent artwork with surrounding block

Julian Reschke julian.reschke at gmx.de
Wed Feb 17 08:02:22 PST 2016

On 2016-02-17 16:24, Paul Hoffman wrote:
> On 17 Feb 2016, at 7:01, HANSEN, TONY L wrote:
>> Yes, <CODE BEGINS> and <CODE ENDS> is just one way in which code
>> components can be identified. It's definitely not a requirement.
> Exactly. I misunderstood the need for those, and thus supported the
> <example> idea earlier, but now I am quite sure we don't need it.

I'm not completely sure how

a) the need to identify code that should be surrounded with "<CODE 
BEGINS>" / "<CODE ENDS>", and

b) the desire to distinguish between artwork (like diagrams), source 
code (such as ABNF), and examples (such as protocol messages)

relate to each other. Could you elaborate?

>> Are there cases where one can have source code within the XML to which
>> the IPR statement applies, as well as code within the XML to which the
>> IPR statement does NOT apply? Does
>> <http://trustee.ietf.org/license-info/IETF-TLP-5.htm> imply though
>> that we should have an attribute within the XML that indicates whether
>> the IPR code statement applies or not? Or is this a rat hole?
> The Trust can tell us all that in the future. Adding an attribute to
> <sourcecode> based on actual requirements, not guesses, is easy.

IMHO: the trust grants certain extra rights for the use of "code 
components". To qualify as such, the specific text either needs to be in 
a white-listed language (and that white-list is being revised from time 
to time), or clearly marked as such. *One* way to do so is to insert the 
"<CODE BEGINS>" / "<CODE ENDS>" brackets.

To me this indicates that it would be good to have a flag on 
<sourcecode> which triggers exactly that; it would allow the display of 
the brackets in formats other than TXT to be less intrusive.


Best regards, Julian

More information about the rfc-interest mailing list