asciidoctor-rfc 0.8.0 → 0.8.2

data/spec/examples/rfc748.md.adoc

@@ -16,7 +16,7 @@ M. Crispin
 
 [align=center]
 ....
-    RANDOMLY-LOSE    256
+RANDOMLY-LOSE    256
 ....
 
 == Command meanings

data/spec/examples/rfc7511.md.adoc

@@ -70,15 +70,14 @@ The Scenic Routing Option (SRO) is placed in the IPv6 Hop-by-Hop
 Options Header that must be examined by every node along a packet's
 delivery path <<RFC2460>>.
 
-The SRO can be included in any IPv6 datagram, but multiple SROs 
-**MUST NOT** be present in the same IPv6 datagram.  The SRO has no alignment
+The SRO can be included in any IPv6 datagram, but multiple SROs [bcp14]#MUST NOT# be present in the same IPv6 datagram.  The SRO has no alignment
 requirement.
 
 If the SRO is set for a packet, every node en route from the packet
 source to the packet's final destination **MUST** preserve the option.
 
 The following Hop-by-Hop Option is proposed according to the
-specification in <<RFC2460,4.2 of>>.
+specification in <<RFC2460,4.2 of: RFC 2460>>.
 
 [#fig-scenic-routing-option-layout]
 .Scenic Routing Option Layout
@@ -114,6 +113,7 @@ HEX         act  chg  rest
 ....
 ====
 
+{blank} +
 The highest-order two bits are set to 00 so any node not
     implementing Scenic Routing will skip over this option and
     continue processing the header.  The third-highest-order bit

data/spec/examples/skel.mkd.adoc

@@ -17,6 +17,7 @@ Carsten Bormann <cabo@tzi.org>
 :email: cabo@tzi.org
 :revdate: 2017-11-03
 :comments: yes
+:rfc2629xslt: true
 
 [abstract]
 insert abstract here

data/spec/examples/stupid-s.mkd.adoc

@@ -22,7 +22,7 @@ Klaus Hartke <hartke@tzi.org>; Carsten Bormann <cabo@tzi.org>
 :country_2: Germany
 :phone_2: +49-421-218-63921
 :fax_2: +49-421-218-7000
-
+:rfc2629xslt: true
 
 [abstract]
 NAT (Network Address Translator) Traversal may require TURN
@@ -663,7 +663,7 @@ an out-of-band channel.
 
 The notification protocol is closely modeled after XMPP's
 In-Band Bytestreams (IBB, see
-http://xmpp.org/extensions/xep-0047.html). Just replace the
+\http://xmpp.org/extensions/xep-0047.html). Just replace the
 namespace and insert the STuPiD Retrieval URI instead of the
 actual Base64 encoded data, see <<figxmpnots>>.
 (Note that the current proposal redundantly sends a sid and a
@@ -678,10 +678,10 @@ then this indicates that a notification has been lost. The
 recipient **MUST NOT** process such an out-of-sequence notification,
 nor any that follow it within the same session; instead, the
 recipient **MUST** consider the session invalid.  (Adapted from
-http://xmpp.org/extensions/xep-0047.html#send)
+\http://xmpp.org/extensions/xep-0047.html#send)
 
 Of course, other methods can be used for setup and teardown, such as Jingle
-(see http://xmpp.org/extensions/xep-0261.html).
+(see \http://xmpp.org/extensions/xep-0261.html).
 
 [#figxmpcri]
 .Creating a Bytestream: Initiator requests session

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: asciidoctor-rfc
 version: !ruby/object:Gem::Version
-  version: 0.8.0
+  version: 0.8.2
 platform: ruby
 authors:
 - Ribose Inc.
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2017-11-10 00:00:00.000000000 Z
+date: 2018-03-26 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: asciidoctor
@@ -42,16 +42,30 @@ dependencies:
   name: nokogiri
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: 1.8.1
+        version: '0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: 1.8.1
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: ruby-jing
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
 - !ruby/object:Gem::Dependency
   name: thread_safe
   requirement: !ruby/object:Gem::Requirement
@@ -228,10 +242,14 @@ extensions: []
 extra_rdoc_files: []
 files:
 - ".gitignore"
+- ".hound.yml"
 - ".oss-guides.rubocop.yml"
 - ".rspec"
+- ".rubocop.ribose.yml"
+- ".rubocop.tb.yml"
 - ".rubocop.yml"
 - ".travis.yml"
+- CODE_OF_CONDUCT.md
 - Gemfile
 - Guardfile
 - LICENSE
@@ -266,9 +284,13 @@ files:
 - lib/asciidoctor/rfc/v3/validate.rb
 - lib/asciidoctor/rfc/v3/validate.rng
 - lib/asciidoctor/rfc/version.rb
+- rfc2629-other.ent
+- rfc2629-xhtml.ent
+- rfc2629.dtd
 - spec/asciidoctor/rfc/v2/appendix_spec.rb
 - spec/asciidoctor/rfc/v2/area_spec.rb
 - spec/asciidoctor/rfc/v2/author_spec.rb
+- spec/asciidoctor/rfc/v2/biblio_spec.rb
 - spec/asciidoctor/rfc/v2/comments_spec.rb
 - spec/asciidoctor/rfc/v2/crossref_spec.rb
 - spec/asciidoctor/rfc/v2/date_spec.rb
@@ -296,6 +318,7 @@ files:
 - spec/asciidoctor/rfc/v3/appendix_spec.rb
 - spec/asciidoctor/rfc/v3/area_spec.rb
 - spec/asciidoctor/rfc/v3/author_spec.rb
+- spec/asciidoctor/rfc/v3/biblio_spec.rb
 - spec/asciidoctor/rfc/v3/comments_spec.rb
 - spec/asciidoctor/rfc/v3/crossref_spec.rb
 - spec/asciidoctor/rfc/v3/date_spec.rb
@@ -322,8 +345,15 @@ files:
 - spec/asciidoctor/rfc/v3/ulist_spec.rb
 - spec/asciidoctor/rfc/v3/workgroup_spec.rb
 - spec/examples/README.adoc
+- spec/examples/biblio-insert-v2.adoc
+- spec/examples/biblio-insert-v3.adoc
 - spec/examples/davies-template-bare-06.adoc
 - spec/examples/davies-template-bare-06.xml.orig
+- spec/examples/draft-iab-html-rfc-bis.xml.adoc
+- spec/examples/draft-iab-html-rfc-bis.xml.orig
+- spec/examples/draft-iab-html-rfc-bis.xml.txt
+- spec/examples/draft-iab-rfc-framework-bis.xml.adoc
+- spec/examples/draft-iab-rfc-framework-bis.xml.orig
 - spec/examples/draft-ietf-core-block-xx.mkd
 - spec/examples/draft-ietf-core-block-xx.mkd.adoc
 - spec/examples/draft-ietf-core-block-xx.xml.orig
@@ -336,6 +366,61 @@ files:
 - spec/examples/hoffmanv3.xml.orig
 - spec/examples/mib-doc-template-xml-06.adoc
 - spec/examples/mib-doc-template-xml-06.xml.orig
+- spec/examples/refs-v2-database.xml
+- spec/examples/refs-v2.adoc
+- spec/examples/refs-v2.xml
+- spec/examples/refs-v2/AsciiDoc.xml
+- spec/examples/refs-v2/AsciiMathML.xml
+- spec/examples/refs-v2/IETF-BibXML.xml
+- spec/examples/refs-v2/MathJax.xml
+- spec/examples/refs-v2/NroffEdit.xml
+- spec/examples/refs-v2/TeX-LaTeX.xml
+- spec/examples/refs-v2/abarth
+- spec/examples/refs-v2/asciidoctor-bibliography.xml
+- spec/examples/refs-v2/asciidoctor-manual.xml
+- spec/examples/refs-v2/asciidoctor-rfc.xml
+- spec/examples/refs-v2/asciidoctor.xml
+- spec/examples/refs-v2/draftr.xml
+- spec/examples/refs-v2/kramdown-rfc2629.xml
+- spec/examples/refs-v2/lyx2rfc.xml
+- spec/examples/refs-v2/mmark.xml
+- spec/examples/refs-v2/pandoc2rfc.xml
+- spec/examples/refs-v2/reference.RFC.2119.xml
+- spec/examples/refs-v2/reference.RFC.5385.xml
+- spec/examples/refs-v2/reference.RFC.7328.xml
+- spec/examples/refs-v2/reference.RFC.7749.xml
+- spec/examples/refs-v2/reference.RFC.7763.xml
+- spec/examples/refs-v2/reference.RFC.7764.xml
+- spec/examples/refs-v2/reference.RFC.7990.xml
+- spec/examples/refs-v2/reference.RFC.7991.xml
+- spec/examples/refs-v3-database.xml
+- spec/examples/refs-v3.adoc
+- spec/examples/refs-v3.xml
+- spec/examples/refs-v3/AsciiDoc.xml
+- spec/examples/refs-v3/AsciiMathML.xml
+- spec/examples/refs-v3/IETF-BibXML.xml
+- spec/examples/refs-v3/MathJax.xml
+- spec/examples/refs-v3/NroffEdit.xml
+- spec/examples/refs-v3/TeX-LaTeX.xml
+- spec/examples/refs-v3/abarth
+- spec/examples/refs-v3/asciidoctor-bibliography.xml
+- spec/examples/refs-v3/asciidoctor-manual.xml
+- spec/examples/refs-v3/asciidoctor-rfc.xml
+- spec/examples/refs-v3/asciidoctor.xml
+- spec/examples/refs-v3/draftr.xml
+- spec/examples/refs-v3/kramdown-rfc2629.xml
+- spec/examples/refs-v3/lyx2rfc.xml
+- spec/examples/refs-v3/mathrefs.xml
+- spec/examples/refs-v3/mmark.xml
+- spec/examples/refs-v3/pandoc2rfc.xml
+- spec/examples/refs-v3/reference.RFC.2119.xml
+- spec/examples/refs-v3/reference.RFC.5385.xml
+- spec/examples/refs-v3/reference.RFC.7328.xml
+- spec/examples/refs-v3/reference.RFC.7749.xml
+- spec/examples/refs-v3/reference.RFC.7763.xml
+- spec/examples/refs-v3/reference.RFC.7764.xml
+- spec/examples/refs-v3/reference.RFC.7990.xml
+- spec/examples/refs-v3/reference.RFC.7991.xml
 - spec/examples/rfc1149.md
 - spec/examples/rfc1149.md.2.xml
 - spec/examples/rfc1149.md.3.xml
@@ -353,7 +438,8 @@ files:
 - spec/examples/rfc5841.md.3.xml
 - spec/examples/rfc5841.md.adoc
 - spec/examples/rfc6350.adoc
-- spec/examples/rfc6350.bib
+- spec/examples/rfc6350.txt.orig
+- spec/examples/rfc6350_refs.xml
 - spec/examples/rfc748.md
 - spec/examples/rfc748.md.2.xml
 - spec/examples/rfc748.md.3.xml
@@ -389,7 +475,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.5.2
+rubygems_version: 2.6.12
 signing_key: 
 specification_version: 4
 summary: asciidoctor-rfc lets you write Internet-Drafts and RFCs in AsciiDoc.

data/spec/examples/rfc6350.bib

@@ -1,763 +0,0 @@
-  @book{CCITT.X520.1988,
-  author="International Telephone and Telegraph Consultative
-           Committee",
-  title="{Information Technology - Open Systems
-           Interconnection - The Directory: Selected Attribute
-           Types}",
-        series="CCITT Recommendation",
-    number="X.520",
-  year=1988,
-  month=nov,
-  }
-
-  @misc{IEEE.754.2008,
-  author="Institute of Electrical and Electronics Engineers",
-  title="{Standard for Binary Floating-Point Arithmetic}",
-        series="IEEE Standard",
-    number="754",
-  year=2008,
-  month=aug,
-  }
-
-
-  @misc{ISO.8601.2000,
-  author="International Organization for Standardization",
-  title="{Data
-           elements and interchange formats - Information interchange
-           - Representation of dates and times}",
-        series="ISO Standard",
-    number="8601",
-  year=2000,
-  month=dec,
-  }
-
-  @misc{ISO.8601.2004,
-  author="International Organization for Standardization",
-  title="{Data
-           elements and interchange formats - Information interchange
-           - Representation of dates and times}",
-        series="ISO Standard",
-    number="8601",
-  year=2004,
-  month=dec,
-  }
-
-
-
-
-@misc{rfc2045,
-  author="N. Freed and N. Borenstein",
-  title="{Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies}",
-  howpublished="RFC 2045 (Draft Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="2045",
-  pages="1--31",
-  year=1996,
-  month=nov,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFCs 2184, 2231, 5335, 6532",
-url="https://www.rfc-editor.org/rfc/rfc2045.txt",
-  key="RFC 2045",
-  abstract={This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]},
-  keywords="MIME, media, types, headers",
-  doi="10.17487/RFC2045",
-  }
-
-@misc{rfc2046,
-  author="N. Freed and N. Borenstein",
-  title="{Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types}",
-  howpublished="RFC 2046 (Draft Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="2046",
-  pages="1--44",
-  year=1996,
-  month=nov,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFCs 2646, 3798, 5147, 6657, 8098",
-url="https://www.rfc-editor.org/rfc/rfc2046.txt",
-  key="RFC 2046",
-  abstract={This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]},
-  keywords="MIME-MEDIA, headers, structure",
-  doi="10.17487/RFC2046",
-  }
-
-@misc{rfc2119,
-  author="S. Bradner",
-  title="{Key words for use in RFCs to Indicate Requirement Levels}",
-  howpublished="RFC 2119 (Best Current Practice)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="2119",
-  pages="1--3",
-  year=1997,
-  month=mar,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFC 8174",
-url="https://www.rfc-editor.org/rfc/rfc2119.txt",
-  key="RFC 2119",
-  abstract={In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
-  keywords="Standards, Track, Documents",
-  doi="10.17487/RFC2119",
-  }
-
-@misc{rfc2739,
-  author="T. Small and D. Hennessy and F. Dawson",
-  title="{Calendar Attributes for vCard and LDAP}",
-  howpublished="RFC 2739 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="2739",
-  pages="1--16",
-  year=2000,
-  month=jan,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFC 6350",
-url="https://www.rfc-editor.org/rfc/rfc2739.txt",
-  key="RFC 2739",
-  abstract={This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. [STANDARDS-TRACK]},
-  keywords="lightweight, directory, access, protocol",
-  doi="10.17487/RFC2739",
-  }
-
-@misc{rfc3629,
-  author="F. Yergeau",
-  title="{UTF-8, a transformation format of ISO 10646}",
-  howpublished="RFC 3629 (Internet Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="3629",
-  pages="1--14",
-  year=2003,
-  month=nov,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-  url="https://www.rfc-editor.org/rfc/rfc3629.txt",
-  key="RFC 3629",
-  abstract={ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.},
-  keywords="UTF-8, UCS, Transformation, Format",
-  doi="10.17487/RFC3629",
-  }
-
-@misc{rfc3966,
-  author="H. Schulzrinne",
-  title="{The tel URI for Telephone Numbers}",
-  howpublished="RFC 3966 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="3966",
-  pages="1--17",
-  year=2004,
-  month=dec,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFC 5341",
-url="https://www.rfc-editor.org/rfc/rfc3966.txt",
-  key="RFC 3966",
-  abstract={This document specifies the URI (Uniform Resource Identifier) scheme ``tel''.  The ``tel'' URI describes resources identified by telephone numbers.  This document obsoletes RFC 2806. [STANDARDS-TRACK]},
-  keywords="uniform, resource, locator, schemes",
-  doi="10.17487/RFC3966",
-  }
-  
-@misc{rfc3986,
-  author="T. Berners-Lee and R. Fielding and L. Masinter",
-  title="{Uniform Resource Identifier (URI): Generic Syntax}",
-  howpublished="RFC 3986 (Internet Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="3986",
-  pages="1--61",
-  year=2005,
-  month=jan,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFCs 6874, 7320",
-url="https://www.rfc-editor.org/rfc/rfc3986.txt",
-  key="RFC 3986",
-  abstract={A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]},
-  keywords="Internet, protocol, uniform, resource, identifier, www, world wide web",
-  doi="10.17487/RFC3986",
-  }
-
-@misc{rfc4122,
-  author="P. Leach and M. Mealling and R. Salz",
-  title="{A Universally Unique IDentifier (UUID) URN Namespace}",
-  howpublished="RFC 4122 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="4122",
-  pages="1--32",
-  year=2005,
-  month=jul,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-  url="https://www.rfc-editor.org/rfc/rfc4122.txt",
-  key="RFC 4122",
-  abstract={This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]},
-  keywords="uniform resource name, guid, globally unique identifier",
-  doi="10.17487/RFC4122",
-  }
-
-@misc{rfc4288,
-  author="N. Freed and J. Klensin",
-  title="{Media Type Specifications and Registration Procedures}",
-  howpublished="RFC 4288 (Best Current Practice)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="4288",
-  pages="1--24",
-  year=2005,
-  month=dec,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Obsoleted by RFC 6838",
-url="https://www.rfc-editor.org/rfc/rfc4288.txt",
-  key="RFC 4288",
-  abstract={This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
-  keywords="mime, multipurpose internet mail extensions, media types",
-  doi="10.17487/RFC4288",
-  }
-
-@misc{rfc5234,
-  author="D. Crocker and P. Overell",
-  title="{Augmented BNF for Syntax Specifications: ABNF}",
-  howpublished="RFC 5234 (Internet Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="5234",
-  pages="1--16",
-  year=2008,
-  month=jan,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFC 7405",
-url="https://www.rfc-editor.org/rfc/rfc5234.txt",
-  key="RFC 5234",
-  abstract={Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF.  It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]},
-  keywords="ABNF, backus-naur form, augmented backus-naur form, rule definitions, encoding, core lexical analyzer",
-  doi="10.17487/RFC5234",
-  }
-
-
-@misc{rfc5322,
-  author="P. Resnick",
-  title="{Internet Message Format}",
-  howpublished="RFC 5322 (Draft Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="5322",
-  pages="1--57",
-  year=2008,
-  month=oct,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFC 6854",
-url="https://www.rfc-editor.org/rfc/rfc5322.txt",
-  key="RFC 5322",
-  abstract={This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of ``electronic mail'' messages.  This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, ``Standard for the Format of ARPA Internet Text Messages'', updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]},
-  keywords="MAIL], e-mail, email, electronic mail, header, address, mailbox, reply, forward, resend, resent, folding, Date, From, Sender, Reply-To, To, Cc, Bcc, Message-ID, In-Reply-To, References, Subject, Comments, Keywords, Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, Resent-Bcc, Resent-Reply-To, Resent-Message-ID, Return-Path, Received",
-  doi="10.17487/RFC5322",
-  }
-
-@misc{rfc5545,
-  author="B. Desruisseaux",
-  title="{Internet Calendaring and Scheduling Core Object Specification (iCalendar)}",
-  howpublished="RFC 5545 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="5545",
-  pages="1--168",
-  year=2009,
-  month=sep,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFCs 5546, 6868, 7529, 7953, 7986",
-url="https://www.rfc-editor.org/rfc/rfc5545.txt",
-  key="RFC 5545",
-  abstract={This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]},
-  keywords="calsify, calsched, calsch, caldav, calendar, calendaring, meeting, event, task, to-do, journal, appointment, agenda, schedule, scheduling, ical, icalendar, itip, imip, text/calendar, ischedule, xCalendar",
-  doi="10.17487/RFC5545",
-  }
-
-@misc{rfc5546,
-  author="C. Daboo",
-  title="{iCalendar Transport-Independent Interoperability Protocol (iTIP)}",
-  howpublished="RFC 5546 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="5546",
-  pages="1--133",
-  year=2009,
-  month=dec,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFC 6638",
-url="https://www.rfc-editor.org/rfc/rfc5546.txt",
-  key="RFC 5546",
-  abstract={This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems. The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]},
-  keywords="calendar, scheduling",
-  doi="10.17487/RFC5546",
-  }
-  
-@misc{rfc5646,
-  author="A. Phillips and M. Davis",
-  title="{Tags for Identifying Languages}",
-  howpublished="RFC 5646 (Best Current Practice)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="5646",
-  pages="1--84",
-  year=2009,
-  month=sep,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-  url="https://www.rfc-editor.org/rfc/rfc5646.txt",
-  key="RFC 5646",
-  abstract={This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object.  It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
-  keywords="language tags, private interchange",
-  doi="10.17487/RFC5646",
-  }
-
-
-@misc{rfc5870,
-  author="A. Mayrhofer and C. Spanring",
-  title="{A Uniform Resource Identifier for Geographic Locations ('geo' URI)}",
-  howpublished="RFC 5870 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="5870",
-  pages="1--23",
-  year=2010,
-  month=jun,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-  url="https://www.rfc-editor.org/rfc/rfc5870.txt",
-  key="RFC 5870",
-  abstract={This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo\' scheme name.  A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way.  The default coordinate reference system used is the World Geodetic System 1984 (WGS-84). [STANDARDS-TRACK]},
-  keywords="geography, geo, uri, scheme",
-  doi="10.17487/RFC5870",
-  }
-  
-@misc{rfc6351,
-  author="S. Perreault",
-  title="{xCard: vCard XML Representation}",
-  howpublished="RFC 6351 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="6351",
-  pages="1--22",
-  year=2011,
-  month=aug,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFC 6868",
-url="https://www.rfc-editor.org/rfc/rfc6351.txt",
-  key="RFC 6351",
-  abstract={This document defines the XML schema of the vCard data format. [STANDARDS-TRACK]},
-  keywords="vCard",
-  doi="10.17487/RFC6351",
-  }
-  
-  @misc{W3C.REC-xml-20081126,
-  author="E. Maler and F. Yergeau and C. Sperberg-McQueen and J. Paoli
-           and T. Bray",
-  title="{Extensible Markup Language (XML) 1.0 (Fifth
-           Edition)}",
-    series="World Wide Web Consortium Recommendation",
-    number="REC-xml-20081126",
-  year=2008,
-  month=nov,
-url="http://www.w3.org/TR/2008/REC-xml-20081126",
-  }
-
-
-  @misc{xfn,
-  author="T. Celik and M. Mullenweg and E. Meyer",
-  title="{XFN 1.1 profile}",
-url="http://gmpg.org/xfn/11",
-  }
-
-
-  @misc{IANA-TZ,
-  author="E. Lear and P. Eggert",
-  title="{IANA Procedures for Maintaining
-           the Timezone Database}",
-  year=2011,
-  month=may,
-  }
-
-  @misc{ISO9070,
-  author="International Organization for Standardization",
-  title="{Information Processing - SGML support facilities -
-           Registration Procedures for Public Text Owner
-           Identifiers}",
-    series="ISO Standard"m
-    number="9070",
-  year=1991,
-  month=apr,
-  }
-
-@misc{rfc1738,
-  author="T. Berners-Lee and L. Masinter and M. McCahill",
-  title="{Uniform Resource Locators (URL)}",
-  howpublished="RFC 1738 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="1738",
-  pages="1--25",
-  year=1994,
-  month=dec,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Obsoleted by RFCs 4248, 4266, updated by RFCs 1808, 2368, 2396, 3986, 6196, 6270, 8089",
-url="https://www.rfc-editor.org/rfc/rfc1738.txt",
-  key="RFC 1738",
-  abstract={This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK]},
-  keywords="URL",
-  doi="10.17487/RFC1738",
-  }
-
-@misc{rfc2397,
-  author="L. Masinter",
-  title="{The ``data'' URL scheme}",
-  howpublished="RFC 2397 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="2397",
-  pages="1--5",
-  year=1998,
-  month=aug,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-  url="https://www.rfc-editor.org/rfc/rfc2397.txt",
-  key="RFC 2397",
-  abstract={A new URL scheme, ``data'', is defined.  It allows inclusion of small data items as ``immediate'' data, as if it had been included externally. [STANDARDS-TRACK]},
-  keywords="DATA-URL, uniform, resource, identifiers, media, type",
-  doi="10.17487/RFC2397",
-  }
-  
-@misc{rfc2425,
-  author="T. Howes and M. Smith and F. Dawson",
-  title="{A MIME Content-Type for Directory Information}",
-  howpublished="RFC 2425 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="2425",
-  pages="1--33",
-  year=1998,
-  month=sep,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Obsoleted by RFC 6350",
-url="https://www.rfc-editor.org/rfc/rfc2425.txt",
-  key="RFC 2425",
-  abstract={This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]},
-  keywords="TXT-DIR, multipurpose, internet, mail, extensions, profiles",
-  doi="10.17487/RFC2425",
-  }
-  
-@misc{rfc2426,
-  author="F. Dawson and T. Howes",
-  title="{vCard MIME Directory Profile}",
-  howpublished="RFC 2426 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="2426",
-  pages="1--42",
-  year=1998,
-  month=sep,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Obsoleted by RFC 6350",
-url="https://www.rfc-editor.org/rfc/rfc2426.txt",
-  key="RFC 2426",
-  abstract={This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. [STANDARDS-TRACK]},
-  keywords="MIME-VCARD, multipurpose, internet, mail, extensions, white-pages, electronic, business, card",
-  doi="10.17487/RFC2426",
-  }
-
-@misc{rfc2616,
-  author="R. Fielding and J. Gettys and J. Mogul and H. Frystyk and L. Masinter and P. Leach and T. Berners-Lee",
-  title="{Hypertext Transfer Protocol -- HTTP/1.1}",
-  howpublished="RFC 2616 (Draft Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="2616",
-  pages="1--176",
-  year=1999,
-  month=jun,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Obsoleted by RFCs 7230, 7231, 7232, 7233, 7234, 7235, updated by RFCs 2817, 5785, 6266, 6585",
-url="https://www.rfc-editor.org/rfc/rfc2616.txt",
-  key="RFC 2616",
-  abstract={HTTP has been in use by the World-Wide Web global information initiative since 1990.  This specification defines the protocol referred to as ``HTTP/1.1'', and is an update to RFC 2068. [STANDARDS-TRACK]},
-  keywords="HTTP, World Wide Web, WWW, hypermedia",
-  doi="10.17487/RFC2616",
-  }
-
-@misc{rfc3282,
-  author="H. Alvestrand",
-  title="{Content Language Headers}",
-  howpublished="RFC 3282 (Draft Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="3282",
-  pages="1--8",
-  year=2002,
-  month=may,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-  url="https://www.rfc-editor.org/rfc/rfc3282.txt",
-  key="RFC 3282",
-  abstract={This document defines a ``Content-language:'' header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an ``Accept-Language:'' header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS-TRACK]},
-  keywords="",
-  doi="10.17487/RFC3282",
-  }
-
-
-@misc{rfc3406,
-  author="L. Daigle and D. van Gulik and R. Iannella and P. Faltstrom",
-  title="{Uniform Resource Names (URN) Namespace Definition Mechanisms}",
-  howpublished="RFC 3406 (Best Current Practice)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="3406",
-  pages="1--22",
-  year=2002,
-  month=oct,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Obsoleted by RFC 8141",
-url="https://www.rfc-editor.org/rfc/rfc3406.txt",
-  key="RFC 3406",
-  abstract={This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) ``namespaces''.  The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405.  The whole rests on the concept of individual ``namespaces'' within the URN structure.  Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.},
-  keywords="namespaces, applications, structure",
-  doi="10.17487/RFC3406",
-  }
-
-@misc{rfc3536,
-  author="P. Hoffman",
-  title="{Terminology Used in Internationalization in the IETF}",
-  howpublished="RFC 3536 (Informational)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="3536",
-  pages="1--30",
-  year=2003,
-  month=may,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Obsoleted by RFC 6365",
-url="https://www.rfc-editor.org/rfc/rfc3536.txt",
-  key="RFC 3536",
-  abstract={This document provides a glossary of terms used in the IETF when discussing internationalization.  The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.  This memo provides information for the Internet community.},
-  keywords="internet engineering task force",
-  doi="10.17487/RFC3536",
-  }
-
-@misc{rfc4770,
-  author="C. Jennings and J. Reschke",
-  title="{vCard Extensions for Instant Messaging (IM)}",
-  howpublished="RFC 4770 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="4770",
-  pages="1--7",
-  year=2007,
-  month=jan,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Obsoleted by RFC 6350",
-url="https://www.rfc-editor.org/rfc/rfc4770.txt",
-  key="RFC 4770",
-  abstract={This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications.  IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books.  It allows a URI that is associated with IM or PP to be specified inside a vCard. [STANDARDS-TRACK]},
-  keywords="impp, instant messaging and presence protocol",
-  doi="10.17487/RFC4770",
-  }
-
-@misc{rfc4880,
-  author="J. Callas and L. Donnerhacke and H. Finney and D. Shaw and R. Thayer",
-  title="{OpenPGP Message Format}",
-  howpublished="RFC 4880 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="4880",
-  pages="1--90",
-  year=2007,
-  month=nov,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Updated by RFC 5581",
-url="https://www.rfc-editor.org/rfc/rfc4880.txt",
-  key="RFC 4880",
-  abstract={This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]},
-  keywords="public-key cryptography, symmetric cryptography",
-  doi="10.17487/RFC4880",
-  }
-
-@misc{rfc5335bis,
-  author="A. Yang and S. Steele",
-  title="{Internationalized Email Headers}",
-  howpublished="RFC 5335 (Experimental)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="5335",
-  pages="1--14",
-  year=2011,
-  month=jul,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-    note="Obsoleted by RFC 6532",
-url="https://www.rfc-editor.org/rfc/rfc5335.txt",
-  key="RFC 5335",
-  abstract={Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses.  It also requires being able to express those addresses and the information based on them in mail header fields.  This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field.  This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification.  This specification Updates section 6.4 of RFC 2045 to conform with the requirements.  This memo defines an Experimental Protocol for the Internet community.},
-  keywords="unicode, utf-8",
-  doi="10.17487/RFC5335",
-  }
-
-@misc{rfc5751,
-  author="B. Ramsdell and S. Turner",
-  title="{Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification}",
-  howpublished="RFC 5751 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="5751",
-  pages="1--45",
-  year=2010,
-  month=jan,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-  url="https://www.rfc-editor.org/rfc/rfc5751.txt",
-  key="RFC 5751",
-  abstract={This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2.  S/MIME provides a consistent way to send and receive secure MIME data.  Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.  Encryption provides data confidentiality.  Compression can be used to reduce data size.  This document obsoletes RFC 3851. [STANDARDS-TRACK]},
-  keywords="secure, multipurpose, internet, mail, extensions, encryption",
-  doi="10.17487/RFC5751",
-  }
-
-@misc{rfc6068,
-  author="M. Duerst and L. Masinter and J. Zawinski",
-  title="{The 'mailto' URI Scheme}",
-  howpublished="RFC 6068 (Proposed Standard)",
-  series="Internet Request for Comments",
-  type="RFC",
-  number="6068",
-  pages="1--17",
-  year=2010,
-  month=oct,
-  issn="2070-1721",
-  publisher="RFC Editor",
-  institution="RFC Editor",
-  organization="RFC Editor",
-  address="Fremont, CA, USA",
-  url="https://www.rfc-editor.org/rfc/rfc6068.txt",
-  key="RFC 6068",
-  abstract={This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail.  It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]},
-  keywords="mailto, email address, URI scheme, IRI",
-  doi="10.17487/RFC6068",
-  }
-
-@misc{TZ-DB,
-  author="A. Olson",
-  title="{Time zone code and data}",
-  url="ftp://elsie.nci.nih.gov/pub/",
-  }
-
-@misc{vCard21,
-  author="Internet Mail Consortium",
-  title="{vCard - The Electronic Business
-           Card Version 2.1}",
-  year=1996,
-  month=sep,
-  }
-
-