]> Passive DNS - qos CIRCL
6, rue de l'Etang Contern L-5326 LU (+352) 247 88444 alexandre.dulaunoy@circl.lu http://www.circl.lu/
CERT.at
Karlsplatz 1/2/9 Wien A-1010 AT +43 1 5056416 78 kaplan@cert.at http://www.cert.at/
General Internet Engineering Task Force template This document describes the output format used between Passive DNS query interface. The output format description includes also a common meaning per Passive DNS system.
Passive DNS is a technique described by Florian Weimer in 2005 in Passive DNS replication, F Weimer - 17th Annual FIRST Conference on Computer Security.
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.
List styles: 'empty', 'symbols', 'letters', 'numbers', 'hanging', 'format'. First bullet Second bullet You can write text here as well.
Figures should not exceed 69 characters wide to allow for the indent of sections.
Preamble text - can be omitted or empty. Cross-references allowed in pre- and postamble. .
The CDATA means you don't need to escape meta-characters (especially < (&lt;) and & (&amp;)) but is not essential. Figures may also have a title attribute but it won't be displayed unless there is also an anchor. White space, both horizontal and vertical, is significant in figures even if you don't use CDATA.
By default 3 levels of nesting show in table of contents but that can be adjusted with the value of the "tocdepth" processing instruction.
.. are very similar to figures: Tables use ttcol to define column headers and widths. Every cell then has a "c" element for its content. ttcol #1 ttcol #2 c #1 c #2 c #3 c #4 c #5 c #6 which is a very simple example.
Lists with 'hanging labels': the list item is indented the amount of the hangIndent: With a label shorter than the hangIndent. With a label longer than the hangIndent. Forces the new item to start on a new line. Simulating more than one paragraph in a list item using <vspace>: First, a short item. Second, a longer list item. And something that looks like a separate pararaph.. Simple indented paragraph using the "empty" style: The quick, brown fox jumped over the lazy dog and lived to fool many another hunter in the great wood in the west.
Numbering items continuously although they are in separate <list> elements, maybe in separate sections using the "format" style and a "counter" variable. First list: #1 #2 #3 Specify the indent explicitly so that all the items line up nicely. Second list: #4 #5 #6
List continues here. Third list: #7 #8 #9 #10 The end of the list.
The <artwork> element has a number of extra attributes that can be used to substitute a more aesthetically pleasing rendition into HTML output while continuing to use the ASCII art version in the text and nroff outputs (see the xml2rfc README for details). It also has a "type" attribute. This is currently ignored except in the case 'type="abnf"'. In this case the "artwork" is expected to contain a piece of valid Augmented Backus-Naur Format (ABNF) grammar. This will be syntax checked by xml2rfc and any errors will cause a fatal error if the "strict" processing instruction is set to "yes". The ABNF will also be colorized in HTML output to highlight the syntactic components. Checking of additional "types" may be provided in future versions of xml2rfc. void main(int argc, char *argv[]) { int i; printf("program arguments are:\n"); for (i = 0; i < argc; i++) { printf("%d: \"%s\"\n", i, argv[i]); } exit(0); } /* main */ /* end of file */ ]]>
This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. This document is part of a plan to make xml2rfc indispensable .
This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see the update of RFC 2434 for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.
All drafts are required to have a security considerations section. See RFC 3552 for a guide.
&RFC2119; Minimal Reference &RFC2629; &RFC3552; &I-D.narten-iana-considerations-rfc2434bis; Ultimate Plan for Taking Over the World Mad Dominators, Inc.
This becomes an Appendix.