Comments (32)
opoudjis
commented on July 30, 2024
Can't replicate: I just compiled rfc-asciidoc-rfc latest successfully with latest "bundle install".
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
... Recompiled gem, and rerun make. Still built successfully. Could you show me error message?
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
Try running “bundle update” in the document and make again? My error is about malformed xml, the header “<xml ...” became “xml ...”.
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
Error message after bundle update:
xml2rfc --text draft-ribose-asciirfc.xml draft-ribose-asciirfc.txt
Parsing file draft-ribose-asciirfc.xml
WARNING: Parsing Error: Document is empty, line 2, column 1 (<string>, line 2)
ERROR: Unable to parse the XML document: draft-ribose-asciirfc.xml
<string>: Line 2: Document is empty
<string>: Line 2: Start tag expected, '<' not found
make: *** [draft-ribose-asciirfc.txt] Error 1
cat draft-ribose-asciirfc.xml
?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
...
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
... And the XML document stops there? With an incomplete entity definition bracket?
That... is not good. And it's not the behaviour I'm seeing. I just debugged an error that was coming up if it was issuing warnings that would have crashed it, but that does not explain this. Just in case (a) please recompile latest asciidoc-rfc gem, and (b) just run bundle exec asciidoctor -r ./lib/glob-include-processor.rb -r asciidoctor-rfc -b rfc2 -a flush-biblio=true --trace on the file, and tell me what happens.
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
@opoudjis I've updated the gem and it now works! You must have done some magic ;-)
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
The document works but this issue was actually about the specs:
1) Asciidoctor::RFC::V2::Converter processes RFC 6350 RFC XML v2 example with bibliography preprocessing, with equivalent text
Failure/Error: File.write("#{old_xml}.txt", remove_pages(File.read("#{old_xml}.txt.1", encoding: "utf-8")))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/rfc6350.xml.txt.1
# ./spec/asciidoctor/rfc/v2/text_spec.rb:29:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:29:in `text_compare2'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:36:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
2) Asciidoctor::RFC::V2::Converter processes Davies template with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/davies-template-bare-06.xml.orig.txt"))).to be_equivalent_to norm(File.read("spec/examples/davies-template-bare-06.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/davies-template-bare-06.xml.orig.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:42:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:42:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
3) Asciidoctor::RFC::V2::Converter processes MIB template with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/mib-doc-template-xml-06.xml.orig.txt"))).to be_equivalent_to norm(File.read("spec/examples/mib-doc-template-xml-06.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/mib-doc-template-xml-06.xml.orig.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:47:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:47:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
4) Asciidoctor::RFC::V2::Converter processes rfc1149 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc1149.md.2.xml.txt"))).to be_equivalent_to norm(File.read("spec/examples/rfc1149.md.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/rfc1149.md.2.xml.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:53:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:53:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
5) Asciidoctor::RFC::V2::Converter processes rfc2100 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc2100.md.2.xml.txt"))).to be_equivalent_to norm(File.read("spec/examples/rfc2100.md.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/rfc2100.md.2.xml.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:59:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:59:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
6) Asciidoctor::RFC::V2::Converter processes rfc3514 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc3514.md.2.xml.txt"))).to be_equivalent_to norm(File.read("spec/examples/rfc3514.md.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/rfc3514.md.2.xml.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:65:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:65:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
7) Asciidoctor::RFC::V2::Converter processes rfc5841 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc5841.md.2.xml.txt"))).to be_equivalent_to norm(File.read("spec/examples/rfc5841.md.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/rfc5841.md.2.xml.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:71:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:71:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
8) Asciidoctor::RFC::V2::Converter processes rfc748 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc748.md.2.xml.txt"))).to be_equivalent_to norm(File.read("spec/examples/rfc748.md.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/rfc748.md.2.xml.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:77:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:77:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
9) Asciidoctor::RFC::V2::Converter processes rfc7511 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc7511.md.2.xml.txt"))).to be_equivalent_to norm(File.read("spec/examples/rfc7511.md.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/rfc7511.md.2.xml.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:83:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:83:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
10) Asciidoctor::RFC::V2::Converter processes draft-ietf-core-block-xx from Kramdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/draft-ietf-core-block-xx.xml.orig.txt"))).to be_equivalent_to norm(File.read("spec/examples/draft-ietf-core-block-xx.mkd.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/draft-ietf-core-block-xx.xml.orig.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:89:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:89:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
11) Asciidoctor::RFC::V2::Converter processes skel from Kramdown with equivalent text
Failure/Error: expect(File.read("spec/examples/skel.xml.orig.txt")).to be_equivalent_to File.read("spec/examples/skel.mkd.xml.txt")
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/skel.xml.orig.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:95:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:95:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
12) Asciidoctor::RFC::V2::Converter processes stupid-s from Kramdown with equivalent text
Failure/Error: expect(File.read("spec/examples/stupid-s.xml.orig.txt")).to be_equivalent_to File.read("spec/examples/stupid-s.mkd.xml.txt")
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/stupid-s.xml.orig.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:101:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:101:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
13) Asciidoctor::RFC::V2::Converter processes Hoffman RFC XML v2 example with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/hoffmanv2.xml.orig.txt"))).to be_equivalent_to norm(File.read("spec/examples/hoffmanv2.xml.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/hoffmanv2.xml.orig.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:106:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:106:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
14) Asciidoctor::RFC::V2::Converter processes draft-iab-rfc-framework-bis RFC XML v2 example with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/draft-iab-rfc-framework-bis.xml.orig.txt"))).to be_equivalent_to norm(File.read("spec/examples/draft-iab-rfc-framework-bis.xml.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/draft-iab-rfc-framework-bis.xml.orig.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:111:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:111:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
15) Asciidoctor::RFC::V2::Converter processes draft-iab-html-rfc-bis RFC XML v2 example with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/draft-iab-html-rfc-bis.xml.orig.txt"))).to be_equivalent_to norm(File.read("spec/examples/draft-iab-html-rfc-bis.xml.xml.txt"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/draft-iab-html-rfc-bis.xml.orig.txt
# ./spec/asciidoctor/rfc/v2/text_spec.rb:116:in `read'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:116:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
16) Asciidoctor::RFC::V3::Converter processes v3 sample biblio file
Failure/Error: expect(remove_preptime(File.read("spec/examples/refs-v3.new.xml"))).to be_equivalent_to remove_prepTime(File.read("spec/examples/refs-v3.xml"))
Errno::ENOENT:
No such file or directory @ rb_sysopen - spec/examples/refs-v3.new.xml
# ./spec/asciidoctor/rfc/v3/biblio_spec.rb:11:in `read'
# ./spec/asciidoctor/rfc/v3/biblio_spec.rb:11:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
Finished in 2 minutes 26.6 seconds (files took 0.37223 seconds to load)
271 examples, 16 failures
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
The specs fail anyway, because the documents' TXT outputs are not exact copies of the TXT outputs that come out of the box. They are as close as I could get them. (The biblio v3 also fails deliberately, because the biblio gem does not yet support referencegroups.)
But the issue you're finding is different: it looks like I haven't checked in some files! Checking...
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
... No, did clean check out, and it works. I get errors in rspec, but they are because of slight format differences, not failure to generate.
To reconstruct this: spec/examples/draft-iab-html-rfc-bis.xml.orig.txt (for example) is generated by text_compare() in text_spec.rb :
File.write("#{old_xml}.1", norm(File.read(old_xml, encoding: "utf-8")))
system("xml2rfc #{old_xml}.1 -o #{old_xml}.txt")
In spec/examples, draft-iab-html-rfc-bis.xml.orig is included in the distro.
draft-iab-html-rfc-bis.xml.orig.1 should be there, because all the code is doing is converting the source file to UTF-8.
xml2rfc draft-iab-html-rfc-bis.xml.orig.1 -o draft-iab-html-rfc-bis.xml.orig.txt therefore seems to be failing on your side. Now since it is processing found RFC XML built by others, that is a surprise.
Could you confirm by checking if draft-iab-html-rfc-bis.xml.orig.1 is there, and what happens when you xml2rfc it?
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
I've changed the text_spec.rb file to use the default rspec string matchers that support multi-line matching, and now the failures only show the diffs.
A number of tests are failing because of this:
-Intended status: Informational November 3, 2017
+Intended status: Informational November 03, 2017
In our gem we are specifying this:
<date year="2017" month="November" day="03"/>But we should be doing this:
<date year="2017" month="November" day="3"/>from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
For Travis, maybe the problem is that xml2rfc isn't installed and therefore unable to generate those text documents?
It actually looks like most of the text differences (except 6350...) can be fixed!
Failures:
1) Asciidoctor::RFC::V2::Converter processes RFC 6350 RFC XML v2 example with bibliography preprocessing, with equivalent text
Failure/Error: expect(File.read("spec/examples/rfc6350.xml.txt")).to eq(File.read("spec/examples/rfc6350.txt.orig"))
expected: "\n\nInternet Engineering Task Force (IETF) S. Perreault\nRequest for Comments: ...p://www.viagenie.ca\n\nPerreault Standards Track [Page 74]\n\f"
got: "\n\nInternet Engineering Task Force (IETF) S. Perreault\nRequest for Comments: ...ttp://www.viagenie.ca\n\nPerreault Standards Track [Page 74]\n"
(compared using ==)
Diff:
@@ -61,125 +61,126 @@
Table of Contents
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3. vCard Format Specification . . . . . . . . . . . . . . . . . . 5
- 3.1. Charset . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.2. Line Delimiting and Folding . . . . . . . . . . . . . . . 5
- 3.3. ABNF Format Definition . . . . . . . . . . . . . . . . . . 6
- 3.4. Property Value Escaping . . . . . . . . . . . . . . . . . 9
- 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 9
- 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 12
- 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 13
- 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14
- 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 14
- 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 4.7. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . . 15
- 4.8. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16
- 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16
- 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 5.7. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . . . 20
- 5.8. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 5.9. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 5.10. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
- 5.11. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. vCard Format Specification . . . . . . . . . . . . . . . . . 5
+ 3.1. Charset . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Line Delimiting and Folding . . . . . . . . . . . . . . . 5
+ 3.3. ABNF Format Definition . . . . . . . . . . . . . . . . . 6
+ 3.4. Property Value Escaping . . . . . . . . . . . . . . . . . 8
+ 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 9
+ 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . 12
+ 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 13
+ 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . 13
+ 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.7. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.8. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . 15
+ 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 15
+ 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 5.7. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.8. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.9. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 5.10. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 5.11. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . 22
- 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 23
- 6.1. General Properties . . . . . . . . . . . . . . . . . . . . 23
- 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 23
- 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 23
- 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 24
- 6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 25
- 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 27
- 6.2. Identification Properties . . . . . . . . . . . . . . . . 28
- 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 28
- 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 29
- 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 29
- 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 30
- 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 30
- 6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 31
- 6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 32
- 6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 32
- 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 32
- 6.4. Communications Properties . . . . . . . . . . . . . . . . 34
- 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 34
- 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 36
- 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 36
- 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 37
- 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 37
- 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 37
- 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 38
- 6.6. Organizational Properties . . . . . . . . . . . . . . . . 39
- 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 39
- 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 39
- 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 40
- 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 40
- 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 41
- 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 42
- 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 43
- 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 43
- 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 44
- 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 44
- 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 45
- 6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 45
- 6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 46
- 6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 47
- 6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 47
- 6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 48
- 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 48
- 6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 48
- 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 49
- 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 49
- 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 50
- 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 50
+ 6.1. General Properties . . . . . . . . . . . . . . . . . . . 23
+ 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . 24
+ 6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 27
+ 6.2. Identification Properties . . . . . . . . . . . . . . . . 28
+ 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . 29
+ 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 29
+ 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 31
+ 6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . 31
+ 6.3. Delivery Addressing Properties . . . . . . . . . . . . . 32
+ 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 32
+ 6.4. Communications Properties . . . . . . . . . . . . . . . . 34
+ 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 34
+ 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 35
+ 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . 36
+ 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . 36
+ 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 37
+ 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . 37
+ 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 38
+ 6.6. Organizational Properties . . . . . . . . . . . . . . . . 38
+ 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 38
+ 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . 39
+ 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . 39
+ 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 40
+ 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . 40
+ 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 42
+ 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . 43
+ 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . 43
+ 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . 43
+ 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . 44
+ 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 44
+ 6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 45
+ 6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 45
+ 6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . 46
+ 6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 47
+ 6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 47
+ 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 48
+ 6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 48
+ 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 48
+ 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 49
+ 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 49
+ 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . 50
+ 6.10. Extended Properties and Parameters . . . . . . . . . . . 50
- 6.10. Extended Properties and Parameters . . . . . . . . . . . . 51
- 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 51
- 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 51
- 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 51
- 7.1.2. Matching Property Instances . . . . . . . . . . . . . 52
- 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 52
- 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 53
- 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 53
- 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 53
- 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 54
- 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 54
- 7.2.5. Global Context Simplification . . . . . . . . . . . . 56
- 8. Example: Author's vCard . . . . . . . . . . . . . . . . . . . 56
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
- 10.1. Media Type Registration . . . . . . . . . . . . . . . . . 58
- 10.2. Registering New vCard Elements . . . . . . . . . . . . . . 59
- 10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 59
- 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 60
- 10.2.3. Registration Template for Properties . . . . . . . . . 61
- 10.2.4. Registration Template for Parameters . . . . . . . . . 61
- 10.2.5. Registration Template for Value Data Types . . . . . . 62
- 10.2.6. Registration Template for Values . . . . . . . . . . . 62
- 10.3. Initial vCard Elements Registries . . . . . . . . . . . . 63
- 10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 64
- 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 65
- 10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 65
- 10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 66
- 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
- 12.1. Normative References . . . . . . . . . . . . . . . . . . . 69
- 12.2. Informative References . . . . . . . . . . . . . . . . . . 71
- Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 73
- A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 73
- A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 73
- A.3. New Properties and Parameters . . . . . . . . . . . . . . 73
+ 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 50
+ 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 51
+ 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . 51
+ 7.1.2. Matching Property Instances . . . . . . . . . . . . . 51
+ 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . 51
+ 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 52
+ 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . 52
+ 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 53
+ 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 53
+ 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . 54
+ 7.2.5. Global Context Simplification . . . . . . . . . . . . 55
+ 8. Example: Author's vCard . . . . . . . . . . . . . . . . . . . 56
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 56
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
+ 10.1. Media Type Registration . . . . . . . . . . . . . . . . 57
+ 10.2. Registering New vCard Elements . . . . . . . . . . . . . 58
+ 10.2.1. Registration Procedure . . . . . . . . . . . . . . . 58
+ 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . 59
+ 10.2.3. Registration Template for Properties . . . . . . . . 60
+ 10.2.4. Registration Template for Parameters . . . . . . . . 60
+ 10.2.5. Registration Template for Value Data Types . . . . . 61
+ 10.2.6. Registration Template for Values . . . . . . . . . . 61
+ 10.3. Initial vCard Elements Registries . . . . . . . . . . . 62
+ 10.3.1. Properties Registry . . . . . . . . . . . . . . . . 62
+ 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . 63
+ 10.3.3. Value Data Types Registry . . . . . . . . . . . . . 64
+ 10.3.4. Values Registries . . . . . . . . . . . . . . . . . 64
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 68
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . 68
+ 12.2. Informative References . . . . . . . . . . . . . . . . . 70
+ Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . 73
+ A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 73
+ A.2. Removed Features . . . . . . . . . . . . . . . . . . . . 73
+ A.3. New Properties and Parameters . . . . . . . . . . . . . . 73
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 74
1. Introduction
@@ -229,7 +230,6 @@
single white space character (space (U+0020) or horizontal tab
(U+0009)). The folded line MUST contain at least one character. Any
sequence of CRLF followed immediately by a single white space
-
character is ignored (removed) when processing the content type. For
example, the line:
@@ -253,13 +253,13 @@
(U+0020)) as equivalent to no characters at all (i.e., the CRLF and
single white space character are removed).
- Note: It is possible for very simple implementations to generate
- improperly folded lines in the middle of a UTF-8 multi-octet
- sequence. For this reason, implementations SHOULD unfold lines in
- such a way as to properly restore the original sequence.
+ Note: It is possible for very simple implementations to generate
+ improperly folded lines in the middle of a UTF-8 multi-octet
+ sequence. For this reason, implementations SHOULD unfold lines in
+ such a way as to properly restore the original sequence.
- Note: Unfolding is done differently than in [RFC5322]. Unfolding
- in [RFC5322] only removes the CRLF, not the space following it.
+ Note: Unfolding is done differently than in [RFC5322]. Unfolding in
+ [RFC5322] only removes the CRLF, not the space following it.
Folding is done after any content encoding of a type value.
Unfolding is done before any decoding of a type value in a content
@@ -290,6 +290,7 @@
group = 1*(ALPHA / DIGIT / "-")
name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME"
/ "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / "TEL"
+
/ "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE"
/ "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES"
/ "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP"
@@ -338,6 +339,7 @@
Property names and parameter names are case-insensitive (e.g., the
property name "fn" is the same as "FN" and "Fn"). Parameter values
+
MAY be case-sensitive or case-insensitive, depending on their
definition. Parameter values that are not explicitly defined as
being case-sensitive are case-insensitive. Based on experience with
@@ -358,10 +360,10 @@
+-------------+--------------------------------------------------+
| Cardinality | Meaning |
+-------------+--------------------------------------------------+
- | 1 | Exactly one instance per vCard MUST be present. |
- | *1 | Exactly one instance per vCard MAY be present. |
- | 1* | One or more instances per vCard MUST be present. |
- | * | One or more instances per vCard MAY be present. |
+ | 1 | Exactly one instance per vCard MUST be present. |
+ | *1 | Exactly one instance per vCard MAY be present. |
+ | 1* | One or more instances per vCard MUST be present. |
+ | * | One or more instances per vCard MAY be present. |
+-------------+--------------------------------------------------+
Properties defined in a vCard instance may have multiple values
@@ -385,6 +387,7 @@
of such a "compound" property MUST be escaped with a BACKSLASH
character. SEMICOLON characters in non-compound properties MAY be
escaped. On input, an escaped SEMICOLON character is never a field
+
separator. An unescaped SEMICOLON character may be a field
separator, depending on the property in which it appears.
@@ -433,6 +436,7 @@
list-component = component *("," component)
text-list = text *("," text)
+
date-list = date *("," date)
time-list = time *("," time)
date-time-list = date-time *("," date-time)
@@ -549,8 +553,8 @@
Reduced accuracy, as specified in [ISO.8601.2004], Sections 4.1.2.3
a) and b), but not c), is permitted.
- Expanded representation, as specified in [ISO.8601.2004], Section
- 4.1.4, is forbidden.
+ Expanded representation, as specified in [ISO.8601.2004],
+ Section 4.1.4, is forbidden.
Truncated representation, as specified in [ISO.8601.2000], Sections
5.2.1.3 d), e), and f), is permitted.
@@ -564,9 +568,9 @@
---12
Note the use of YYYY-MM in the second example above. YYYYMM is
- disallowed to prevent confusion with YYMMDD. Note also that
- YYYY-MM-DD is disallowed since we are using the basic format instead
- of the extended format.
+ disallowed to prevent confusion with YYMMDD. Note also that YYYY-MM-
+ DD is disallowed since we are using the basic format instead of the
+ extended format.
4.3.2. TIME
@@ -599,8 +603,8 @@
A date and time of day combination as specified in [ISO.8601.2004],
Section 4.3.
- Truncation of the date part, as specified in [ISO.8601.2000], Section
- 5.4.2 c), is permitted.
+ Truncation of the date part, as specified in [ISO.8601.2000],
+ Section 5.4.2 c), is permitted.
Examples for "date-time":
@@ -678,8 +682,8 @@
Implementations MUST support a precision equal or better than that of
the IEEE "binary64" format [IEEE.754.2008].
- Note: Scientific notation is disallowed. Implementers wishing to
- use their favorite language's %f formatting should be careful.
+ Note: Scientific notation is disallowed. Implementers wishing to use
+ their favorite language's %f formatting should be careful.
Examples:
@@ -747,7 +751,6 @@
formats is encouraged even if the value parameter is not explicitly
used. By defining a standard set of value types and their formats,
existing parsing and processing code can be leveraged. The
-
predefined data type values MUST NOT be repeated in COMMA-separated
value lists except within the N, NICKNAME, ADR, and CATEGORIES
properties.
@@ -889,7 +892,6 @@
predefined enumeration. In this document, the following properties
make use of this parameter: FN, NICKNAME, PHOTO, ADR, TEL, EMAIL,
IMPP, LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES,
-
NOTE, SOUND, URL, KEY, FBURL, CALADRURI, and CALURI. The TYPE
parameter MUST NOT be applied on other properties defined in this
document.
@@ -904,7 +906,7 @@
ABNF:
- type-param = "TYPE=" type-value *("," type-value)
+ type-param = "TYPE=" type-value *("," type-value)
type-value = "work" / "home" / type-param-tel
/ type-param-related / iana-token / x-name
@@ -938,7 +940,6 @@
only value specified by iCalendar is "gregorian", which stands for
the Gregorian system. It is the default when the parameter is
absent. Additional values may be defined in extension documents and
-
registered with IANA (see Section 10.3.4). A vCard implementation
MUST ignore properties with a CALSCALE parameter value that it does
not understand.
@@ -1044,7 +1045,6 @@
Special notes: The content entity MUST begin with the BEGIN property
with a value of "VCARD". The value is case-insensitive.
-
The BEGIN property is used in conjunction with the END property to
delimit an entity containing a related set of properties within a
text/vcard content-type. This construct can be used instead of
@@ -1074,13 +1074,13 @@
Special notes: The content entity MUST end with the END type with a
value of "VCARD". The value is case-insensitive.
-
The END property is used in conjunction with the BEGIN property to
delimit an entity containing a related set of properties within a
text/vcard content-type. This construct can be used instead of or
in addition to wrapping separate sets of information inside
additional MIME headers. It is provided for applications that
wish to define content that can contain multiple entities within
+
the same text/vcard content-type or to define content that can be
identifiable outside of a MIME environment.
@@ -1135,92 +1135,86 @@
Special notes: The value may be one of the following:
- "individual" for a vCard representing a single person or entity.
- This is the default kind of vCard.
+ "individual" for a vCard representing a single person or entity.
+ This is the default kind of vCard.
- "group" for a vCard representing a group of persons or entities.
- The group's member entities can be other vCards or other types
- of entities, such as email addresses or web sites. A group
- vCard will usually contain MEMBER properties to specify the
- members of the group, but it is not required to. A group vCard
- without MEMBER properties can be considered an abstract
- grouping, or one whose members are known empirically (perhaps
- "IETF Participants" or "Republican U.S. Senators").
+ "group" for a vCard representing a group of persons or entities.
+ The group's member entities can be other vCards or other types of
+ entities, such as email addresses or web sites. A group vCard
+ will usually contain MEMBER properties to specify the members of
+ the group, but it is not required to. A group vCard without
+ MEMBER properties can be considered an abstract grouping, or one
+ whose members are known empirically (perhaps "IETF Participants"
+ or "Republican U.S. Senators").
+ All properties in a group vCard apply to the group as a whole, and
+ not to any particular MEMBER. For example, an EMAIL property
+ might specify the address of a mailing list associated with the
+ group, and an IMPP property might refer to a group chat room.
- All properties in a group vCard apply to the group as a whole,
- and not to any particular MEMBER. For example, an EMAIL
- property might specify the address of a mailing list associated
- with the group, and an IMPP property might refer to a group
- chat room.
+ "org" for a vCard representing an organization. An organization
+ vCard will not (in fact, MUST NOT) contain MEMBER properties, and
+ so these are something of a cross between "individual" and
+ "group". An organization is a single entity, but not a person.
+ It might represent a business or government, a department or
+ division within a business or government, a club, an association,
+ or the like.
+ All properties in an organization vCard apply to the organization
+ as a whole, as is the case with a group vCard. For example, an
+ EMAIL property might specify the address of a contact point for
+ the organization.
- "org" for a vCard representing an organization. An organization
- vCard will not (in fact, MUST NOT) contain MEMBER properties,
- and so these are something of a cross between "individual" and
- "group". An organization is a single entity, but not a person.
- It might represent a business or government, a department or
- division within a business or government, a club, an
- association, or the like.
+ "location" for a named geographical place. A location vCard will
+ usually contain a GEO property, but it is not required to. A
+ location vCard without a GEO property can be considered an
+ abstract location, or one whose definition is known empirically
+ (perhaps "New England" or "The Seashore").
+ All properties in a location vCard apply to the location itself,
+ and not with any entity that might exist at that location. For
+ example, in a vCard for an office building, an ADR property might
+ give the mailing address for the building, and a TEL property
+ might specify the telephone number of the receptionist.
- All properties in an organization vCard apply to the
- organization as a whole, as is the case with a group vCard.
- For example, an EMAIL property might specify the address of a
- contact point for the organization.
+ An x-name. vCards MAY include private or experimental values for
+ KIND. Remember that x-name values are not intended for general
+ use and are unlikely to interoperate.
- "location" for a named geographical place. A location vCard will
- usually contain a GEO property, but it is not required to. A
- location vCard without a GEO property can be considered an
- abstract location, or one whose definition is known empirically
- (perhaps "New England" or "The Seashore").
+ An iana-token. Additional values may be registered with IANA (see
+ Section 10.3.4). A new value's specification document MUST
+ specify which properties make sense for that new kind of vCard and
+ which do not.
- All properties in a location vCard apply to the location
- itself, and not with any entity that might exist at that
- location. For example, in a vCard for an office building, an
- ADR property might give the mailing address for the building,
- and a TEL property might specify the telephone number of the
- receptionist.
+ Implementations MUST support the specific string values defined
+ above. If this property is absent, "individual" MUST be assumed as
+ the default. If this property is present but the implementation does
+ not understand its value (the value is an x-name or iana-token that
+ the implementation does not support), the implementation SHOULD act
+ in a neutral way, which usually means treating the vCard as though
+ its kind were "individual". The presence of MEMBER properties MAY,
+ however, be taken as an indication that the unknown kind is an
+ extension of "group".
- An x-name. vCards MAY include private or experimental values for
- KIND. Remember that x-name values are not intended for general
- use and are unlikely to interoperate.
+ Clients often need to visually distinguish contacts based on what
+ they represent, and the KIND property provides a direct way for them
+ to do so. For example, when displaying contacts in a list, an icon
+ could be displayed next to each one, using distinctive icons for the
+ different kinds; a client might use an outline of a single person to
+ represent an "individual", an outline of multiple people to represent
+ a "group", and so on. Alternatively, or in addition, a client might
+ choose to segregate different kinds of vCards to different panes,
+ tabs, or selections in the user interface.
- An iana-token. Additional values may be registered with IANA (see
- Section 10.3.4). A new value's specification document MUST
- specify which properties make sense for that new kind of vCard
- and which do not.
+ Some clients might also make functional distinctions among the kinds,
+ ignoring "location" vCards for some purposes and considering only
+ "location" vCards for others.
- Implementations MUST support the specific string values defined
- above. If this property is absent, "individual" MUST be assumed
- as the default. If this property is present but the
- implementation does not understand its value (the value is an
- x-name or iana-token that the implementation does not support),
- the implementation SHOULD act in a neutral way, which usually
- means treating the vCard as though its kind were "individual".
- The presence of MEMBER properties MAY, however, be taken as an
- indication that the unknown kind is an extension of "group".
+ When designing those sorts of visual and functional distinctions,
+ client implementations have to decide how to fit unsupported kinds
+ into the scheme. What icon is used for them? The one for
+ "individual"? A unique one, such as an icon of a question mark?
+ Which tab do they go into? It is beyond the scope of this
+ specification to answer these questions, but these are things
+ implementers need to consider.
- Clients often need to visually distinguish contacts based on what
- they represent, and the KIND property provides a direct way for
- them to do so. For example, when displaying contacts in a list,
- an icon could be displayed next to each one, using distinctive
- icons for the different kinds; a client might use an outline of a
- single person to represent an "individual", an outline of multiple
- people to represent a "group", and so on. Alternatively, or in
- addition, a client might choose to segregate different kinds of
- vCards to different panes, tabs, or selections in the user
- interface.
-
- Some clients might also make functional distinctions among the
- kinds, ignoring "location" vCards for some purposes and
- considering only "location" vCards for others.
-
- When designing those sorts of visual and functional distinctions,
- client implementations have to decide how to fit unsupported kinds
- into the scheme. What icon is used for them? The one for
- "individual"? A unique one, such as an icon of a question mark?
- Which tab do they go into? It is beyond the scope of this
- specification to answer these questions, but these are things
- implementers need to consider.
-
ABNF:
KIND-param = "VALUE=text" / any-param
@@ -1238,10 +1232,9 @@
FN:Jane Doe
ORG:ABC\, Inc.;North American Division;Marketing
END:VCARD
+ This represents the department itself, commonly known as ABC
+ Marketing.
- This represents the department itself, commonly known as ABC
- Marketing.
-
BEGIN:VCARD
VERSION:4.0
KIND:org
@@ -1261,20 +1254,16 @@
Special notes: The content of this property is a single XML 1.0
[W3C.REC-xml-20081126] element whose namespace MUST be explicitly
specified using the xmlns attribute and MUST NOT be the vCard 4
-
namespace ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies
that it cannot duplicate a standard vCard property.) The element
is to be interpreted as if it was contained in a <vcard> element,
as defined in [RFC6351].
-
The fragment is subject to normal line folding and escaping, i.e.,
replace all backslashes with "\\", then replace all newlines with
"\n", then fold long lines.
-
Support for this property is OPTIONAL, but implementations of this
specification MUST preserve instances of this property when
propagating vCards.
-
See [RFC6351] for more information on the intended use of this
property.
@@ -1507,39 +1496,44 @@
address components. The component values MUST be specified in
their corresponding position. The structured type value
corresponds, in sequence, to
+
the post office box;
+
the extended address (e.g., apartment or suite number);
+
the street address;
+
the locality (e.g., city);
+
the region (e.g., state or province);
+
the postal code;
+
the country name (full name in the language specified in
Section 5.1).
- When a component value is missing, the associated component
- separator MUST still be specified.
+ When a component value is missing, the associated component separator
+ MUST still be specified.
- Experience with vCard 3 has shown that the first two components
- (post office box and extended address) are plagued with many
- interoperability issues. To ensure maximal interoperability,
- their values SHOULD be empty.
+ Experience with vCard 3 has shown that the first two components (post
+ office box and extended address) are plagued with many
+ interoperability issues. To ensure maximal interoperability, their
+ values SHOULD be empty.
- The text components are separated by the SEMICOLON character
- (U+003B). Where it makes semantic sense, individual text
- components can include multiple text values (e.g., a "street"
- component with multiple lines) separated by the COMMA character
- (U+002C).
+ The text components are separated by the SEMICOLON character
+ (U+003B). Where it makes semantic sense, individual text components
+ can include multiple text values (e.g., a "street" component with
+ multiple lines) separated by the COMMA character (U+002C).
- The property can include the "PREF" parameter to indicate the
- preferred delivery address when more than one address is
- specified.
+ The property can include the "PREF" parameter to indicate the
+ preferred delivery address when more than one address is specified.
- The GEO and TZ parameters MAY be used with this property.
+ The GEO and TZ parameters MAY be used with this property.
- The property can also include a "LABEL" parameter to present a
- delivery address label for the address. Its value is a plain-text
- string representing the formatted address. Newlines are encoded
- as \n, as they are for property values.
+ The property can also include a "LABEL" parameter to present a
+ delivery address label for the address. Its value is a plain-text
+ string representing the formatted address. Newlines are encoded as
+ \n, as they are for property values.
ABNF:
@@ -1561,8 +1555,8 @@
ADR-component-code = list-component
ADR-component-country = list-component
- Example: In this example, the post office box and the extended
- address are absent.
+ Example: In this example, the post office box and the extended
+ address are absent.
ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n
Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n
@@ -1587,10 +1581,8 @@
Special notes: This property is based on the X.520 Telephone Number
attribute [CCITT.X520.1988].
-
The property can include the "PREF" parameter to indicate a
preferred-use telephone number.
-
The property can include the parameter "TYPE" to specify intended
use for the telephone number. The predefined values for the TYPE
parameter are:
@@ -1609,18 +1601,18 @@
| | hearing or speech difficulties. |
+-----------+-------------------------------------------------------+
- The default type is "voice". These type parameter values can be
- specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a
- value list (e.g., TYPE="text,voice"). The default can be
- overridden to another set of values by specifying one or more
- alternate values. For example, the default TYPE of "voice" can be
- reset to a VOICE and FAX telephone number by the value list
- TYPE="voice,fax".
+ The default type is "voice". These type parameter values can be
+ specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a
+ value list (e.g., TYPE="text,voice"). The default can be overridden
+ to another set of values by specifying one or more alternate values.
- If this property's value is a URI that can also be used for
- instant messaging, the IMPP (Section 6.4.3) property SHOULD be
- used in addition to this property.
+ For example, the default TYPE of "voice" can be reset to a VOICE and
+ FAX telephone number by the value list TYPE="voice,fax".
+ If this property's value is a URI that can also be used for instant
+ messaging, the IMPP (Section 6.4.3) property SHOULD be used in
+ addition to this property.
+
ABNF:
TEL-param = TEL-text-param / TEL-uri-param
@@ -1657,7 +1649,6 @@
Special notes: The property can include tye "PREF" parameter to
indicate a preferred-use email address when more than one is
specified.
-
Even though the value is free-form UTF-8 text, it is likely to be
interpreted by a Mail User Agent (MUA) as an "addr-spec", as
defined in [RFC5322], Section 3.4.1. Readers should also be aware
@@ -1688,11 +1679,9 @@
Special notes: The property may include the "PREF" parameter to
indicate that this is a preferred address and has the same
semantics as the "PREF" parameter in a TEL property.
-
- If this property's value is a URI that can be used for voice
- and/or video, the TEL property (Section 6.4.1) SHOULD be used in
+ If this property's value is a URI that can be used for voice and/
+ or video, the TEL property (Section 6.4.1) SHOULD be used in
addition to this property.
-
This property is adapted from [RFC4770], which is made obsolete by
this document.
@@ -1746,12 +1735,10 @@
Special notes: It is expected that names from the public-domain
Olson database [TZ-DB] will be used, but this is not a
restriction. See also [IANA-TZ].
-
Efforts are currently being directed at creating a standard URI
scheme for expressing time zone information. Usage of such a
scheme would ensure a high level of interoperability between
implementations that support it.
-
Note that utc-offset values SHOULD NOT be used because the UTC
offset varies with time -- not just because of the usual daylight
saving time shifts that occur in may regions, but often entire
@@ -1809,7 +1796,7 @@
Value type: A single text value.
- Cardinality: *
+ Cardinality: *
Special notes: This property is based on the X.520 Title attribute
[CCITT.X520.1988].
@@ -1833,11 +1820,11 @@
Cardinality: *
- Special notes: This property is based on the X.520 Business Category
- explanatory attribute [CCITT.X520.1988]. This property is
- included as an organizational type to avoid confusion with the
- semantics of the TITLE property and incorrect usage of that
- property when the semantics of this property is intended.
+ Special notes: This property is based on the X.520 Business Category
+ explanatory attribute [CCITT.X520.1988]. This property is included
+ as an organizational type to avoid confusion with the semantics of
+ the TITLE property and incorrect usage of that property when the
+ semantics of this property is intended.
ABNF:
@@ -1887,7 +1874,6 @@
and Organization Unit attributes [CCITT.X520.1988]. The property
value is a structured type consisting of the organization name,
followed by zero or more levels of organizational unit names.
-
The SORT-AS parameter MAY be applied to this property.
ABNF:
@@ -1897,8 +1883,8 @@
/ any-param
ORG-value = component *(";" component)
- Example: A property value consisting of an organizational name,
- organizational unit #1 name, and organizational unit #2 name.
+ Example: A property value consisting of an organizational name,
+ organizational unit #1 name, and organizational unit #2 name.
ORG:ABC\, Inc.;North American Division;Marketing
@@ -2039,8 +2025,8 @@
Cardinality: *
- Special notes: The property is based on the X.520 Description
- attribute [CCITT.X520.1988].
+ Special notes: The property is based on the X.520 Description
+ attribute [CCITT.X520.1988].
ABNF:
@@ -2174,10 +2160,8 @@
instance. Each distinct source identifier present in a vCard MUST
have an associated CLIENTPIDMAP. See Section 7 for more details
on the usage of CLIENTPIDMAP.
-
PID source identifiers MUST be strictly positive. Zero is not
allowed.
-
As a special exception, the PID parameter MUST NOT be applied to
this property.
@@ -2346,7 +2330,6 @@
Special notes: Where multiple CALURI properties are specified, the
default CALURI property is indicated with the PREF parameter. The
property should contain a URI pointing to an iCalendar [RFC5545]
-
object associated with a snapshot of the user's calendar store.
If the iCalendar object is represented as a file or document, its
file extension should be ".ics".
@@ -2467,16 +2450,16 @@
CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
END:VCARD
- This new vCard is assigned the UID
- "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating
- device. The FN and EMAIL properties are assigned the same local
- value of 1, and this value is given global context by associating it
- with "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which
- represents the creating device. We are at liberty to reuse the same
- local value since instances of different properties will never be
- matched. The N property has no PID because it is forbidden by its
- maximum cardinality of 1.
+ This new vCard is assigned the UID "urn:uuid:4fbe8971-0bc3-424c-
+ 9c26-36c3e1eff6b1" by the creating device. The FN and EMAIL
+ properties are assigned the same local value of 1, and this value is
+ given global context by associating it with "urn:uuid:53e374d9-337e-
+ 4727-8803-a1e9c14e0556", which represents the creating device. We
+ are at liberty to reuse the same local value since instances of
+ different properties will never be matched. The N property has no
+ PID because it is forbidden by its maximum cardinality of 1.
+
7.2.2. Initial Sharing
This vCard is shared with a second device. Upon inspecting the UID
@@ -2569,6 +2552,7 @@
Although the situation appears to be the same for the TEL properties,
in this case, the synchronization engine is particularly smart and
+
matches the two new TEL properties even though their PID global
values are different. Note that in this case, the rules of
Section 7.1.2 state that two properties MAY be matched at the
@@ -2626,7 +2610,6 @@
BDAY:--0203
ANNIVERSARY:20090808T1430-0500
GENDER:M
-
LANG;PREF=1:fr
LANG;PREF=2:en
ORG;TYPE=work:Viagenie
@@ -2680,7 +2663,7 @@
10.1. Media Type Registration
IANA has registered the following Media Type (in
- <http://www.iana.org/>) and marked the text/directory Media Type as
+ <http://www.iana.org>) and marked the text/directory Media Type as
DEPRECATED.
To: [email protected]
@@ -2694,12 +2677,10 @@
Required parameters: none
Optional parameters: version
-
The "version" parameter is to be interpreted identically as the
VERSION vCard property. If this parameter is present, all vCards
in a text/vcard body part MUST have a VERSION property with value
identical to that of this MIME parameter.
-
"charset": as defined for text/plain [RFC2046]; encodings other
than UTF-8 [RFC3629] MUST NOT be used.
@@ -2709,7 +2690,7 @@
Interoperability considerations: The text/vcard media type is
intended to identify vCard data of any version. There are older
- specifications of vCard [RFC2426][vCard21] still in common use.
+ specifications of vCard [RFC2426] [vCard21] still in common use.
While these formats are similar, they are not strictly compatible.
In general, it is necessary to inspect the value of the VERSION
property (see Section 6.7.9) for identifying the standard to which
@@ -2720,7 +2701,9 @@
favor of text/vcard.
* text/directory
+
* text/directory; profile=vcard
+
* text/x-vcard
Published specification: RFC 6350
@@ -2738,8 +2721,8 @@
Macintosh file type code(s):
- Person & email address to contact for further information: vCard
- discussion mailing list <[email protected]>
+ Person & email address to contact for further information: vCard dis
+ cussion mailing list <[email protected]>
Intended usage: COMMON
@@ -2760,6 +2743,7 @@
The IETF has created a mailing list, [email protected], which can be
used for public discussion of vCard element proposals prior to
registration. Use of the mailing list is strongly encouraged. The
+
IESG has appointed a designated expert who will monitor the
[email protected] mailing list and review registrations.
@@ -3035,102 +3019,129 @@
The following table has been used to initialize the parameter values
registry.
- +------------------------+-----------+--------------+---------------+
- | Property | Parameter | Value | Reference |
- +------------------------+-----------+--------------+---------------+
- | FN, NICKNAME, PHOTO, | TYPE | work | RFC 6350, |
- | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 |
- | LANG, TZ, GEO, TITLE, | | | |
- | ROLE, LOGO, ORG, | | | |
- | RELATED, CATEGORIES, | | | |
- | NOTE, SOUND, URL, KEY, | | | |
- | FBURL, CALADRURI, and | | | |
- | CALURI | | | |
- | FN, NICKNAME, PHOTO, | TYPE | home | RFC 6350, |
- | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 |
- | LANG, TZ, GEO, TITLE, | | | |
- | ROLE, LOGO, ORG, | | | |
- | RELATED, CATEGORIES, | | | |
- | NOTE, SOUND, URL, KEY, | | | |
- | FBURL, CALADRURI, and | | | |
- | CALURI | | | |
- | TEL | TYPE | text | RFC 6350, |
- | | | | Section 6.4.1 |
- | TEL | TYPE | voice | RFC 6350, |
- | | | | Section 6.4.1 |
- | TEL | TYPE | fax | RFC 6350, |
- | | | | Section 6.4.1 |
- | TEL | TYPE | cell | RFC 6350, |
- | | | | Section 6.4.1 |
- | TEL | TYPE | video | RFC 6350, |
- | | | | Section 6.4.1 |
- | TEL | TYPE | pager | RFC 6350, |
- | | | | Section 6.4.1 |
- | TEL | TYPE | textphone | RFC 6350, |
- | | | | Section 6.4.1 |
- | BDAY, ANNIVERSARY | CALSCALE | gregorian | RFC 6350, |
- | | | | Section 5.8 |
- | RELATED | TYPE | contact | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | acquaintance | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | friend | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | met | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
+ +----------------------------+-----------+--------------+-----------+
+ | Property | Parameter | Value | Reference |
+ +----------------------------+-----------+--------------+-----------+
+ | FN, NICKNAME, PHOTO, ADR, | TYPE | work | RFC 6350, |
+ | TEL, EMAIL, IMPP, LANG, | | | Section |
+ | TZ, GEO, TITLE, ROLE, | | | 5.6 |
+ | LOGO, ORG, RELATED, | | | |
+ | CATEGORIES, NOTE, SOUND, | | | |
+ | URL, KEY, FBURL, | | | |
+ | CALADRURI, and CALURI | | | |
+ | FN, NICKNAME, PHOTO, ADR, | TYPE | home | RFC 6350, |
+ | TEL, EMAIL, IMPP, LANG, | | | Section |
+ | TZ, GEO, TITLE, ROLE, | | | 5.6 |
+ | LOGO, ORG, RELATED, | | | |
+ | CATEGORIES, NOTE, SOUND, | | | |
+ | URL, KEY, FBURL, | | | |
+ | CALADRURI, and CALURI | | | |
+ | TEL | TYPE | text | RFC 6350, |
+ | | | | Section |
+ | | | | 6.4.1 |
+ | TEL | TYPE | voice | RFC 6350, |
+ | | | | Section |
+ | | | | 6.4.1 |
+ | TEL | TYPE | fax | RFC 6350, |
+ | | | | Section |
+ | | | | 6.4.1 |
+ | TEL | TYPE | cell | RFC 6350, |
+ | | | | Section |
+ | | | | 6.4.1 |
+ | TEL | TYPE | video | RFC 6350, |
+ | | | | Section |
+ | | | | 6.4.1 |
+ | TEL | TYPE | pager | RFC 6350, |
+ | | | | Section |
- | RELATED | TYPE | co-worker | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | colleague | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | co-resident | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | neighbor | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | child | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | parent | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | sibling | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | spouse | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | kin | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | muse | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | crush | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | date | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | sweetheart | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | me | RFC 6350, |
- | | | | Section 6.6.6 |
- | | | | and [xfn] |
- | RELATED | TYPE | agent | RFC 6350, |
- | | | | Section 6.6.6 |
- | RELATED | TYPE | emergency | RFC 6350, |
- | | | | Section 6.6.6 |
- +------------------------+-----------+--------------+---------------+
+ | | | | 6.4.1 |
+ | TEL | TYPE | textphone | RFC 6350, |
+ | | | | Section |
+ | | | | 6.4.1 |
+ | BDAY, ANNIVERSARY | CALSCALE | gregorian | RFC 6350, |
+ | | | | Section |
+ | | | | 5.8 |
+ | RELATED | TYPE | contact | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | acquaintance | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | friend | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | met | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | co-worker | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | colleague | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | co-resident | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | neighbor | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | child | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | parent | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | sibling | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | spouse | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | kin | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | muse | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | crush | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | date | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | sweetheart | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | me | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 and |
+ | | | | [xfn] |
+ | RELATED | TYPE | agent | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 |
+ | RELATED | TYPE | emergency | RFC 6350, |
+ | | | | Section |
+ | | | | 6.6.6 |
+ +----------------------------+-----------+--------------+-----------+
+
11. Acknowledgments
The authors would like to thank Tim Howes, Mark Smith, and Frank
@@ -3148,7 +3159,7 @@
Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, Julian Reschke,
Kepeng Li, Kevin Marks, Kevin Wu Won, Kurt Zeilenga, Lisa Dusseault,
Marc Blanchet, Mark Paterson, Markus Lorenz, Michael Haardt, Mike
- Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter
+ Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter
Saint-Andre, Renato Iannella, Rohit Khare, Sly Gryphon, Stephane
Bortzmeyer, Tantek Celik, and Zoltan Ordogh.
@@ -3164,8 +3175,8 @@
[IEEE.754.2008]
Institute of Electrical and Electronics Engineers,
- "Standard for Binary Floating-Point Arithmetic",
- IEEE Standard 754, August 2008.
+ "Standard for Binary Floating-Point Arithmetic", IEEE
+ Standard 754, August 2008.
[ISO.8601.2000]
International Organization for Standardization, "Data
@@ -3181,123 +3192,158 @@
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
+ Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
+ <https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
- November 1996.
+ DOI 10.17487/RFC2046, November 1996,
+ <https://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
[RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar
- Attributes for vCard and LDAP", RFC 2739, January 2000.
+ Attributes for vCard and LDAP", RFC 2739,
+ DOI 10.17487/RFC2739, January 2000,
+ <https://www.rfc-editor.org/info/rfc2739>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD 63, RFC 3629, November 2003.
+ 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+ 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
- RFC 3966, December 2004.
+ RFC 3966, DOI 10.17487/RFC3966, December 2004,
+ <https://www.rfc-editor.org/info/rfc3966>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
- RFC 3986, January 2005.
+ RFC 3986, DOI 10.17487/RFC3986, January 2005,
+ <https://www.rfc-editor.org/info/rfc3986>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
- July 2005.
+ DOI 10.17487/RFC4122, July 2005,
+ <https://www.rfc-editor.org/info/rfc4122>.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
- Registration Procedures", BCP 13, RFC 4288, December 2005.
+ Registration Procedures", RFC 4288, DOI 10.17487/RFC4288,
+ December 2005, <https://www.rfc-editor.org/info/rfc4288>.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", STD 68, RFC 5234, January 2008.
+ [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234,
+ DOI 10.17487/RFC5234, January 2008,
+ <https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
- October 2008.
+ DOI 10.17487/RFC5322, October 2008,
+ <https://www.rfc-editor.org/info/rfc5322>.
- [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
- Core Object Specification (iCalendar)", RFC 5545,
- September 2009.
+ [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
+ Scheduling Core Object Specification (iCalendar)",
+ RFC 5545, DOI 10.17487/RFC5545, September 2009,
+ <https://www.rfc-editor.org/info/rfc5545>.
- [RFC5546] Daboo, C., "iCalendar Transport-Independent
+ [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
Interoperability Protocol (iTIP)", RFC 5546,
- December 2009.
+ DOI 10.17487/RFC5546, December 2009,
+ <https://www.rfc-editor.org/info/rfc5546>.
- [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
- Languages", BCP 47, RFC 5646, September 2009.
+ [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
+ Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
+ September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
Identifier for Geographic Locations ('geo' URI)",
- RFC 5870, June 2010.
+ RFC 5870, DOI 10.17487/RFC5870, June 2010,
+ <https://www.rfc-editor.org/info/rfc5870>.
[RFC6351] Perreault, S., "xCard: vCard XML Representation",
- RFC 6351, August 2011.
+ RFC 6351, DOI 10.17487/RFC6351, August 2011,
+ <https://www.rfc-editor.org/info/rfc6351>.
[W3C.REC-xml-20081126]
- Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J.,
- and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
+ Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
+ F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
[xfn] Celik, T., Mullenweg, M., and E. Meyer, "XFN 1.1 profile",
- <http://gmpg.org/xfn/11>.
+ October 2003, <http://gmpg.org/xfn/11>.
12.2. Informative References
[IANA-TZ] Lear, E. and P. Eggert, "IANA Procedures for Maintaining
- the Timezone Database", Work in Progress, May 2011.
+ the Timezone Database", May 2011,
+ <http://gmpg.org/xfn/11>.
[ISO9070] International Organization for Standardization,
"Information Processing - SGML support facilities -
Registration Procedures for Public Text Owner
- Identifiers", ISO 9070, April 1991.
+ Identifiers", ISO Standard 9070, April 1991.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
- Resource Locators (URL)", RFC 1738, December 1994.
+ Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
+ December 1994, <https://www.rfc-editor.org/info/rfc1738>.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
- August 1998.
+ DOI 10.17487/RFC2397, August 1998,
+ <https://www.rfc-editor.org/info/rfc2397>.
[RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type
- for Directory Information", RFC 2425, September 1998.
+ for Directory Information", RFC 2425,
+ DOI 10.17487/RFC2425, September 1998,
+ <https://www.rfc-editor.org/info/rfc2425>.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
- RFC 2426, September 1998.
+ RFC 2426, DOI 10.17487/RFC2426, September 1998,
+ <https://www.rfc-editor.org/info/rfc2426>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
- Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+ Transfer Protocol -- HTTP/1.1", RFC 2616,
+ DOI 10.17487/RFC2616, June 1999,
+ <https://www.rfc-editor.org/info/rfc2616>.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
- May 2002.
+ DOI 10.17487/RFC3282, May 2002,
+ <https://www.rfc-editor.org/info/rfc3282>.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition
- Mechanisms", BCP 66, RFC 3406, October 2002.
+ Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002,
+ <https://www.rfc-editor.org/info/rfc3406>.
[RFC3536] Hoffman, P., "Terminology Used in Internationalization in
- the IETF", RFC 3536, May 2003.
+ the IETF", RFC 3536, DOI 10.17487/RFC3536, May 2003,
+ <https://www.rfc-editor.org/info/rfc3536>.
[RFC4770] Jennings, C. and J. Reschke, Ed., "vCard Extensions for
- Instant Messaging (IM)", RFC 4770, January 2007.
+ Instant Messaging (IM)", RFC 4770, DOI 10.17487/RFC4770,
+ January 2007, <https://www.rfc-editor.org/info/rfc4770>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
- Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
+ Thayer, "OpenPGP Message Format", RFC 4880,
+ DOI 10.17487/RFC4880, November 2007,
+ <https://www.rfc-editor.org/info/rfc4880>.
[RFC5335bis]
- Yang, A. and S. Steele, "Internationalized Email Headers",
- Work in Progress, July 2011.
+ Yang, A., Ed., "Internationalized Email Headers",
+ RFC 5335, September 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
- Specification", RFC 5751, January 2010.
+ Specification", RFC 5751, DOI 10.17487/RFC5751, January
+ 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
- URI Scheme", RFC 6068, October 2010.
+ URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
+ <https://www.rfc-editor.org/info/rfc6068>.
- [TZ-DB] Olson, A., "Time zone code and data",
+ [TZ-DB] Olson, A., "Time zone code and data", August 2011,
<ftp://elsie.nci.nih.gov/pub/>.
[vCard21] Internet Mail Consortium, "vCard - The Electronic Business
@@ -3369,5 +3415,4 @@
URI: http://www.viagenie.ca
Perreault Standards Track [Page 74]
-
# ./spec/asciidoctor/rfc/v2/text_spec.rb:37:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
2) Asciidoctor::RFC::V2::Converter processes Davies template with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/davies-template-bare-06.xml.orig.txt"))).to eq(norm(File.read("spec/examples/davies-template-bare-06.xml.txt")))
expected: "\n\n\n\nInternet Engineering Task Force E. Davies, Ed.\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nDavies Expires October 3, 2010 [Page 8]\n"
got: "\n\n\n\nInternet Engineering Task Force E. Davies, Ed.\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nDavies Expires October 3, 2010 [Page 8]\n"
(compared using ==)
Diff:
@@ -146,8 +146,8 @@
.. are very similar to figures:
- Tables use ttcol to define column headers and widths. Every cell
- then has a "c" element for its content.
+ Tables use ttcol to define column headers and widths. Every cell
+ then has a "c" element for its content.
+----------+----------+
| ttcol #1 | ttcol #2 |
@@ -157,9 +157,9 @@
| c #5 | c #6 |
+----------+----------+
- Table 1: A Very Simple Table
+ which is a very simple example.
- which is a very simple example.
+ Table 1: A Very Simple Table
# ./spec/asciidoctor/rfc/v2/text_spec.rb:42:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
3) Asciidoctor::RFC::V2::Converter processes MIB template with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/mib-doc-template-xml-06.xml.orig.txt"))).to eq(norm(File.read("spec/examples/mib-doc-template-xml-06.xml.txt")))
expected: "\n\n\n\nInternet Engineering Task Force Y. name, Ed.\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nname Expires July 4, 2008 [Page 12]\n"
got: "\n\n\n\nInternet Engineering Task Force Y. Name, Ed.\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nName Expires July 4, 2008 [Page 12]\n"
(compared using ==)
Diff:
@@ -2,7 +2,7 @@
-Internet Engineering Task Force Y. name, Ed.
+Internet Engineering Task Force Y. Name, Ed.
Internet-Draft Editor affiliation
Intended status: Historic January 1, 2008
Expires: July 4, 2008
@@ -13,8 +13,6 @@
Abstract
- (In RFC XML v2, an absract cannot begin with a note!)
-
[[CREF1: This template is for authors of IETF specifications
containing MIB modules. This template can be used as a starting
point to produce specifications that comply with the Operations &
@@ -53,14 +51,16 @@
-name Expires July 4, 2008 [Page 1]
+
+
+Name Expires July 4, 2008 [Page 1]
Internet-Draft Your MIB Module document name January 2008
For information on writing internet drafts or RFCs, see
- <http://www.ietf.org/ietf/1id-guidelines.txt> and RFC2223(bis)
- [RFC2223], and look at <http://www.ietf.org/ID-Checklist.html> for
+ http://www.ietf.org/ietf/1id-guidelines.txt and RFC2223(bis)
+ [RFC2223], and look at http://www.ietf.org/ID-Checklist.html for
issues to note when writing drafts.
This template is not meant to be a complete list of everything needed
@@ -77,7 +77,7 @@
An XML2RFC template is also available. For information on XML2RFC,
see RFC2629 [RFC2629], and documentation available at
- <http://xml.resource.org>. The XML2RFC version includes advice
+ http://xml.resource.org. The XML2RFC version includes advice
describing how to fill in each section of the template. XML2RFC
generates the actual internet-draft from your information, and
automatically handles getting up-to-date boilerplates, references,
@@ -109,7 +109,7 @@
-name Expires July 4, 2008 [Page 2]
+Name Expires July 4, 2008 [Page 2]
Internet-Draft Your MIB Module document name January 2008
@@ -165,7 +165,7 @@
-name Expires July 4, 2008 [Page 3]
+Name Expires July 4, 2008 [Page 3]
Internet-Draft Your MIB Module document name January 2008
@@ -221,7 +221,7 @@
-name Expires July 4, 2008 [Page 4]
+Name Expires July 4, 2008 [Page 4]
Internet-Draft Your MIB Module document name January 2008
@@ -277,7 +277,7 @@
-name Expires July 4, 2008 [Page 5]
+Name Expires July 4, 2008 [Page 5]
Internet-Draft Your MIB Module document name January 2008
@@ -333,7 +333,7 @@
-name Expires July 4, 2008 [Page 6]
+Name Expires July 4, 2008 [Page 6]
Internet-Draft Your MIB Module document name January 2008
@@ -389,7 +389,7 @@
-name Expires July 4, 2008 [Page 7]
+Name Expires July 4, 2008 [Page 7]
Internet-Draft Your MIB Module document name January 2008
@@ -445,7 +445,7 @@
-name Expires July 4, 2008 [Page 8]
+Name Expires July 4, 2008 [Page 8]
Internet-Draft Your MIB Module document name January 2008
@@ -453,9 +453,9 @@
9. IANA Considerations
[[CREF22: [TEMPLATE TODO] In order to comply with IESG policy as set
- forth in <http://www.ietf.org/ID-Checklist.html>, every Internet-
- Draft that is submitted to the IESG for publication MUST contain an
- IANA Considerations section. The requirements for this section vary
+ forth in http://www.ietf.org/ID-Checklist.html, every Internet-Draft
+ that is submitted to the IESG for publication MUST contain an IANA
+ Considerations section. The requirements for this section vary
depending what actions are required of the IANA. See "Guidelines for
Writing an IANA Considerations Section in RFCs" [RFC2434]. and see
RFC4181 section 3.5 for more information on writing an IANA clause
@@ -501,7 +501,7 @@
-name Expires July 4, 2008 [Page 9]
+Name Expires July 4, 2008 [Page 9]
Internet-Draft Your MIB Module document name January 2008
@@ -557,7 +557,7 @@
-name Expires July 4, 2008 [Page 10]
+Name Expires July 4, 2008 [Page 10]
Internet-Draft Your MIB Module document name January 2008
@@ -613,7 +613,7 @@
-name Expires July 4, 2008 [Page 11]
+Name Expires July 4, 2008 [Page 11]
Internet-Draft Your MIB Module document name January 2008
@@ -669,5 +669,5 @@
-name Expires July 4, 2008 [Page 12]
+Name Expires July 4, 2008 [Page 12]
# ./spec/asciidoctor/rfc/v2/text_spec.rb:47:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
4) Asciidoctor::RFC::V2::Converter processes rfc1149 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc1149.md.2.xml.txt"))).to eq(norm(File.read("spec/examples/rfc1149.md.xml.txt")))
expected: "\n\n\n\nNetwork D. Waitzman\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nWaitzman Expires October 3, 1990 [Page 3]\n"
got: "\n\n\n\nNetwork Working Group D. Waitzman\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nWaitzman Expires October 3, 1990 [Page 3]\n"
(compared using ==)
Diff:
@@ -2,7 +2,7 @@
-Network D. Waitzman
+Network Working Group D. Waitzman
Internet-Draft BBN STC
Intended status: Informational April 1, 1990
Expires: October 3, 1990
# ./spec/asciidoctor/rfc/v2/text_spec.rb:53:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
5) Asciidoctor::RFC::V2::Converter processes rfc2100 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc2100.md.2.xml.txt"))).to eq(norm(File.read("spec/examples/rfc2100.md.xml.txt")))
expected: "\n\n\n\nNetwork J. Ashworth\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nAshworth Expires October 3, 1997 [Page 3]\n"
got: "\n\n\n\nNetwork Working Group J. Ashworth\nInternet-Draft ...lib.fl.us\n\n\n\n\n\n\n\nAshworth Expires October 3, 1997 [Page 3]\n"
(compared using ==)
Diff:
@@ -2,7 +2,7 @@
-Network J. Ashworth
+Network Working Group J. Ashworth
Internet-Draft Ashworth & Associates
Intended status: Informational April 1, 1997
Expires: October 3, 1997
@@ -67,53 +67,65 @@
2. Poetry
The Naming of Hosts is a difficult matter,
- It isn't just one of your holiday games;
+ It isn't just one of your holiday games;
You may think at first I'm as mad as a hatter
- When I tell you, a host must have THREE DIFFERENT NAMES.
+ When I tell you, a host must have THREE DIFFERENT NAMES.
+
First of all, there's the name that the users use daily,
- Such as venus, athena, and cisco, and ames,
+ Such as venus, athena, and cisco, and ames,
Such as titan or sirius, hobbes or europa--
- All of them sensible everyday names.
+ All of them sensible everyday names.
+
There are fancier names if you think they sound sweeter,
- Some for the web pages, some for the flames:
+ Some for the web pages, some for the flames:
Such as mercury, phoenix, orion, and charon--
- But all of them sensible everyday names.
+ But all of them sensible everyday names.
+
But I tell you, a host needs a name that's particular,
- A name that's peculiar, and more dignified,
+ A name that's peculiar, and more dignified,
Else how can it keep its home page perpendicular,
- And spread out its data, send pages world wide?
+ And spread out its data, send pages world wide?
+
Of names of this kind, I can give you a quorum,
- Like lothlorien, pothole, or kobyashi-maru,
+ Like lothlorien, pothole, or kobyashi-maru,
Such as pearly-gates.vatican, or else diplomatic-
- Names that never belong to more than one host.
+ Names that never belong to more than one host.
+
But above and beyond there's still one name left over,
- And that is the name that you never will guess;
+ And that is the name that you never will guess;
The name that no human research can discover--
- But THE NAMESERVER KNOWS, and will us'ually confess.
+ But THE NAMESERVER KNOWS, and will us'ually confess.
+
When you notice a client in rapt meditation,
- The reason, I tell you, is always the same:
+ The reason, I tell you, is always the same:
The code is engaged in a deep consultation
- On the address, the address, the address of its name:
- It's ineffable,
- effable,
- Effanineffable,
- Deep and inscrutable,
- singular
- Name.
+ On the address, the address, the address of its name:
-3. Credits
- Thanks to Don Libes, Mark Lottor, and a host of twisted
- individuals^W^Wcreative sysadmins for providing source material for
- this memo, to Andrew Lloyd-Webber, Cameron Mackintosh, and a cast of
+
+
+
+
Ashworth Expires October 3, 1997 [Page 2]
Internet-Draft The Naming of Hosts April 1997
+ It's ineffable,
+ effable,
+ Effanineffable,
+ Deep and inscrutable,
+ singular
+ Name.
+
+3. Credits
+
+ Thanks to Don Libes, Mark Lottor, and a host of twisted
+ individuals^W^Wcreative sysadmins for providing source material for
+ this memo, to Andrew Lloyd-Webber, Cameron Mackintosh, and a cast of
thousands (particularly including Terrance Mann) who drew my
attention to the necessity, and of course, to Thomas Stearns Eliot,
for making this all necessary.
@@ -146,18 +158,6 @@
Phone: +1 813 790 7592
Email: [email protected]
-
-
-
-
-
-
-
-
-
-
-
-
# ./spec/asciidoctor/rfc/v2/text_spec.rb:59:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
6) Asciidoctor::RFC::V2::Converter processes rfc3514 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc3514.md.2.xml.txt"))).to eq(norm(File.read("spec/examples/rfc3514.md.xml.txt")))
expected: "\n\n\n\nNetwork S. Bellovin\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nBellovin Expires October 3, 2003 [Page 6]\n"
got: "\n\n\n\nNetwork Working Group S. Bellovin\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nBellovin Expires October 3, 2003 [Page 6]\n"
(compared using ==)
Diff:
@@ -2,7 +2,7 @@
-Network S. Bellovin
+Network Working Group S. Bellovin
Internet-Draft AT&T Labs Research
Intended status: Informational April 1, 2003
Expires: October 3, 2003
@@ -132,7 +132,7 @@
Multi-level insecure operating systems may have special levels for
attack programs; the evil bit MUST be set by default on packets
emanating from programs running at such levels. However, the system
- MAY provide an API to allow it to be cleared for non-malicious
+ _MAY_ provide an API to allow it to be cleared for non-malicious
activity by users who normally engage in attack behavior.
Fragments that by themselves are dangerous MUST have the evil bit
# ./spec/asciidoctor/rfc/v2/text_spec.rb:65:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
7) Asciidoctor::RFC::V2::Converter processes rfc5841 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc5841.md.2.xml.txt"))).to eq(norm(File.read("spec/examples/rfc5841.md.xml.txt")))
expected: "\n\n\n\nNetwork R. Hay\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nHay & Turkal Expires October 3, 2010 [Page 9]\n"
got: "\n\n\n\nNetwork Working Group R. Hay\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nHay & Turkal Expires October 3, 2010 [Page 9]\n"
(compared using ==)
Diff:
@@ -2,7 +2,7 @@
-Network R. Hay
+Network Working Group R. Hay
Internet-Draft W. Turkal
Intended status: Informational Google
Expires: October 3, 2010 April 1, 2010
# ./spec/asciidoctor/rfc/v2/text_spec.rb:71:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
8) Asciidoctor::RFC::V2::Converter processes rfc748 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc748.md.2.xml.txt"))).to eq(norm(File.read("spec/examples/rfc748.md.xml.txt")))
expected: "\n\n\n\nNetwork M. Crispin\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nCrispin Expires October 3, 1978 [Page 3]\n"
got: "\n\n\n\nNetwork Working Group M. Crispin\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nCrispin Expires October 3, 1978 [Page 3]\n"
(compared using ==)
Diff:
@@ -2,7 +2,7 @@
-Network M. Crispin
+Network Working Group M. Crispin
Internet-Draft SU-AI
Intended status: Informational April 1, 1978
Expires: October 3, 1978
@@ -69,7 +69,7 @@
1. Command name and code
- RANDOMLY-LOSE 256
+ RANDOMLY-LOSE 256
2. Command meanings
# ./spec/asciidoctor/rfc/v2/text_spec.rb:77:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
9) Asciidoctor::RFC::V2::Converter processes rfc7511 from Markdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/rfc7511.md.2.xml.txt"))).to eq(norm(File.read("spec/examples/rfc7511.md.xml.txt")))
expected: "\n\n\n\nNetwork M. Wilhelm\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nWilhelm Expires October 3, 2015 [Page 8]\n"
got: "\n\n\n\nNetwork Working Group M. Wilhelm\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nWilhelm Expires October 3, 2015 [Page 8]\n"
(compared using ==)
Diff:
@@ -2,7 +2,7 @@
-Network M. Wilhelm
+Network Working Group M. Wilhelm
Internet-Draft April 1, 2015
Intended status: Informational
Expires: October 3, 2015
@@ -67,15 +67,15 @@
3. Implications . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Routing Implications . . . . . . . . . . . . . . . . . . 5
3.2. Implications for Hosts . . . . . . . . . . . . . . . . . 5
- 3.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
- Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
@@ -135,15 +135,15 @@
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 *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 Section 4.2 of [RFC2460].
+ specification in Section 4.2 of RFC 2460 [RFC2460].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
@@ -156,6 +156,7 @@
Figure 1: Scenic Routing Option Layout
Option Type
+
8-bit identifier of the type of option. The option identifier
0x0A (On Air) is proposed for Scenic Routing.
@@ -164,7 +165,6 @@
-
Wilhelm Expires October 3, 2015 [Page 3]
Internet-Draft Scenic Routing for IPv6 April 2015
@@ -175,6 +175,7 @@
0A 00 0 01010 Scenic Routing
Figure 2: Scenic Routing Option Type
+
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
@@ -182,11 +183,13 @@
final destination.
Option Length
+
8-bit unsigned integer. The length of the option in octets
(excluding the Option Type and Option Length fields). The value
MUST be greater than 0.
SRO Param
+
8-bit identifier indicating Scenic Routing parameters encoded as a
bit string.
@@ -195,6 +198,7 @@
+-+-+-+-+-+-+-+-+
Figure 3: SRO Param Bit String Layout
+
The highest-order two bits (SR) define the urgency of Scenic
Routing:
@@ -205,27 +209,30 @@
10 - Scenic Routing SHOULD be used for this packet.
11 - Scenic Routing MUST be used for this packet.
+
The following BIT (A) defines if Avian IP Carriers should be used:
0 - Don't use Avian IP Carrier links (maybe the packet is
afraid of pigeons).
1 - Avian IP Carrier links may be used.
+
The following BIT (W) defines if wireless links should be used:
- 0 - Don't use wireless links (maybe the packet is afraid of
- radiation).
- 1 - Wireless links may be used.
- The following two bits (AA) define the affinity for link types:
-
-
Wilhelm Expires October 3, 2015 [Page 4]
Internet-Draft Scenic Routing for IPv6 April 2015
+ 0 - Don't use wireless links (maybe the packet is afraid of
+ radiation).
+
+ 1 - Wireless links may be used.
+
+ The following two bits (AA) define the affinity for link types:
+
00 - No affinity.
01 - Avian IP Carriers SHOULD be preferred.
@@ -233,6 +240,7 @@
10 - Wireless links SHOULD be preferred.
11 - RESERVED
+
The lowest-order two bits (XY) are currently unused and reserved
for future use.
@@ -265,6 +273,15 @@
System administrators *MIGHT* want to configure sensible default
parameters for Scenic Routing, when Scenic Routing has been widely
+
+
+
+
+Wilhelm Expires October 3, 2015 [Page 5]
+
+Internet-Draft Scenic Routing for IPv6 April 2015
+
+
adopted by operating systems. System administrators SHOULD deploy
Scenic Routing information where applicable.
@@ -275,13 +292,6 @@
same SRO Params on the outgoing packet as seen on the incoming
packet.
-
-
-Wilhelm Expires October 3, 2015 [Page 5]
-
-Internet-Draft Scenic Routing for IPv6 April 2015
-
-
Developers *SHOULD CONSIDER* Scenic Routing when designing and
implementing any network service.
@@ -319,25 +329,22 @@
algorithms could easily calculate the optimal paths providing the
most fresh-air time for a packet for any given destination.
- This would even allow preference for wireless paths going alongside
- popular or culturally important places. This way, the packets don't
- only avoid the dark fibers, but they get to see the world outside of
- the Internet and are exposed to different cultures around the globe,
- which may help build an understanding of cultural differences and
- promote acceptance of these differences.
-
-
-
-
Wilhelm Expires October 3, 2015 [Page 6]
Internet-Draft Scenic Routing for IPv6 April 2015
+ This would even allow preference for wireless paths going alongside
+ popular or culturally important places. This way, the packets don't
+ only avoid the dark fibers, but they get to see the world outside of
+ the Internet and are exposed to different cultures around the globe,
+ which may help build an understanding of cultural differences and
+ promote acceptance of these differences.
+
7. References
7.1. Normative References
@@ -375,38 +382,31 @@
DOI 10.17487/RFC1149, April 1990,
<https://www.rfc-editor.org/info/rfc1149>.
-Appendix A. Acknowledgements
- The author wishes to thank all those poor friends who were kindly
- forced to read this document and that provided some nifty comments.
-Author's Address
-
-
-
Wilhelm Expires October 3, 2015 [Page 7]
Internet-Draft Scenic Routing for IPv6 April 2015
+Appendix A. Acknowledgements
+
+ The author wishes to thank all those poor friends who were kindly
+ forced to read this document and that provided some nifty comments.
+
+Author's Address
+
Maximilian Wilhelm
Paderborn, NRW
Germany
Phone: +49 176 62 05 94 27
Email: [email protected]
-
-
-
-
-
-
-
# ./spec/asciidoctor/rfc/v2/text_spec.rb:83:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
10) Asciidoctor::RFC::V2::Converter processes draft-ietf-core-block-xx from Kramdown with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/draft-ietf-core-block-xx.xml.orig.txt"))).to eq(norm(File.read("spec/examples/draft-ietf-core-block-xx.mkd.xml.txt")))
expected: "\n\n\n\nCoRE C. Bormann\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nBormann & Shelby Expires July 16, 2012 [Page 21]\n"
got: "\n\n\n\nCoRE Working Group C. Bormann\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nBormann & Shelby Expires July 16, 2012 [Page 21]\n"
(compared using ==)
Diff:
@@ -2,7 +2,7 @@
-CoRE C. Bormann
+CoRE Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track Z. Shelby, Ed.
Expires: July 16, 2012 Sensinode
@@ -144,8 +144,8 @@
lower layers with conversation state that is better managed in the
application layer.
- This specification defines a pair of CoAP options to enable *block-
- wise* access to resource representations. The Block options provide
+ This specification defines a pair of CoAP options to enable _block-
+ wise_ access to resource representations. The Block options provide
a minimal way to transfer larger resource representations in a block-
wise fashion. The overriding objective is to avoid creating
conversation state at the server for block-wise GET requests. (It is
@@ -247,6 +247,7 @@
| Type | C/E | Name | Format | Length | Default |
+------+----------+--------+--------+--------+---------------+
| 19 | Critical | Block1 | uint | 1-3 B | 0 (see below) |
+ | | | | | | |
| 17 | Critical | Block2 | uint | 1-3 B | 0 (see below) |
+------+----------+--------+--------+--------+---------------+
@@ -276,7 +277,6 @@
-
Bormann & Shelby Expires July 16, 2012 [Page 5]
Internet-Draft Blockwise transfers in CoAP January 2012
@@ -932,12 +932,13 @@
This draft adds the following option numbers to the CoAP Option
Numbers registry of [I-D.ietf-core-coap]:
- +--------+--------+------------+
- | Number | Name | Reference |
- +--------+--------+------------+
- | 17 | Block2 | [RFCXXXX] |
- | 19 | Block1 | [RFCXXXX] |
- +--------+--------+------------+
+ +--------+--------+-----------+
+ | Number | Name | Reference |
+ +--------+--------+-----------+
+ | 17 | Block2 | [RFCXXXX] |
+ | | | |
+ | 19 | Block1 | [RFCXXXX] |
+ +--------+--------+-----------+
Table 2: CoAP Option Numbers
@@ -948,17 +949,16 @@
-
Bormann & Shelby Expires July 16, 2012 [Page 17]
Internet-Draft Blockwise transfers in CoAP January 2012
- +------+--------------------------------+------------+
- | Code | Description | Reference |
- +------+--------------------------------+------------+
- | 136 | 4.08 Request Entity Incomplete | [RFCXXXX] |
- +------+--------------------------------+------------+
+ +------+--------------------------------+-----------+
+ | Code | Description | Reference |
+ +------+--------------------------------+-----------+
+ | 136 | 4.08 Request Entity Incomplete | [RFCXXXX] |
+ +------+--------------------------------+-----------+
Table 3: CoAP Response Codes
@@ -1077,11 +1077,6 @@
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
- [RFCXXXX] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
- the Constrained Application Protocol (CoAP)", RFC 7959,
- DOI 10.17487/RFC7959, August 2016,
- <https://www.rfc-editor.org/info/rfc7959>.
-
8.2. Informative References
[REST] Fielding, R., "Architectural Styles and the Design of
@@ -1114,6 +1109,11 @@
Phone: +49-421-218-63921
Fax: +49-421-218-7000
Email: [email protected]
+
+
+
+
+
# ./spec/asciidoctor/rfc/v2/text_spec.rb:89:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
11) Asciidoctor::RFC::V2::Converter processes skel from Kramdown with equivalent text
Failure/Error: expect(File.read("spec/examples/skel.xml.orig.txt")).to eq(File.read("spec/examples/skel.mkd.xml.txt"))
expected: "\n\n\n\nNetwork Working Group C. Bormann\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nBormann Expires May 7, 2018 [Page 2]\n"
got: "\n\n\n\nNetwork Working Group C. Bormann\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nBormann Expires May 7, 2018 [Page 2]\n"
(compared using ==)
Diff:
@@ -4,7 +4,7 @@
Network Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
-Intended status: Informational November 3, 2017
+Intended status: Informational November 03, 2017
Expires: May 7, 2018
# ./spec/asciidoctor/rfc/v2/text_spec.rb:95:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
12) Asciidoctor::RFC::V2::Converter processes stupid-s from Kramdown with equivalent text
Failure/Error: expect(File.read("spec/examples/stupid-s.xml.orig.txt")).to eq(File.read("spec/examples/stupid-s.mkd.xml.txt"))
expected: "\n\n\n\nXMPP K. Hartke\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nHartke & Bormann Expires January 6, 2010 [Page 14]\n"
got: "\n\n\n\nXMPP Working Group K. Hartke\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nHartke & Bormann Expires January 6, 2010 [Page 14]\n"
(compared using ==)
Diff:
@@ -2,10 +2,10 @@
-XMPP K. Hartke
+XMPP Working Group K. Hartke
Internet-Draft C. Bormann
Intended status: Informational Universitaet Bremen TZI
-Expires: January 6, 2010 July 5, 2009
+Expires: January 6, 2010 July 05, 2009
STUN/TURN using PHP in Despair
@@ -624,7 +624,7 @@
channel.
The notification protocol is closely modeled after XMPP's In-Band
- Bytestreams (IBB, see <http://xmpp.org/extensions/xep-0047.html>).
+ Bytestreams (IBB, see 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 Figure 8. (Note that
the current proposal redundantly sends a sid and a seq as well as the
@@ -638,11 +638,11 @@
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>)
+ invalid. (Adapted from 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>).
+ Jingle (see http://xmpp.org/extensions/xep-0261.html).
<iq from='[email protected]/orchard'
id='jn3h8g65'
# ./spec/asciidoctor/rfc/v2/text_spec.rb:101:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
13) Asciidoctor::RFC::V2::Converter processes Hoffman RFC XML v2 example with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/hoffmanv2.xml.orig.txt"))).to eq(norm(File.read("spec/examples/hoffmanv2.xml.xml.txt")))
expected: "\n\n\n\nImaginary WG C. Smith\nInternet-Draft ...n\n\n\n\n\n\n\n\n\n\n\n\nSmith & Jones Expires March 5, 2015 [Page 5]\n"
got: "\n\n\n\nImaginary WG C. Smith\nInternet-Draft ... Email: [email protected]\n\n\n\nSmith & Jones Expires March 5, 2015 [Page 5]\n"
(compared using ==)
Diff:
@@ -97,34 +97,40 @@
Bulleted lists are good for items that are not ordered:
o This is the first item.
+
o This is the second item. Here comes a sub-list:
* This is the first sub-item.
+
* This is the second sub-item
and some more detail on the second sub-item.
+
o This is the item after the sub-list.
- Numbered lists are good for items that are ordered:
-
-
Smith & Jones Expires March 5, 2015 [Page 2]
Internet-Draft XML Example September 2014
+ Numbered lists are good for items that are ordered:
+
1. This is the first item.
+
2. This is the second item. Here comes a sub-list, but with
letters:
A. This is the first sub-item.
+
B. This is the second sub-item
+
3. This is the item after the sub-list.
And an example of hanging indent.
Trees These are bigger plants
+
Lichen These are smaller plants
And the always-interesting "format" for lists.
@@ -154,37 +160,38 @@
The following is a table example.
- These are sometimes called "inert" gasses.
-
-
-
-
-
Smith & Jones Expires March 5, 2015 [Page 3]
Internet-Draft XML Example September 2014
- +----------------+--------------------------------+-----------------+
- | Name | Symbol | Atomic Number |
- +----------------+--------------------------------+-----------------+
- | Helium | He | 2 |
- | Neon | Ne | 10 |
- | Argon | Ar | 18 |
- | Krypton | Kr | 36 |
- | Xenon | Xe | 54 |
- | Radon | Rn | 86 |
- +----------------+--------------------------------+-----------------+
+ These are sometimes called "inert" gasses.
- The Noble Gases
+ +---------+--------------------------------+---------------+
+ | Name | Symbol | Atomic Number |
+ +---------+--------------------------------+---------------+
+ | Helium | He | 2 |
+ | | | |
+ | Neon | Ne | 10 |
+ | | | |
+ | Argon | Ar | 18 |
+ | | | |
+ | Krypton | Kr | 36 |
+ | | | |
+ | Xenon | Xe | 54 |
+ | | | |
+ | Radon | Rn | 86 |
+ +---------+--------------------------------+---------------+
- Source: Chemistry 101
+ Source: Chemistry 101
+ The Noble Gases
+
The following is a right-aligned table with "full" (but not "all")
lines between cells.
@@ -192,7 +199,9 @@
| Time | Mood |
+-----------+--------+
| Morning | Happy! |
+ | | |
| Afternoon | Happy! |
+ | | |
| Evening | Somber |
+-----------+--------+
@@ -209,6 +218,14 @@
Some of the things included in this draft came from Elwyn Davies'
templates.
+
+
+
+Smith & Jones Expires March 5, 2015 [Page 4]
+
+Internet-Draft XML Example September 2014
+
+
9. References
9.1. Normative References
@@ -218,14 +235,6 @@
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
-
-
-
-Smith & Jones Expires March 5, 2015 [Page 4]
-
-Internet-Draft XML Example September 2014
-
-
9.2. Informative References
[RED] Floyd, S. and V. Jacobson, "Random Early Detection (RED)
@@ -234,10 +243,10 @@
<http://www.aciri.org/floyd/papers/early.pdf>.
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format
- Requirements and Future Development", RFC 6949,
- DOI 10.17487/RFC6949, May 2013,
- <https://www.rfc-editor.org/info/rfc6949>.
+ Requirements and Future Development", RFC 6949, May 2013.
+ This is a primary reference work.
+
9.3. URIs
[1] http://www.ietf.org
@@ -265,15 +274,6 @@
Kim Jones
Email: [email protected]
-
-
-
-
-
-
-
-
-
# ./spec/asciidoctor/rfc/v2/text_spec.rb:106:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
14) Asciidoctor::RFC::V2::Converter processes draft-iab-html-rfc-bis RFC XML v2 example with equivalent text
Failure/Error: expect(norm(File.read("spec/examples/draft-iab-html-rfc-bis.xml.orig.txt"))).to eq(norm(File.read("spec/examples/draft-iab-html-rfc-bis.xml.xml.txt")))
expected: "\n\n\n\n\n\nInternet Architecture Board (IAB) J. Hildebrand, Ed.\nRequest for [email protected]\n\n\n\n\nHildebrand & Hoffman Informational [Page 41]\n"
got: "\n\n\n\n\n\nInternet Architecture Board (IAB) J. Hildebrand, Ed.\nRequest for Co...n\n\n\n\n\n\n\n\n\n\n\n\nHildebrand & Hoffman Informational [Page 41]\n"
(compared using ==)
Diff:
@@ -193,8 +193,8 @@
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . 40
- Appendix A. Appendix A: IAB Members at the Time of Approval . . 40
- Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 41
+ IAB Members at the Time of Approval . . . . . . . . . . . . . . . 40
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction
@@ -1725,7 +1725,7 @@
<source> element's "anchor" attribute.
<div class="refInstance" id="RFC5730">
- ...
+ ...
</div>
@@ -2174,11 +2174,11 @@
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
RFC 7991, DOI 10.17487/RFC7991, December 2016,
- <https://www.rfc-editor.org/info/rfc7991>.
+ <http://www.rfc-editor.org/info/rfc7991>.
[RFC7993] Flanagan, H., "Cascading Style Sheets (CSS) Requirements
for RFCs", RFC 7993, DOI 10.17487/RFC7993, December 2016,
- <https://www.rfc-editor.org/info/rfc7993>.
+ <http://www.rfc-editor.org/info/rfc7993>.
@@ -2189,17 +2189,17 @@
[W3C.REC-CSS2-20110607]
- Bos, B., A‡elik, T., Hickson, I., and H. Lie,
- "Cascading Style Sheets Level 2 Revision 1 (CSS 2.1)
- Specification", World Wide Web Consortium Recommendation
- REC-CSS2-20110607, June 2011,
+ Bos, B., Celik, T., Hickson, I., and H. Lie, "Cascading
+ Style Sheets Level 2 Revision 1 (CSS 2.1) Specification",
+ World Wide Web Consortium Recommendation REC-
+ CSS2-20110607, June 2011,
<http://www.w3.org/TR/2011/REC-CSS2-20110607>.
[W3C.REC-html5-20141028]
Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
- Navara, E., O'Connor, T., and S. Pfeiffer, "HTML5",
- World Wide Web Consortium Recommendation REC-
- html5-20141028, October 2014,
+ Navara, E., O'Connor, T., and S. Pfeiffer, "HTML5", World
+ Wide Web Consortium Recommendation REC-html5-20141028,
+ October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028>.
11.2. Informative References
@@ -2218,12 +2218,12 @@
[RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990,
DOI 10.17487/RFC7990, December 2016,
- <https://www.rfc-editor.org/info/rfc7990>.
+ <http://www.rfc-editor.org/info/rfc7990>.
[RFC7998] Hoffman, P. and J. Hildebrand, ""xml2rfc" Version 3
Preparation Tool Description", RFC 7998,
DOI 10.17487/RFC7998, December 2016,
- <https://www.rfc-editor.org/info/rfc7998>.
+ <http://www.rfc-editor.org/info/rfc7998>.
[W3C.WD-css3-page-20130314]
Grant, M., Etemad, E., Lie, H., and S. Sapin, "CSS Paged
@@ -2231,7 +2231,7 @@
css3-page-20130314, March 2013,
<http://www.w3.org/TR/2013/WD-css3-page-20130314>.
-Appendix A. Appendix A: IAB Members at the Time of Approval
+IAB Members at the Time of Approval
The IAB members at the time this memo was approved were (in
alphabetical order):
@@ -2244,34 +2244,22 @@
RFC 7992 HTML for RFCs December 2016
- o Jari Arkko
+ Jari Arkko
+ Ralph Droms
+ Ted Hardie
+ Joe Hildebrand
+ Russ Housley
+ Lee Howard
+ Erik Nordmark
+ Robert Sparks
+ Andrew Sullivan
+ Dave Thaler
+ Martin Thomson
+ Brian Trammell
+ Suzanne Woolf
- o Ralph Droms
+Acknowledgments
- o Ted Hardie
-
- o Joe Hildebrand
-
- o Russ Housley
-
- o Lee Howard
-
- o Erik Nordmark
-
- o Robert Sparks
-
- o Andrew Sullivan
-
- o Dave Thaler
-
- o Martin Thomson
-
- o Brian Trammell
-
- o Suzanne Woolf
-
-Appendix B. Acknowledgments
-
Heather Flanangan was an early coauthor of this document and helped
its formation. The authors gratefully acknowledge the contributions
of: Patrick Linskey and the members of the RFC Format Design Team
@@ -2291,6 +2279,18 @@
ICANN
Email: [email protected]
+
+
+
+
+
+
+
+
+
+
+
+
# ./spec/asciidoctor/rfc/v2/text_spec.rb:116:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:118:in `block (2 levels) in <top (required)>'
Finished in 29.83 seconds (files took 0.46839 seconds to load)
15 examples, 14 failures
Failed examples:
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:34 # Asciidoctor::RFC::V2::Converter processes RFC 6350 RFC XML v2 example with bibliography preprocessing, with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:39 # Asciidoctor::RFC::V2::Converter processes Davies template with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:44 # Asciidoctor::RFC::V2::Converter processes MIB template with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:49 # Asciidoctor::RFC::V2::Converter processes rfc1149 from Markdown with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:55 # Asciidoctor::RFC::V2::Converter processes rfc2100 from Markdown with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:61 # Asciidoctor::RFC::V2::Converter processes rfc3514 from Markdown with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:67 # Asciidoctor::RFC::V2::Converter processes rfc5841 from Markdown with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:73 # Asciidoctor::RFC::V2::Converter processes rfc748 from Markdown with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:79 # Asciidoctor::RFC::V2::Converter processes rfc7511 from Markdown with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:85 # Asciidoctor::RFC::V2::Converter processes draft-ietf-core-block-xx from Kramdown with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:91 # Asciidoctor::RFC::V2::Converter processes skel from Kramdown with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:97 # Asciidoctor::RFC::V2::Converter processes stupid-s from Kramdown with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:103 # Asciidoctor::RFC::V2::Converter processes Hoffman RFC XML v2 example with equivalent text
rspec ./spec/asciidoctor/rfc/v2/text_spec.rb:113 # Asciidoctor::RFC::V2::Converter processes draft-iab-html-rfc-bis RFC XML v2 example with equivalent text
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
We now have a new discrepancy between published RFC documents and the gem: they do not strip out "Working Group" from Working Group names. Could you confirm that we should be stripping it out? This looks odd:
Network S. Bellovin
Internet-Draft AT&T Labs Research
Intended status: Informational April 1, 2003
Expires: October 3, 2003
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
Re dates: in fact, it's the published specs that are inconsistently adding leading zeros on their dates, not the gem.
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
Done some tweaks to rspec, but a lot of these have resisted patching up.
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
-
We should keep the "Working Group", maybe use preprocessing to scrub them before testing equivalence. For example, this one gives out "Network Working Group" (https://tools.ietf.org/id/draft-iab-xml2rfc-04.txt). However, published RFC (not Internet-Draft) does not show the "Working Group" at all, e.g., (https://tools.ietf.org/html/rfc7991).
-
Dates, perhaps we could also preprocess them away. We don't want to spec the differences between xml2rfc versions.
-
Maybe we should find a way to patch those specs so that they all pass now, and future changes will alert us of future problems.
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
"Working Group": I'll issue a warning: "suffix Working Group will be stripped in published RFC".
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
@opoudjis re: Working Group, I've run into another issue regarding IRTF documents.
Technically, "IRTF" documents should have "submission-type" "IRTF", and "workgroup" the name of an IRTF working group. However, the list of working groups now don't include them.
IRTF Groups can be found here: https://irtf.org/groups . We should accept abbreviations and also the full names of them.
Update: Moved to #89
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
Mitigated, down to 7 docs with issues from 12.
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
Awesome. The other part of the failures on Travis stem from:
No such file or directory @ rb_sysopen - spec/examples/rfc6350.xml.txt.1
I feel that this is because of the lack of xml2rfc installed?
Update: yes, xml2rfc is not installed. We should install them like this:
https://github.com/riboseinc/rfc-openpgp-sca/blob/master/.travis.yml
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
Rspec is now running, which it didn't seem to be doing before the way I was reading it. I think some of the intractable files, I will just have to remove from rspec, but let's leave this ticket open.
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
I will take 6350 out; it's just more trouble than it's worth in the RSpec context, and the points it was seeking to prove have been proven elsewhere.
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
Patching the remainder one file at a time, emending their XML to match.
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
Down to 1
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
Oh my, you're a magician 😉
The remaining one is interesting regarding the "Appendix" bits (and the list). Our gem is doing better than the original which scrambles up the accents!
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
In retrospect: a lot of these were me insisting on the "right" way of marking them up rather than the way they actually marked them up. The last one actually uses illegal v3 attributes in a v2 context, and I've also had to deal with preambles/postambles, which are impossible in Asciidoc for tables, and idiosyncractic additions of blank lines in definition lists.
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
The problem appears to be with UTF-8 being mangled on https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.REC-CSS2-20110607.xml . I can't change the encoding on that page to do anything reasonable with Çelik or Håkon. This needs to be brought to the attention of the IETF: @ronaldtse ?
The fact that the XML output is deliberately in US-ASCII (to force UTF-8 characters to be output as entities) will get in the way of UTF-8 includes; but these are not in UTF-8; they are corrupted out of the box.
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
In fact (to their shame) the original file dealt with this by simply stripping the diacritics from the reference. I will sidestep this by using a non-canonical anchor for the reference; but this is a bug on the IETF's side, and they need to fix it.
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
In addition, bug report for xml2rfc: it is not dealing with the ' in <author initials="T." surname="O'Connor" fullname="Theresa O'Connor"> in https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.REC-html5-20141028.xml . It is fine with the XML including the reference, it's not with the include.
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
All rspec issues patched, but waiting on word about the https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/ encoding issues.
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
@opoudjis agree we should report the BibXML encoding issue to the IETF, but at this point it's not very clear who is actually responsible for them. Let me try to find out.
In our specs, we can temporarily hide this issue using "pending" first, with an issue to re-enable it later?
from asciidoctor-rfc.
opoudjis
commented on July 30, 2024
Spec is hiding it with a patch, but I will put an issue in to reenable.
from asciidoctor-rfc.
ronaldtse
commented on July 30, 2024
@opoudjis let's close this then since the specs are passing 👍
from asciidoctor-rfc.
Related Issues (20)
- Render RFC references HOT 8
- Warn if section after appendix not marked up as appendix HOT 8
- In RFC style, backticks should be presented as double quotes HOT 7
- Tests failed on windows HOT 2
- AsciiRFC Internet-Draft bug HOT 2
- RELAXNG validation error: <eref> inside <spanx> HOT 4
- Extract references as entities HOT 7
- Line numbers / file path missing in WARNING messages HOT 3
- Uncertainty in allowed values of <workgroup> and <area> HOT 4
- Inconsistent behavior of `[source]` block without figure wrapper in v3/v2 HOT 3
- Asciidoctor-biblio workaround HOT 11
- Canonical references have dots HOT 1
- Add xml-stylesheet `rfc2629.xslt` HOT 2
- Handling IRTF Working Groups HOT 1
- Referencing the latest I-D BibXML causes resulting ENTITY to lose link HOT 2
- CR before literal/sourcecode HOT 5
- Automatic section referencing overrides explicit references HOT 8
- Test errors HOT 1
- `NOT RECOMMENDED` should be labeled as `<bcp14>`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asciidoctor-rfc.