pkg apg ver 2.2.3-4 lastfile apg_2.2.3.orig.tar.gz files apg-2.2.3/doc/rfc0972.txt apg-2.2.3/doc/rfc1750.txt tar xfz /data/debian/pool/main/a/apg/apg_2.2.3.orig.tar.gz apg-2.2.3/doc/rfc0972.txt 701c7252476b49582ea7fab5ad965f20 - apg-2.2.3/doc/rfc0972.txt 701c7252476b49582ea7fab5ad965f20 - /home/jas/rfc/rfc972.txt MATCH rfc972.txt tar xfz /data/debian/pool/main/a/apg/apg_2.2.3.orig.tar.gz apg-2.2.3/doc/rfc1750.txt b7b57294f70ad60acc936f606365558c - apg-2.2.3/doc/rfc1750.txt b7b57294f70ad60acc936f606365558c - /home/jas/rfc/rfc1750.txt MATCH rfc1750.txt pkg asn1c ver 0.9.21-2 lastfile asn1c_0.9.21.orig.tar.gz files asn1c-0.9.21/samples/rfc3280.txt asn1c-0.9.21/samples/rfc3525.txt asn1c-0.9.21/samples/rfc4511.txt tar xfz /data/debian/pool/main/a/asn1c/asn1c_0.9.21.orig.tar.gz asn1c-0.9.21/samples/rfc3280.txt 30f39bebcdf2a03933a24356184e5ce7 - asn1c-0.9.21/samples/rfc3280.txt 30f39bebcdf2a03933a24356184e5ce7 - /home/jas/rfc/rfc3280.txt MATCH rfc3280.txt tar xfz /data/debian/pool/main/a/asn1c/asn1c_0.9.21.orig.tar.gz asn1c-0.9.21/samples/rfc3525.txt 3de5e8aef94e4e426663c6d8065c9287 - asn1c-0.9.21/samples/rfc3525.txt 3de5e8aef94e4e426663c6d8065c9287 - /home/jas/rfc/rfc3525.txt MATCH rfc3525.txt tar xfz /data/debian/pool/main/a/asn1c/asn1c_0.9.21.orig.tar.gz asn1c-0.9.21/samples/rfc4511.txt c749bb76c4ca7c6834d558405d2801d1 - asn1c-0.9.21/samples/rfc4511.txt c749bb76c4ca7c6834d558405d2801d1 - /home/jas/rfc/rfc4511.txt MATCH rfc4511.txt pkg bincimap ver 1.2.14beta2-1 lastfile bincimap_1.2.14beta2.orig.tar.gz files bincimap-1.2.14beta2.orig/doc/rfc1341.txt bincimap-1.2.14beta2.orig/doc/rfc1731.txt bincimap-1.2.14beta2.orig/doc/rfc1732.txt bincimap-1.2.14beta2.orig/doc/rfc1733.txt bincimap-1.2.14beta2.orig/doc/rfc2060.txt bincimap-1.2.14beta2.orig/doc/rfc2061.txt bincimap-1.2.14beta2.orig/doc/rfc2086.txt bincimap-1.2.14beta2.orig/doc/rfc2087.txt bincimap-1.2.14beta2.orig/doc/rfc2088.txt bincimap-1.2.14beta2.orig/doc/rfc2095.txt bincimap-1.2.14beta2.orig/doc/rfc2177.txt bincimap-1.2.14beta2.orig/doc/rfc2180.txt bincimap-1.2.14beta2.orig/doc/rfc2192.txt bincimap-1.2.14beta2.orig/doc/rfc2193.txt bincimap-1.2.14beta2.orig/doc/rfc2195.txt bincimap-1.2.14beta2.orig/doc/rfc2221.txt bincimap-1.2.14beta2.orig/doc/rfc2342.txt bincimap-1.2.14beta2.orig/doc/rfc2359.txt bincimap-1.2.14beta2.orig/doc/rfc2595.txt bincimap-1.2.14beta2.orig/doc/rfc2683.txt bincimap-1.2.14beta2.orig/doc/rfc2971.txt bincimap-1.2.14beta2.orig/doc/rfc3028.txt bincimap-1.2.14beta2.orig/doc/rfc3348.txt bincimap-1.2.14beta2.orig/doc/rfc3501.txt bincimap-1.2.14beta2.orig/doc/rfc3502.txt bincimap-1.2.14beta2.orig/doc/rfc3503.txt bincimap-1.2.14beta2.orig/doc/rfc3516.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc1341.txt c657f5aee9aac7749042f01e645133dd - bincimap-1.2.14beta2.orig/doc/rfc1341.txt c657f5aee9aac7749042f01e645133dd - /home/jas/rfc/rfc1341.txt MATCH rfc1341.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc1731.txt 82e7bb0077d0706b495ac512ea400bc1 - bincimap-1.2.14beta2.orig/doc/rfc1731.txt 82e7bb0077d0706b495ac512ea400bc1 - /home/jas/rfc/rfc1731.txt MATCH rfc1731.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc1732.txt 13e7b39d5ba6e1903c83b256ba067089 - bincimap-1.2.14beta2.orig/doc/rfc1732.txt 13e7b39d5ba6e1903c83b256ba067089 - /home/jas/rfc/rfc1732.txt MATCH rfc1732.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc1733.txt aa25bfe07e80e37534e117978de55146 - bincimap-1.2.14beta2.orig/doc/rfc1733.txt aa25bfe07e80e37534e117978de55146 - /home/jas/rfc/rfc1733.txt MATCH rfc1733.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2060.txt 33c14a58e84b863682c318af9f62fc4a - bincimap-1.2.14beta2.orig/doc/rfc2060.txt 33c14a58e84b863682c318af9f62fc4a - /home/jas/rfc/rfc2060.txt MATCH rfc2060.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2061.txt e9d1774f7e95ec54c33929a889565ad0 - bincimap-1.2.14beta2.orig/doc/rfc2061.txt e9d1774f7e95ec54c33929a889565ad0 - /home/jas/rfc/rfc2061.txt MATCH rfc2061.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2086.txt 08dd84b0546b917ce316baf3021a9dbf - bincimap-1.2.14beta2.orig/doc/rfc2086.txt 08dd84b0546b917ce316baf3021a9dbf - /home/jas/rfc/rfc2086.txt MATCH rfc2086.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2087.txt dd611be0081bdd93af0136d030131a05 - bincimap-1.2.14beta2.orig/doc/rfc2087.txt dd611be0081bdd93af0136d030131a05 - /home/jas/rfc/rfc2087.txt MATCH rfc2087.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2088.txt 396b3b410f45da9b98932fefb1f49da5 - bincimap-1.2.14beta2.orig/doc/rfc2088.txt 396b3b410f45da9b98932fefb1f49da5 - /home/jas/rfc/rfc2088.txt MATCH rfc2088.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2095.txt 139434c3e50e59cf6eb559c7ae587c99 - bincimap-1.2.14beta2.orig/doc/rfc2095.txt 139434c3e50e59cf6eb559c7ae587c99 - /home/jas/rfc/rfc2095.txt MATCH rfc2095.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2177.txt dd8f2b9b4c2898334f41f8843f0f0efa - bincimap-1.2.14beta2.orig/doc/rfc2177.txt dd8f2b9b4c2898334f41f8843f0f0efa - /home/jas/rfc/rfc2177.txt MATCH rfc2177.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2180.txt 92a49bb4560db4896524896900238f49 - bincimap-1.2.14beta2.orig/doc/rfc2180.txt 92a49bb4560db4896524896900238f49 - /home/jas/rfc/rfc2180.txt MATCH rfc2180.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2192.txt 06a4f0eb97f0930b960dd5a42b4832bf - bincimap-1.2.14beta2.orig/doc/rfc2192.txt 06a4f0eb97f0930b960dd5a42b4832bf - /home/jas/rfc/rfc2192.txt MATCH rfc2192.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2193.txt 8c92ced2fd1b5bc16f753e303bf79d70 - bincimap-1.2.14beta2.orig/doc/rfc2193.txt 8c92ced2fd1b5bc16f753e303bf79d70 - /home/jas/rfc/rfc2193.txt MATCH rfc2193.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2195.txt 58a62f906e60dbb5c1dd12a6f0e92f6a - bincimap-1.2.14beta2.orig/doc/rfc2195.txt 58a62f906e60dbb5c1dd12a6f0e92f6a - /home/jas/rfc/rfc2195.txt MATCH rfc2195.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2221.txt 5e01beb9ec8c27d91c7c2b29b0cd91e2 - bincimap-1.2.14beta2.orig/doc/rfc2221.txt 5e01beb9ec8c27d91c7c2b29b0cd91e2 - /home/jas/rfc/rfc2221.txt MATCH rfc2221.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2342.txt 2f0f339458a114b666cee21fcfdf17e6 - bincimap-1.2.14beta2.orig/doc/rfc2342.txt 2f0f339458a114b666cee21fcfdf17e6 - /home/jas/rfc/rfc2342.txt MATCH rfc2342.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2359.txt d6a62e185568e19c3bf7243d2c6780c3 - bincimap-1.2.14beta2.orig/doc/rfc2359.txt d6a62e185568e19c3bf7243d2c6780c3 - /home/jas/rfc/rfc2359.txt MATCH rfc2359.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2595.txt 4ce96161b6a9155f912d043d69197334 - bincimap-1.2.14beta2.orig/doc/rfc2595.txt 4ce96161b6a9155f912d043d69197334 - /home/jas/rfc/rfc2595.txt MATCH rfc2595.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2683.txt eb1a2bda87de73def5f2554116c3d5e8 - bincimap-1.2.14beta2.orig/doc/rfc2683.txt eb1a2bda87de73def5f2554116c3d5e8 - /home/jas/rfc/rfc2683.txt MATCH rfc2683.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc2971.txt 1938a00ba4559200ad0c73b42e6c4c59 - bincimap-1.2.14beta2.orig/doc/rfc2971.txt 1938a00ba4559200ad0c73b42e6c4c59 - /home/jas/rfc/rfc2971.txt MATCH rfc2971.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc3028.txt fad4e041e4ce6c4e5ecf5cef169d4428 - bincimap-1.2.14beta2.orig/doc/rfc3028.txt fad4e041e4ce6c4e5ecf5cef169d4428 - /home/jas/rfc/rfc3028.txt MATCH rfc3028.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc3348.txt 108a527df34cdea02b9cbca30a8e9591 - bincimap-1.2.14beta2.orig/doc/rfc3348.txt 108a527df34cdea02b9cbca30a8e9591 - /home/jas/rfc/rfc3348.txt MATCH rfc3348.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc3501.txt f49bfc28b5980e6db512acc32febd7a3 - bincimap-1.2.14beta2.orig/doc/rfc3501.txt f49bfc28b5980e6db512acc32febd7a3 - /home/jas/rfc/rfc3501.txt MATCH rfc3501.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc3502.txt ccd7a89d77269a09dfd9dfa53d1f0f95 - bincimap-1.2.14beta2.orig/doc/rfc3502.txt ccd7a89d77269a09dfd9dfa53d1f0f95 - /home/jas/rfc/rfc3502.txt MATCH rfc3502.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc3503.txt 325eb3a524c75f246c4731423aae34dc - bincimap-1.2.14beta2.orig/doc/rfc3503.txt 325eb3a524c75f246c4731423aae34dc - /home/jas/rfc/rfc3503.txt MATCH rfc3503.txt tar xfz /data/debian/pool/main/b/bincimap/bincimap_1.2.14beta2.orig.tar.gz bincimap-1.2.14beta2.orig/doc/rfc3516.txt 713abcbabb3c6260e85e3d146bd5a0bf - bincimap-1.2.14beta2.orig/doc/rfc3516.txt 713abcbabb3c6260e85e3d146bd5a0bf - /home/jas/rfc/rfc3516.txt MATCH rfc3516.txt pkg bind9 ver 1:9.3.2-P1-2 lastfile bind9_9.3.2-P1.orig.tar.gz files bind-9.3.2-P1/doc/rfc/rfc1032.txt bind-9.3.2-P1/doc/rfc/rfc1033.txt bind-9.3.2-P1/doc/rfc/rfc1034.txt bind-9.3.2-P1/doc/rfc/rfc1035.txt bind-9.3.2-P1/doc/rfc/rfc1101.txt bind-9.3.2-P1/doc/rfc/rfc1122.txt bind-9.3.2-P1/doc/rfc/rfc1123.txt bind-9.3.2-P1/doc/rfc/rfc1183.txt bind-9.3.2-P1/doc/rfc/rfc1348.txt bind-9.3.2-P1/doc/rfc/rfc1535.txt bind-9.3.2-P1/doc/rfc/rfc1536.txt bind-9.3.2-P1/doc/rfc/rfc1537.txt bind-9.3.2-P1/doc/rfc/rfc1591.txt bind-9.3.2-P1/doc/rfc/rfc1611.txt bind-9.3.2-P1/doc/rfc/rfc1612.txt bind-9.3.2-P1/doc/rfc/rfc1706.txt bind-9.3.2-P1/doc/rfc/rfc1712.txt bind-9.3.2-P1/doc/rfc/rfc1750.txt bind-9.3.2-P1/doc/rfc/rfc1876.txt bind-9.3.2-P1/doc/rfc/rfc1886.txt bind-9.3.2-P1/doc/rfc/rfc1982.txt bind-9.3.2-P1/doc/rfc/rfc1995.txt bind-9.3.2-P1/doc/rfc/rfc1996.txt bind-9.3.2-P1/doc/rfc/rfc2052.txt bind-9.3.2-P1/doc/rfc/rfc2104.txt bind-9.3.2-P1/doc/rfc/rfc2119.txt bind-9.3.2-P1/doc/rfc/rfc2133.txt bind-9.3.2-P1/doc/rfc/rfc2136.txt bind-9.3.2-P1/doc/rfc/rfc2137.txt bind-9.3.2-P1/doc/rfc/rfc2163.txt bind-9.3.2-P1/doc/rfc/rfc2168.txt bind-9.3.2-P1/doc/rfc/rfc2181.txt bind-9.3.2-P1/doc/rfc/rfc2230.txt bind-9.3.2-P1/doc/rfc/rfc2308.txt bind-9.3.2-P1/doc/rfc/rfc2317.txt bind-9.3.2-P1/doc/rfc/rfc2373.txt bind-9.3.2-P1/doc/rfc/rfc2374.txt bind-9.3.2-P1/doc/rfc/rfc2375.txt bind-9.3.2-P1/doc/rfc/rfc2418.txt bind-9.3.2-P1/doc/rfc/rfc2535.txt bind-9.3.2-P1/doc/rfc/rfc2536.txt bind-9.3.2-P1/doc/rfc/rfc2537.txt bind-9.3.2-P1/doc/rfc/rfc2538.txt bind-9.3.2-P1/doc/rfc/rfc2539.txt bind-9.3.2-P1/doc/rfc/rfc2540.txt bind-9.3.2-P1/doc/rfc/rfc2541.txt bind-9.3.2-P1/doc/rfc/rfc2553.txt bind-9.3.2-P1/doc/rfc/rfc2671.txt bind-9.3.2-P1/doc/rfc/rfc2672.txt bind-9.3.2-P1/doc/rfc/rfc2673.txt bind-9.3.2-P1/doc/rfc/rfc2782.txt bind-9.3.2-P1/doc/rfc/rfc2825.txt bind-9.3.2-P1/doc/rfc/rfc2826.txt bind-9.3.2-P1/doc/rfc/rfc2845.txt bind-9.3.2-P1/doc/rfc/rfc2874.txt bind-9.3.2-P1/doc/rfc/rfc2915.txt bind-9.3.2-P1/doc/rfc/rfc2929.txt bind-9.3.2-P1/doc/rfc/rfc2930.txt bind-9.3.2-P1/doc/rfc/rfc2931.txt bind-9.3.2-P1/doc/rfc/rfc3007.txt bind-9.3.2-P1/doc/rfc/rfc3008.txt bind-9.3.2-P1/doc/rfc/rfc3071.txt bind-9.3.2-P1/doc/rfc/rfc3090.txt bind-9.3.2-P1/doc/rfc/rfc3110.txt bind-9.3.2-P1/doc/rfc/rfc3123.txt bind-9.3.2-P1/doc/rfc/rfc3152.txt bind-9.3.2-P1/doc/rfc/rfc3197.txt bind-9.3.2-P1/doc/rfc/rfc3225.txt bind-9.3.2-P1/doc/rfc/rfc3226.txt bind-9.3.2-P1/doc/rfc/rfc3258.txt bind-9.3.2-P1/doc/rfc/rfc3363.txt bind-9.3.2-P1/doc/rfc/rfc3364.txt bind-9.3.2-P1/doc/rfc/rfc3425.txt bind-9.3.2-P1/doc/rfc/rfc3445.txt bind-9.3.2-P1/doc/rfc/rfc3467.txt bind-9.3.2-P1/doc/rfc/rfc3490.txt bind-9.3.2-P1/doc/rfc/rfc3491.txt bind-9.3.2-P1/doc/rfc/rfc3492.txt bind-9.3.2-P1/doc/rfc/rfc3493.txt bind-9.3.2-P1/doc/rfc/rfc3513.txt bind-9.3.2-P1/doc/rfc/rfc3596.txt bind-9.3.2-P1/doc/rfc/rfc3597.txt bind-9.3.2-P1/doc/rfc/rfc3645.txt bind-9.3.2-P1/doc/rfc/rfc3655.txt bind-9.3.2-P1/doc/rfc/rfc3658.txt bind-9.3.2-P1/doc/rfc/rfc3757.txt bind-9.3.2-P1/doc/rfc/rfc3833.txt bind-9.3.2-P1/doc/rfc/rfc3845.txt bind-9.3.2-P1/doc/rfc/rfc3901.txt bind-9.3.2-P1/doc/rfc/rfc4025.txt bind-9.3.2-P1/doc/rfc/rfc4033.txt bind-9.3.2-P1/doc/rfc/rfc4034.txt bind-9.3.2-P1/doc/rfc/rfc4035.txt bind-9.3.2-P1/doc/rfc/rfc4074.txt bind-9.3.2-P1/doc/rfc/rfc4159.txt bind-9.3.2-P1/doc/rfc/rfc952.txt bind-9.3.2-P1/doc/draft/draft-baba-dnsext-acl-reqts-01.txt bind-9.3.2-P1/doc/draft/draft-daigle-napstr-04.txt bind-9.3.2-P1/doc/draft/draft-danisch-dns-rr-smtp-03.txt bind-9.3.2-P1/doc/draft/draft-dnsext-opcode-discover-02.txt bind-9.3.2-P1/doc/draft/draft-durand-dnsop-dynreverse-00.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-2929bis-01.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-ecc-key-07.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-insensitive-06.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-interop3597-02.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-mdns-43.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-nsec3-02.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-respsize-02.txt bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-serverid-04.txt bind-9.3.2-P1/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt bind-9.3.2-P1/doc/draft/draft-ietf-ipv6-node-requirements-08.txt bind-9.3.2-P1/doc/draft/draft-ietf-secsh-dns-05.txt bind-9.3.2-P1/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt bind-9.3.2-P1/doc/draft/draft-kato-dnsop-local-zones-00.txt bind-9.3.2-P1/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1032.txt 6466ef602a92458a7ced6d771499a949 - bind-9.3.2-P1/doc/rfc/rfc1032.txt 339eba3a119165da6a8c520f1da987fe - /home/jas/rfc/rfc1032.txt MISMATCH rfc1032.txt --- bind-9.3.2-P1/doc/rfc/rfc1032.txt 1999-03-23 18:37:40.000000000 +0100 +++ /home/jas/rfc/rfc1032.txt 1987-11-10 19:28:33.000000000 +0100 @@ -19,7 +19,7 @@ BACKGROUND - Domains are administrative entities that provide decentralized + Domains are adminstrative entities that provide decentralized management of host naming and addressing. The domain-naming system is distributed and hierarchical. @@ -86,7 +86,7 @@ A zone consists of those contiguous parts of the domain tree for which a domain server has complete information and over which it has - authority. A domain server may be authoritative for more than one + authority. A domain server may be authoratative for more than one zone. The domain technical/zone contact is the person who tends to the technical aspects of maintaining the domain's name server and resolver software, and database files. He keeps the name server @@ -208,7 +208,7 @@ of the label ".ARPA" in order to accelerate a transition to the domain-naming system. Another reason for the blanket name changes was to force hosts to become accustomed to using the new style - names and to modify their network software, if necessary. This + names and to modifiy their network software, if necessary. This was done on a network-wide basis and was directed by DCA in DDN Management Bulletin No. 22. Hosts that fall into this domain will eventually move to other branches of the domain tree. @@ -249,7 +249,7 @@ host should have only one name regardless of what networks it is connected to. This implies, that, in general, domain names should not include routing information or addresses. For example, a host - that has one network connection to the Internet and another to BITNET + that has one network connection to the Interent and another to BITNET should use the same name when talking to either network. For a description of the syntax of domain names, please refer to Section 3 of RFC-1034. @@ -258,7 +258,7 @@ The verification process can be accomplished in several ways. One of these is through the NIC WHOIS server. If he has access to WHOIS, - the DA can type the command "whois domain ". + the DA can type the commmand "whois domain ". The reply from WHOIS will supply the following: the name and address of the organization "owning" the domain; the name of the domain; its administrative, technical, and zone contacts; the host names and @@ -421,7 +421,7 @@ [ Not online ] 6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031, - Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ] + Mitre Corporation, October 1987. [ RDC:RFC1031.TXT ] 7. Lottor, M.K., "Domain Administrators Operations Guide", RFC-1033, DDN Network Information Center, SRI International, @@ -766,7 +766,7 @@ SRI International is an independent, nonprofit, scientific research organization. It performs basic and applied research for government and commercial clients, and contributes to - worldwide economic, scientific, industrial, and social progress + worldwide ecomomic, scientific, industrial, and social progress through research and related services. bind-9.3.2-P1/doc/rfc/rfc1032.txt /home/jas/rfc/rfc1032.txt differ: byte 883, line 22 tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1033.txt 8ed86ea7839d828ecff7c012ca55ad88 - bind-9.3.2-P1/doc/rfc/rfc1033.txt 0a89a3f92e8fbb2070bb60a6e10972db - /home/jas/rfc/rfc1033.txt MISMATCH rfc1033.txt --- bind-9.3.2-P1/doc/rfc/rfc1033.txt 1999-03-23 18:37:40.000000000 +0100 +++ /home/jas/rfc/rfc1033.txt 1987-11-12 00:27:28.000000000 +0100 @@ -344,8 +344,8 @@ KL.SRI.COM, then the NS record would look like this, but you will also need to have the following A record. - SRI.COM. NS KL.SRI.COM. - KL.SRI.COM. A 10.1.0.2 + SRI.COM. NS + KL.SRI.COM. KL.SRI.COM. A 10.1.0.2. A (Address) bind-9.3.2-P1/doc/rfc/rfc1033.txt /home/jas/rfc/rfc1033.txt differ: byte 12753, line 347 tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1034.txt be18aea2b66422dd8d0dca05b09eb0cc - bind-9.3.2-P1/doc/rfc/rfc1034.txt be18aea2b66422dd8d0dca05b09eb0cc - /home/jas/rfc/rfc1034.txt MATCH rfc1034.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1035.txt 85600131ad1cdecc84c31fbb0dffd6cf - bind-9.3.2-P1/doc/rfc/rfc1035.txt 85600131ad1cdecc84c31fbb0dffd6cf - /home/jas/rfc/rfc1035.txt MATCH rfc1035.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1101.txt 395fbd51be1b844651cbb0d4e722c205 - bind-9.3.2-P1/doc/rfc/rfc1101.txt 395fbd51be1b844651cbb0d4e722c205 - /home/jas/rfc/rfc1101.txt MATCH rfc1101.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1122.txt 2ffd604f3947e521871545ec33269fda - bind-9.3.2-P1/doc/rfc/rfc1122.txt 2ffd604f3947e521871545ec33269fda - /home/jas/rfc/rfc1122.txt MATCH rfc1122.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1123.txt 5275203d2f583703f71965a2b5a8bf69 - bind-9.3.2-P1/doc/rfc/rfc1123.txt 5275203d2f583703f71965a2b5a8bf69 - /home/jas/rfc/rfc1123.txt MATCH rfc1123.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1183.txt 69e7e84bfdb277d86b80b186ac914eca - bind-9.3.2-P1/doc/rfc/rfc1183.txt 69e7e84bfdb277d86b80b186ac914eca - /home/jas/rfc/rfc1183.txt MATCH rfc1183.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1348.txt aece0a332d9a1316eb60488c8cdd0e91 - bind-9.3.2-P1/doc/rfc/rfc1348.txt aece0a332d9a1316eb60488c8cdd0e91 - /home/jas/rfc/rfc1348.txt MATCH rfc1348.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1535.txt ebd35776b603bb680988be9c51903d6f - bind-9.3.2-P1/doc/rfc/rfc1535.txt 428ab6f50b96df5e7197f5c704f02be7 - /home/jas/rfc/rfc1535.txt MISMATCH rfc1535.txt cmp: EOF on /home/jas/rfc/rfc1535.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1536.txt 153394ddc493733e928e5d56e602dcd8 - bind-9.3.2-P1/doc/rfc/rfc1536.txt c13640d63fcbeac0e745289ba5386d41 - /home/jas/rfc/rfc1536.txt MISMATCH rfc1536.txt cmp: EOF on /home/jas/rfc/rfc1536.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1537.txt 02fb4f6396536af70682f8ff2fe12572 - bind-9.3.2-P1/doc/rfc/rfc1537.txt 02fb4f6396536af70682f8ff2fe12572 - /home/jas/rfc/rfc1537.txt MATCH rfc1537.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1591.txt cc610720e236b47b36029eedf6acf0e7 - bind-9.3.2-P1/doc/rfc/rfc1591.txt cc610720e236b47b36029eedf6acf0e7 - /home/jas/rfc/rfc1591.txt MATCH rfc1591.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1611.txt 75c01762f62152af398886066070f442 - bind-9.3.2-P1/doc/rfc/rfc1611.txt 75c01762f62152af398886066070f442 - /home/jas/rfc/rfc1611.txt MATCH rfc1611.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1612.txt 8dcb601014e5ee350077df3ab4dbf712 - bind-9.3.2-P1/doc/rfc/rfc1612.txt 8dcb601014e5ee350077df3ab4dbf712 - /home/jas/rfc/rfc1612.txt MATCH rfc1612.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1706.txt 167bf869131250bdf0edbbf5539fde9b - bind-9.3.2-P1/doc/rfc/rfc1706.txt 167bf869131250bdf0edbbf5539fde9b - /home/jas/rfc/rfc1706.txt MATCH rfc1706.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1712.txt 9c80d4e79e61ff097c282795319ad302 - bind-9.3.2-P1/doc/rfc/rfc1712.txt 9c80d4e79e61ff097c282795319ad302 - /home/jas/rfc/rfc1712.txt MATCH rfc1712.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1750.txt b7b57294f70ad60acc936f606365558c - bind-9.3.2-P1/doc/rfc/rfc1750.txt b7b57294f70ad60acc936f606365558c - /home/jas/rfc/rfc1750.txt MATCH rfc1750.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1876.txt ef777225afd3ca68580d69e7db9c4241 - bind-9.3.2-P1/doc/rfc/rfc1876.txt ef777225afd3ca68580d69e7db9c4241 - /home/jas/rfc/rfc1876.txt MATCH rfc1876.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1886.txt 5d6136424009ef845d3dc9cb415c41d4 - bind-9.3.2-P1/doc/rfc/rfc1886.txt 5d6136424009ef845d3dc9cb415c41d4 - /home/jas/rfc/rfc1886.txt MATCH rfc1886.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1982.txt 2358ef21dd44eebc189d13921c6edcda - bind-9.3.2-P1/doc/rfc/rfc1982.txt 2358ef21dd44eebc189d13921c6edcda - /home/jas/rfc/rfc1982.txt MATCH rfc1982.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1995.txt a7d499741a592fd88f12e9fde9eed90a - bind-9.3.2-P1/doc/rfc/rfc1995.txt a7d499741a592fd88f12e9fde9eed90a - /home/jas/rfc/rfc1995.txt MATCH rfc1995.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc1996.txt 11afa82908a58a5f1a2509ee1097388d - bind-9.3.2-P1/doc/rfc/rfc1996.txt 11afa82908a58a5f1a2509ee1097388d - /home/jas/rfc/rfc1996.txt MATCH rfc1996.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2052.txt 73c4607219add250a75c392891bf7f6a - bind-9.3.2-P1/doc/rfc/rfc2052.txt 95ebeac8f3240a6814f8b1b17075bb85 - /home/jas/rfc/rfc2052.txt MISMATCH rfc2052.txt --- bind-9.3.2-P1/doc/rfc/rfc2052.txt 1999-03-23 18:37:49.000000000 +0100 +++ /home/jas/rfc/rfc2052.txt 1996-10-30 19:26:46.000000000 +0100 @@ -215,7 +215,7 @@ Moving this information to the DNS makes it less necessary to update these files on every single computer of the net every time a new service is added, and makes it possible to move standard services out - of the "root-only" port range on unix + of the "root-only" port range on unix. bind-9.3.2-P1/doc/rfc/rfc2052.txt /home/jas/rfc/rfc2052.txt differ: byte 8233, line 218 tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2104.txt 11ed69388b6a8a659942eb8dbadce26d - bind-9.3.2-P1/doc/rfc/rfc2104.txt d108e0788d01554ad3d1cd49558b2d20 - /home/jas/rfc/rfc2104.txt MISMATCH rfc2104.txt --- bind-9.3.2-P1/doc/rfc/rfc2104.txt 1999-03-23 18:37:49.000000000 +0100 +++ /home/jas/rfc/rfc2104.txt 1997-02-05 00:39:38.000000000 +0100 @@ -617,4 +617,3 @@ Krawczyk, et. al. Informational [Page 11] - cmp: EOF on /home/jas/rfc/rfc2104.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2119.txt 42f1e4edffdfec8db0ac811adfd13ce1 - bind-9.3.2-P1/doc/rfc/rfc2119.txt 42f1e4edffdfec8db0ac811adfd13ce1 - /home/jas/rfc/rfc2119.txt MATCH rfc2119.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2133.txt c1b08d31d9555e58c06507178c8ff204 - bind-9.3.2-P1/doc/rfc/rfc2133.txt c1b08d31d9555e58c06507178c8ff204 - /home/jas/rfc/rfc2133.txt MATCH rfc2133.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2136.txt 2aa17c83a8324a2aafadf53dfe0212ee - bind-9.3.2-P1/doc/rfc/rfc2136.txt 53288b8e0c118c861f63014a00aefd3e - /home/jas/rfc/rfc2136.txt MISMATCH rfc2136.txt --- bind-9.3.2-P1/doc/rfc/rfc2136.txt 1999-03-23 18:37:50.000000000 +0100 +++ /home/jas/rfc/rfc2136.txt 1997-04-18 23:45:26.000000000 +0200 @@ -1457,4 +1457,3 @@ Vixie, et. al. Standards Track [Page 26] - cmp: EOF on /home/jas/rfc/rfc2136.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2137.txt 0922f9e921f403877aebde6c4bdd7dc0 - bind-9.3.2-P1/doc/rfc/rfc2137.txt 0922f9e921f403877aebde6c4bdd7dc0 - /home/jas/rfc/rfc2137.txt MATCH rfc2137.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2163.txt b0bb1623b0b60f38847d3f4abce60650 - bind-9.3.2-P1/doc/rfc/rfc2163.txt b0bb1623b0b60f38847d3f4abce60650 - /home/jas/rfc/rfc2163.txt MATCH rfc2163.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2168.txt a92856269d93111794b6a80008e13309 - bind-9.3.2-P1/doc/rfc/rfc2168.txt a92856269d93111794b6a80008e13309 - /home/jas/rfc/rfc2168.txt MATCH rfc2168.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2181.txt 497e2a3c47d6c948e39c0eddd12707ab - bind-9.3.2-P1/doc/rfc/rfc2181.txt 497e2a3c47d6c948e39c0eddd12707ab - /home/jas/rfc/rfc2181.txt MATCH rfc2181.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2230.txt b7265916df6739be87654b497046db26 - bind-9.3.2-P1/doc/rfc/rfc2230.txt b7265916df6739be87654b497046db26 - /home/jas/rfc/rfc2230.txt MATCH rfc2230.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2308.txt 29a7b5293f907331e3a5e5b0e47d2d6e - bind-9.3.2-P1/doc/rfc/rfc2308.txt 29a7b5293f907331e3a5e5b0e47d2d6e - /home/jas/rfc/rfc2308.txt MATCH rfc2308.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2317.txt 0ff76ebf802c894aece54ad5f436471b - bind-9.3.2-P1/doc/rfc/rfc2317.txt 0ff76ebf802c894aece54ad5f436471b - /home/jas/rfc/rfc2317.txt MATCH rfc2317.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2373.txt 97da9a50c28dd413dc870d5230083cf8 - bind-9.3.2-P1/doc/rfc/rfc2373.txt 97da9a50c28dd413dc870d5230083cf8 - /home/jas/rfc/rfc2373.txt MATCH rfc2373.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2374.txt cb210d60f9b4afec278e8a323f0bdb24 - bind-9.3.2-P1/doc/rfc/rfc2374.txt cb210d60f9b4afec278e8a323f0bdb24 - /home/jas/rfc/rfc2374.txt MATCH rfc2374.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2375.txt e42c5d44e27e73aab956a2ef68674b55 - bind-9.3.2-P1/doc/rfc/rfc2375.txt e42c5d44e27e73aab956a2ef68674b55 - /home/jas/rfc/rfc2375.txt MATCH rfc2375.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2418.txt 5f9e67cc635a801a3cf4cf7e5569911f - bind-9.3.2-P1/doc/rfc/rfc2418.txt 5f9e67cc635a801a3cf4cf7e5569911f - /home/jas/rfc/rfc2418.txt MATCH rfc2418.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2535.txt 10860aa12781842eb3704511a23d514f - bind-9.3.2-P1/doc/rfc/rfc2535.txt 10860aa12781842eb3704511a23d514f - /home/jas/rfc/rfc2535.txt MATCH rfc2535.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2536.txt 839060f6e2b65db197edf78ad1d2a298 - bind-9.3.2-P1/doc/rfc/rfc2536.txt 839060f6e2b65db197edf78ad1d2a298 - /home/jas/rfc/rfc2536.txt MATCH rfc2536.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2537.txt 732fd8f1a2e5844225de71335d7820dc - bind-9.3.2-P1/doc/rfc/rfc2537.txt 732fd8f1a2e5844225de71335d7820dc - /home/jas/rfc/rfc2537.txt MATCH rfc2537.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2538.txt 17f2919a3fb6bf82d062f1feefa3e7f4 - bind-9.3.2-P1/doc/rfc/rfc2538.txt 17f2919a3fb6bf82d062f1feefa3e7f4 - /home/jas/rfc/rfc2538.txt MATCH rfc2538.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2539.txt 140bfdef956a08c7871c9076a16a0193 - bind-9.3.2-P1/doc/rfc/rfc2539.txt 140bfdef956a08c7871c9076a16a0193 - /home/jas/rfc/rfc2539.txt MATCH rfc2539.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2540.txt 748583d77a05dd478cd12c06f52f87a4 - bind-9.3.2-P1/doc/rfc/rfc2540.txt 748583d77a05dd478cd12c06f52f87a4 - /home/jas/rfc/rfc2540.txt MATCH rfc2540.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2541.txt 60be8c9e6f03aadfc395103ff64fdf38 - bind-9.3.2-P1/doc/rfc/rfc2541.txt 60be8c9e6f03aadfc395103ff64fdf38 - /home/jas/rfc/rfc2541.txt MATCH rfc2541.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2553.txt 1148f85a05b1029b48ccb55cdbcf8c4a - bind-9.3.2-P1/doc/rfc/rfc2553.txt 1148f85a05b1029b48ccb55cdbcf8c4a - /home/jas/rfc/rfc2553.txt MATCH rfc2553.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2671.txt 9a8b828b2763a55db72d17602d5a3527 - bind-9.3.2-P1/doc/rfc/rfc2671.txt 9a8b828b2763a55db72d17602d5a3527 - /home/jas/rfc/rfc2671.txt MATCH rfc2671.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2672.txt 676aef449eb0785126268cc57feae803 - bind-9.3.2-P1/doc/rfc/rfc2672.txt 676aef449eb0785126268cc57feae803 - /home/jas/rfc/rfc2672.txt MATCH rfc2672.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2673.txt 236a4128ac338ddf91f9fdff8a62bb1f - bind-9.3.2-P1/doc/rfc/rfc2673.txt 236a4128ac338ddf91f9fdff8a62bb1f - /home/jas/rfc/rfc2673.txt MATCH rfc2673.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2782.txt 8ef8540bc8cf44b6eada9e349e61210f - bind-9.3.2-P1/doc/rfc/rfc2782.txt 8ef8540bc8cf44b6eada9e349e61210f - /home/jas/rfc/rfc2782.txt MATCH rfc2782.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2825.txt 35b10409c18d1aed87366719d766dd57 - bind-9.3.2-P1/doc/rfc/rfc2825.txt 9ca2b27eb66a8f7679ba57b9fa8cc7c7 - /home/jas/rfc/rfc2825.txt MISMATCH rfc2825.txt bind-9.3.2-P1/doc/rfc/rfc2825.txt /home/jas/rfc/rfc2825.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2826.txt a443541f14b6ed912708c04dbfa8f9c9 - bind-9.3.2-P1/doc/rfc/rfc2826.txt 855c0499f7b899185e6d18abd15936c6 - /home/jas/rfc/rfc2826.txt MISMATCH rfc2826.txt bind-9.3.2-P1/doc/rfc/rfc2826.txt /home/jas/rfc/rfc2826.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2845.txt 75ff46c483fd31039905ee1b28e90bc3 - bind-9.3.2-P1/doc/rfc/rfc2845.txt 75ff46c483fd31039905ee1b28e90bc3 - /home/jas/rfc/rfc2845.txt MATCH rfc2845.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2874.txt a0995ef5c364b828389091ff247550f2 - bind-9.3.2-P1/doc/rfc/rfc2874.txt a0995ef5c364b828389091ff247550f2 - /home/jas/rfc/rfc2874.txt MATCH rfc2874.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2915.txt c236c5d8b8ba426a1f401b3fb7d49e88 - bind-9.3.2-P1/doc/rfc/rfc2915.txt c236c5d8b8ba426a1f401b3fb7d49e88 - /home/jas/rfc/rfc2915.txt MATCH rfc2915.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2929.txt 4b2acd24e07747fd0569bd0646601021 - bind-9.3.2-P1/doc/rfc/rfc2929.txt 4b2acd24e07747fd0569bd0646601021 - /home/jas/rfc/rfc2929.txt MATCH rfc2929.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2930.txt 6c36cc6057527e92d7e07e59e4b52582 - bind-9.3.2-P1/doc/rfc/rfc2930.txt 6c36cc6057527e92d7e07e59e4b52582 - /home/jas/rfc/rfc2930.txt MATCH rfc2930.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc2931.txt 13d5e5c4e8ddcc7b7f35c4a7296606ab - bind-9.3.2-P1/doc/rfc/rfc2931.txt 13d5e5c4e8ddcc7b7f35c4a7296606ab - /home/jas/rfc/rfc2931.txt MATCH rfc2931.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3007.txt 0d58c3323bd81b933dde43a073266e58 - bind-9.3.2-P1/doc/rfc/rfc3007.txt 0d58c3323bd81b933dde43a073266e58 - /home/jas/rfc/rfc3007.txt MATCH rfc3007.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3008.txt 52f25def794d04856a1ebe90cdefe92f - bind-9.3.2-P1/doc/rfc/rfc3008.txt 52f25def794d04856a1ebe90cdefe92f - /home/jas/rfc/rfc3008.txt MATCH rfc3008.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3071.txt ad6cc295817209ae81e25a5c37f30b12 - bind-9.3.2-P1/doc/rfc/rfc3071.txt ad6cc295817209ae81e25a5c37f30b12 - /home/jas/rfc/rfc3071.txt MATCH rfc3071.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3090.txt 6f2263bb758bb0c3a14ef4c7277f2266 - bind-9.3.2-P1/doc/rfc/rfc3090.txt 6f2263bb758bb0c3a14ef4c7277f2266 - /home/jas/rfc/rfc3090.txt MATCH rfc3090.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3110.txt ff41062ca24ec941274a37ec41124fa1 - bind-9.3.2-P1/doc/rfc/rfc3110.txt ff41062ca24ec941274a37ec41124fa1 - /home/jas/rfc/rfc3110.txt MATCH rfc3110.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3123.txt d022721b3a666b3a2bc1b5c892fb3bd1 - bind-9.3.2-P1/doc/rfc/rfc3123.txt d022721b3a666b3a2bc1b5c892fb3bd1 - /home/jas/rfc/rfc3123.txt MATCH rfc3123.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3152.txt 76264310ffbdd2729eb04cf6dbff16bb - bind-9.3.2-P1/doc/rfc/rfc3152.txt 76264310ffbdd2729eb04cf6dbff16bb - /home/jas/rfc/rfc3152.txt MATCH rfc3152.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3197.txt 27dede25e6ba4bc9c167ae22b2bb7e05 - bind-9.3.2-P1/doc/rfc/rfc3197.txt 27dede25e6ba4bc9c167ae22b2bb7e05 - /home/jas/rfc/rfc3197.txt MATCH rfc3197.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3225.txt 6b833b757f7b9ddd959a93e1e3a35a84 - bind-9.3.2-P1/doc/rfc/rfc3225.txt 6b833b757f7b9ddd959a93e1e3a35a84 - /home/jas/rfc/rfc3225.txt MATCH rfc3225.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3226.txt a2ecece3b63b6441a31716df977d6564 - bind-9.3.2-P1/doc/rfc/rfc3226.txt a2ecece3b63b6441a31716df977d6564 - /home/jas/rfc/rfc3226.txt MATCH rfc3226.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3258.txt 3dd583529f6f39f8c86f558fabfbd7e3 - bind-9.3.2-P1/doc/rfc/rfc3258.txt 3dd583529f6f39f8c86f558fabfbd7e3 - /home/jas/rfc/rfc3258.txt MATCH rfc3258.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3363.txt 187c8f8cdeaf602f644fb0677b3af885 - bind-9.3.2-P1/doc/rfc/rfc3363.txt 187c8f8cdeaf602f644fb0677b3af885 - /home/jas/rfc/rfc3363.txt MATCH rfc3363.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3364.txt 35baf2b7f684cafefb2d8be76a1ca504 - bind-9.3.2-P1/doc/rfc/rfc3364.txt 35baf2b7f684cafefb2d8be76a1ca504 - /home/jas/rfc/rfc3364.txt MATCH rfc3364.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3425.txt 98434c36f897a63b971f67272c1b125a - bind-9.3.2-P1/doc/rfc/rfc3425.txt 98434c36f897a63b971f67272c1b125a - /home/jas/rfc/rfc3425.txt MATCH rfc3425.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3445.txt f1eac9d383b1c8daf566d1e6a5452fd1 - bind-9.3.2-P1/doc/rfc/rfc3445.txt f1eac9d383b1c8daf566d1e6a5452fd1 - /home/jas/rfc/rfc3445.txt MATCH rfc3445.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3467.txt c3f70c5d24693cfc712daf58a0e6958e - bind-9.3.2-P1/doc/rfc/rfc3467.txt c3f70c5d24693cfc712daf58a0e6958e - /home/jas/rfc/rfc3467.txt MATCH rfc3467.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3490.txt 30ca17544a02b73ddf0ed75fb1cab0d4 - bind-9.3.2-P1/doc/rfc/rfc3490.txt 30ca17544a02b73ddf0ed75fb1cab0d4 - /home/jas/rfc/rfc3490.txt MATCH rfc3490.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3491.txt f01785038fbe76397de5dc4cd63383cc - bind-9.3.2-P1/doc/rfc/rfc3491.txt f01785038fbe76397de5dc4cd63383cc - /home/jas/rfc/rfc3491.txt MATCH rfc3491.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3492.txt 6599e416de5c2aaf58f4dc6e3d603461 - bind-9.3.2-P1/doc/rfc/rfc3492.txt 6599e416de5c2aaf58f4dc6e3d603461 - /home/jas/rfc/rfc3492.txt MATCH rfc3492.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3493.txt ec56dfe6fce5637624bad34a4a1775f7 - bind-9.3.2-P1/doc/rfc/rfc3493.txt ec56dfe6fce5637624bad34a4a1775f7 - /home/jas/rfc/rfc3493.txt MATCH rfc3493.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3513.txt ed4a32d357a3f14449fff67e4ef6a4c0 - bind-9.3.2-P1/doc/rfc/rfc3513.txt ed4a32d357a3f14449fff67e4ef6a4c0 - /home/jas/rfc/rfc3513.txt MATCH rfc3513.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3596.txt 8c36a009cb818c1470179175940328f7 - bind-9.3.2-P1/doc/rfc/rfc3596.txt 8c36a009cb818c1470179175940328f7 - /home/jas/rfc/rfc3596.txt MATCH rfc3596.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3597.txt 5bba4c45bd755fe88da64b8490f53634 - bind-9.3.2-P1/doc/rfc/rfc3597.txt 5bba4c45bd755fe88da64b8490f53634 - /home/jas/rfc/rfc3597.txt MATCH rfc3597.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3645.txt 825e0f224a05366d3f3ff7a7e402351b - bind-9.3.2-P1/doc/rfc/rfc3645.txt 825e0f224a05366d3f3ff7a7e402351b - /home/jas/rfc/rfc3645.txt MATCH rfc3645.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3655.txt 73555c1488b432c9a748fd5e53330052 - bind-9.3.2-P1/doc/rfc/rfc3655.txt 73555c1488b432c9a748fd5e53330052 - /home/jas/rfc/rfc3655.txt MATCH rfc3655.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3658.txt ae2d86267017f521c0bef73dd57f6674 - bind-9.3.2-P1/doc/rfc/rfc3658.txt ae2d86267017f521c0bef73dd57f6674 - /home/jas/rfc/rfc3658.txt MATCH rfc3658.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3757.txt 5050b72679fdb8727880325d61335189 - bind-9.3.2-P1/doc/rfc/rfc3757.txt 5050b72679fdb8727880325d61335189 - /home/jas/rfc/rfc3757.txt MATCH rfc3757.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3833.txt d09af77c8edbfa04b10ffd549a71893e - bind-9.3.2-P1/doc/rfc/rfc3833.txt d09af77c8edbfa04b10ffd549a71893e - /home/jas/rfc/rfc3833.txt MATCH rfc3833.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3845.txt 940931ded0dd604246874e317786336e - bind-9.3.2-P1/doc/rfc/rfc3845.txt 940931ded0dd604246874e317786336e - /home/jas/rfc/rfc3845.txt MATCH rfc3845.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc3901.txt 4de3c34bfcbe74bff5c57f23eb613304 - bind-9.3.2-P1/doc/rfc/rfc3901.txt 4de3c34bfcbe74bff5c57f23eb613304 - /home/jas/rfc/rfc3901.txt MATCH rfc3901.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc4025.txt 55bcefbf86b981547e3a107b8baf502a - bind-9.3.2-P1/doc/rfc/rfc4025.txt 55bcefbf86b981547e3a107b8baf502a - /home/jas/rfc/rfc4025.txt MATCH rfc4025.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc4033.txt da98cc34c4772374bc38b25c96a5317e - bind-9.3.2-P1/doc/rfc/rfc4033.txt da98cc34c4772374bc38b25c96a5317e - /home/jas/rfc/rfc4033.txt MATCH rfc4033.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc4034.txt 5b0ddba4e12109f3644f891eb2eb95e3 - bind-9.3.2-P1/doc/rfc/rfc4034.txt 5b0ddba4e12109f3644f891eb2eb95e3 - /home/jas/rfc/rfc4034.txt MATCH rfc4034.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc4035.txt 15cb870610b4238ff98f31ebcda19d54 - bind-9.3.2-P1/doc/rfc/rfc4035.txt 15cb870610b4238ff98f31ebcda19d54 - /home/jas/rfc/rfc4035.txt MATCH rfc4035.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc4074.txt e6793cdf8abbb8ff2c37b8c2230df159 - bind-9.3.2-P1/doc/rfc/rfc4074.txt e6793cdf8abbb8ff2c37b8c2230df159 - /home/jas/rfc/rfc4074.txt MATCH rfc4074.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc4159.txt 0d26a4709d2c89a6f4b8d03f51da53e7 - bind-9.3.2-P1/doc/rfc/rfc4159.txt 0d26a4709d2c89a6f4b8d03f51da53e7 - /home/jas/rfc/rfc4159.txt MATCH rfc4159.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/rfc/rfc952.txt 20c9dea23e356e5fab48dc8d1d85c1bb - bind-9.3.2-P1/doc/rfc/rfc952.txt 20c9dea23e356e5fab48dc8d1d85c1bb - /home/jas/rfc/rfc952.txt MATCH rfc952.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-baba-dnsext-acl-reqts-01.txt 66a06b10547c19a60e9daaa888beadcc - bind-9.3.2-P1/doc/draft/draft-baba-dnsext-acl-reqts-01.txt 66a06b10547c19a60e9daaa888beadcc - /home/jas/rfc/draft-baba-dnsext-acl-reqts-01.txt MATCH draft-baba-dnsext-acl-reqts-01.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-daigle-napstr-04.txt d3ab458131293ab36d954f813faf288d - bind-9.3.2-P1/doc/draft/draft-daigle-napstr-04.txt d3ab458131293ab36d954f813faf288d - /home/jas/rfc/draft-daigle-napstr-04.txt MATCH draft-daigle-napstr-04.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-danisch-dns-rr-smtp-03.txt b1c94c810eb3502b1483ea5015b772c1 - bind-9.3.2-P1/doc/draft/draft-danisch-dns-rr-smtp-03.txt b1c94c810eb3502b1483ea5015b772c1 - /home/jas/rfc/draft-danisch-dns-rr-smtp-03.txt MATCH draft-danisch-dns-rr-smtp-03.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-dnsext-opcode-discover-02.txt fef16ce522bc37cdb9a065132ee5d3e9 - bind-9.3.2-P1/doc/draft/draft-dnsext-opcode-discover-02.txt fef16ce522bc37cdb9a065132ee5d3e9 - /home/jas/rfc/draft-dnsext-opcode-discover-02.txt MATCH draft-dnsext-opcode-discover-02.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-durand-dnsop-dynreverse-00.txt d10022592baeb069a23236f3bac146ee - bind-9.3.2-P1/doc/draft/draft-durand-dnsop-dynreverse-00.txt d10022592baeb069a23236f3bac146ee - /home/jas/rfc/draft-durand-dnsop-dynreverse-00.txt MATCH draft-durand-dnsop-dynreverse-00.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-2929bis-01.txt e2585e3a55d48ce906bddbe2ef64f819 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-2929bis-01.txt e2585e3a55d48ce906bddbe2ef64f819 - /home/jas/rfc/draft-ietf-dnsext-2929bis-01.txt MATCH draft-ietf-dnsext-2929bis-01.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt 2a5d278f61be51bb467f96dd5318392c - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt 2a5d278f61be51bb467f96dd5318392c - /home/jas/rfc/draft-ietf-dnsext-axfr-clarify-05.txt MATCH draft-ietf-dnsext-axfr-clarify-05.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt 5c4f8f3242e77f44bf187e660a022131 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt 5c4f8f3242e77f44bf187e660a022131 - /home/jas/rfc/draft-ietf-dnsext-dhcid-rr-09.txt MATCH draft-ietf-dnsext-dhcid-rr-09.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt 54cd55e19bb4ba1c3a85f667eace6c23 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt 54cd55e19bb4ba1c3a85f667eace6c23 - /home/jas/rfc/draft-ietf-dnsext-dns-name-p-s-00.txt MATCH draft-ietf-dnsext-dns-name-p-s-00.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt ba09a3ce488bf2bc86e093fbf2c33099 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt ba09a3ce488bf2bc86e093fbf2c33099 - /home/jas/rfc/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt MATCH draft-ietf-dnsext-dnssec-2535typecode-change-06.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt 08e59ec365e550de4c9923363a56b2a4 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt 08e59ec365e550de4c9923363a56b2a4 - /home/jas/rfc/draft-ietf-dnsext-dnssec-bis-updates-01.txt MATCH draft-ietf-dnsext-dnssec-bis-updates-01.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt 4dfdfecc7ce760f300b6704228306b24 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt 4dfdfecc7ce760f300b6704228306b24 - /home/jas/rfc/draft-ietf-dnsext-dnssec-experiments-01.txt MATCH draft-ietf-dnsext-dnssec-experiments-01.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt 202f1ffc23130f47793930eb8f0c5863 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt 202f1ffc23130f47793930eb8f0c5863 - /home/jas/rfc/draft-ietf-dnsext-dnssec-online-signing-00.txt MATCH draft-ietf-dnsext-dnssec-online-signing-00.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt a980c1c717d5241161c9279c98782596 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt a980c1c717d5241161c9279c98782596 - /home/jas/rfc/draft-ietf-dnsext-dnssec-opt-in-07.txt MATCH draft-ietf-dnsext-dnssec-opt-in-07.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt 26e913f86c33845a1effd5f2ce61c631 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt 26e913f86c33845a1effd5f2ce61c631 - /home/jas/rfc/draft-ietf-dnsext-dnssec-trans-02.txt MATCH draft-ietf-dnsext-dnssec-trans-02.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-ecc-key-07.txt e2a15bca8a69c3d1fd7b06be19ff25a4 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-ecc-key-07.txt e2a15bca8a69c3d1fd7b06be19ff25a4 - /home/jas/rfc/draft-ietf-dnsext-ecc-key-07.txt MATCH draft-ietf-dnsext-ecc-key-07.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-insensitive-06.txt e75c9443980a6ddd1fcb663dc513c8e5 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-insensitive-06.txt e75c9443980a6ddd1fcb663dc513c8e5 - /home/jas/rfc/draft-ietf-dnsext-insensitive-06.txt MATCH draft-ietf-dnsext-insensitive-06.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-interop3597-02.txt e088e8e48a927f5c2f645079d3f5e89c - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-interop3597-02.txt e088e8e48a927f5c2f645079d3f5e89c - /home/jas/rfc/draft-ietf-dnsext-interop3597-02.txt MATCH draft-ietf-dnsext-interop3597-02.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt 806ebe53c4fd5054ac19067afd20c8c2 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt 806ebe53c4fd5054ac19067afd20c8c2 - /home/jas/rfc/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt MATCH draft-ietf-dnsext-keyrr-key-signing-flag-12.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-mdns-43.txt ac4f4b3545cc3b1ffdd5e46c8c624457 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-mdns-43.txt ac4f4b3545cc3b1ffdd5e46c8c624457 - /home/jas/rfc/draft-ietf-dnsext-mdns-43.txt MATCH draft-ietf-dnsext-mdns-43.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-nsec3-02.txt 73b46781adb8bdd8ba091d68b7c96039 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-nsec3-02.txt 73b46781adb8bdd8ba091d68b7c96039 - /home/jas/rfc/draft-ietf-dnsext-nsec3-02.txt MATCH draft-ietf-dnsext-nsec3-02.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt f665a5fabf3df9a44bd6e82fdf72a6df - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt f665a5fabf3df9a44bd6e82fdf72a6df - /home/jas/rfc/draft-ietf-dnsext-rfc2536bis-dsa-06.txt MATCH draft-ietf-dnsext-rfc2536bis-dsa-06.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt 864c26945cb04b98c28c834e6f74582b - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt 864c26945cb04b98c28c834e6f74582b - /home/jas/rfc/draft-ietf-dnsext-rfc2538bis-04.txt MATCH draft-ietf-dnsext-rfc2538bis-04.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt d12b20e411972dc05a755258b254bbad - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt d12b20e411972dc05a755258b254bbad - /home/jas/rfc/draft-ietf-dnsext-rfc2539bis-dhk-06.txt MATCH draft-ietf-dnsext-rfc2539bis-dhk-06.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt 87f027058d5c7af0212561d7d291bcf5 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt 87f027058d5c7af0212561d7d291bcf5 - /home/jas/rfc/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt MATCH draft-ietf-dnsext-signed-nonexistence-requirements-01.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt eacec984673dd5e96bb857d63b3d2aae - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt eacec984673dd5e96bb857d63b3d2aae - /home/jas/rfc/draft-ietf-dnsext-tkey-renewal-mode-05.txt MATCH draft-ietf-dnsext-tkey-renewal-mode-05.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt ffd660bac136bacac552d599b130510a - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt ed315dca1c5c3532fa27981a31f1b145 - /home/jas/rfc/draft-ietf-dnsext-trustupdate-threshold-00.txt MISMATCH draft-ietf-dnsext-trustupdate-threshold-00.txt --- bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt 2005-07-18 09:33:00.000000000 +0200 +++ /home/jas/rfc/draft-ietf-dnsext-trustupdate-threshold-00.txt 2004-10-20 18:02:02.000000000 +0200 @@ -1380,7 +1380,7 @@ to the RFC editor. - The version you are reading is tagged as $Revision: 1.1.232.1 $. + The version you are reading is tagged as $Revision: 1.3 $. Text between square brackets, other than references, are editorial bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt /home/jas/rfc/draft-ietf-dnsext-trustupdate-threshold-00.txt differ: byte 39567, line 1383 tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt 49d898319a437089b52267165c403610 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt 49d898319a437089b52267165c403610 - /home/jas/rfc/draft-ietf-dnsext-trustupdate-timers-01.txt MATCH draft-ietf-dnsext-trustupdate-timers-01.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt 816ca3641b8cf472f9f62241e653759f - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt 816ca3641b8cf472f9f62241e653759f - /home/jas/rfc/draft-ietf-dnsext-tsig-sha-04.txt MATCH draft-ietf-dnsext-tsig-sha-04.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt a50c174f9117e54678faac927e91b3b7 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt a50c174f9117e54678faac927e91b3b7 - /home/jas/rfc/draft-ietf-dnsext-wcard-clarify-08.txt MATCH draft-ietf-dnsext-wcard-clarify-08.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt d685c23f921da4487b238c6efde8a0a1 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt d685c23f921da4487b238c6efde8a0a1 - /home/jas/rfc/draft-ietf-dnsop-bad-dns-res-04.txt MATCH draft-ietf-dnsop-bad-dns-res-04.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt f0a4a4bea68ee62ea4936ea9de15bd31 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt f0a4a4bea68ee62ea4936ea9de15bd31 - /home/jas/rfc/draft-ietf-dnsop-dnssec-operational-practices-04.txt MATCH draft-ietf-dnsop-dnssec-operational-practices-04.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt e5c8662584dc32ee2e73f7e8fb6462c6 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt e5c8662584dc32ee2e73f7e8fb6462c6 - /home/jas/rfc/draft-ietf-dnsop-inaddr-required-07.txt MATCH draft-ietf-dnsop-inaddr-required-07.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt 93fbb5307d3a7eaf417b588e379ef484 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt 93fbb5307d3a7eaf417b588e379ef484 - /home/jas/rfc/draft-ietf-dnsop-ipv6-dns-configuration-06.txt MATCH draft-ietf-dnsop-ipv6-dns-configuration-06.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt 56a2f3351cc46057c1fdcb295a5541fc - bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt 56a2f3351cc46057c1fdcb295a5541fc - /home/jas/rfc/draft-ietf-dnsop-ipv6-dns-issues-11.txt MATCH draft-ietf-dnsop-ipv6-dns-issues-11.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt 2284d0d9e799c7e248dd96760a2d39d1 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt 2284d0d9e799c7e248dd96760a2d39d1 - /home/jas/rfc/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt MATCH draft-ietf-dnsop-ipv6-transport-guidelines-01.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt 0490b9ec35b95095262fef00c7946598 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt 0490b9ec35b95095262fef00c7946598 - /home/jas/rfc/draft-ietf-dnsop-key-rollover-requirements-02.txt MATCH draft-ietf-dnsop-key-rollover-requirements-02.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-respsize-02.txt f8511904c041ab4d7f912699c9e4cf86 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-respsize-02.txt f8511904c041ab4d7f912699c9e4cf86 - /home/jas/rfc/draft-ietf-dnsop-respsize-02.txt MATCH draft-ietf-dnsop-respsize-02.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-serverid-04.txt 11fac19cbfae78a226bcd5ba167b4836 - bind-9.3.2-P1/doc/draft/draft-ietf-dnsop-serverid-04.txt 11fac19cbfae78a226bcd5ba167b4836 - /home/jas/rfc/draft-ietf-dnsop-serverid-04.txt MATCH draft-ietf-dnsop-serverid-04.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt 0e5c3987addc297c5672c8ac820d92b8 - bind-9.3.2-P1/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt 0e5c3987addc297c5672c8ac820d92b8 - /home/jas/rfc/draft-ietf-enum-e164-gstn-np-05.txt MATCH draft-ietf-enum-e164-gstn-np-05.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-ipv6-node-requirements-08.txt fd25bdeecca6eb872ca3e0c2b68343aa - bind-9.3.2-P1/doc/draft/draft-ietf-ipv6-node-requirements-08.txt fd25bdeecca6eb872ca3e0c2b68343aa - /home/jas/rfc/draft-ietf-ipv6-node-requirements-08.txt MATCH draft-ietf-ipv6-node-requirements-08.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ietf-secsh-dns-05.txt 29d23c54715ac591f81e74592660d446 - bind-9.3.2-P1/doc/draft/draft-ietf-secsh-dns-05.txt 29d23c54715ac591f81e74592660d446 - /home/jas/rfc/draft-ietf-secsh-dns-05.txt MATCH draft-ietf-secsh-dns-05.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt 5764582ea85ad8391bfda8ab76356fe8 - bind-9.3.2-P1/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt 5764582ea85ad8391bfda8ab76356fe8 - /home/jas/rfc/draft-ihren-dnsext-threshold-validation-00.txt MATCH draft-ihren-dnsext-threshold-validation-00.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-kato-dnsop-local-zones-00.txt a7a454b20ed4d4b308cdf9199bc9cd65 - bind-9.3.2-P1/doc/draft/draft-kato-dnsop-local-zones-00.txt a7a454b20ed4d4b308cdf9199bc9cd65 - /home/jas/rfc/draft-kato-dnsop-local-zones-00.txt MATCH draft-kato-dnsop-local-zones-00.txt tar xfz /data/debian/pool/main/b/bind9/bind9_9.3.2-P1.orig.tar.gz bind-9.3.2-P1/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt 5716103c9e40e46a511a2610c70c45ba - bind-9.3.2-P1/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt 5716103c9e40e46a511a2610c70c45ba - /home/jas/rfc/draft-park-ipv6-extensions-dns-pnp-00.txt MATCH draft-park-ipv6-extensions-dns-pnp-00.txt pkg cherokee ver 0.5.5-1 lastfile cherokee_0.5.5.orig.tar.gz files cherokee-0.5.5/doc/develop/draft-coar-cgi-v11-03.txt cherokee-0.5.5/doc/develop/rfc1952.txt cherokee-0.5.5/doc/develop/rfc2616.txt cherokee-0.5.5/doc/develop/rfc2817.txt tar xfz /data/debian/pool/main/c/cherokee/cherokee_0.5.5.orig.tar.gz cherokee-0.5.5/doc/develop/draft-coar-cgi-v11-03.txt 77df17ffc2d533c2add89afd81105a35 - cherokee-0.5.5/doc/develop/draft-coar-cgi-v11-03.txt 9ca9537320ad8beae773bf040c591f07 - /home/jas/rfc/draft-coar-cgi-v11-03.txt MISMATCH draft-coar-cgi-v11-03.txt --- cherokee-0.5.5/doc/develop/draft-coar-cgi-v11-03.txt 2006-04-01 16:50:27.000000000 +0200 +++ /home/jas/rfc/draft-coar-cgi-v11-03.txt 2000-07-19 16:00:00.000000000 +0200 @@ -1,5 +1,5 @@ INTERNET-DRAFT Ken A L Coar - draft-coar-cgi-v11-03.{html,txt} IBM Corporation + draft-coar-cgi-v11-03.txt IBM Corporation D.R.T. Robinson E*TRADE UK Ltd. 25 June 1999 @@ -45,7 +45,7 @@ Discussion of this draft occurs on the CGI-WG mailing list; see the project Web page at - for details on the + for details on the mailing list and the status of the project. Table of Contents @@ -231,7 +231,6 @@ 2. Notational Conventions and Generic Grammar - Coar, et al. INTERNET-DRAFT [Page 4] CGI/1.1 Expires: 31 December, 1999 @@ -408,7 +407,6 @@ xsafe = "$" | "-" | "_" | "." xreserved = ";" | "/" | "?" | ":" | "@" | "&" - Coar, et al. INTERNET-DRAFT [Page 7] CGI/1.1 Expires: 31 December, 1999 @@ -644,7 +642,6 @@ segment = *pchar pchar = - Coar, et al. INTERNET-DRAFT [Page 11] CGI/1.1 Expires: 31 December, 1999 @@ -679,7 +676,6 @@ http://somehost.com/cgi-bin/somescript/this%2eis%2epath%2einfo - the PATH_INFO component would be decoded, and the result parsed as though it were a request for the following: @@ -762,7 +758,6 @@ REMOTE_IDENT = *CHAR - Coar, et al. INTERNET-DRAFT [Page 13] CGI/1.1 Expires: 31 December, 1999 @@ -1242,7 +1237,6 @@ AUTH_TYPE (section 6.1.1) REMOTE_HOST (section 6.1.10) - In addition, servers SHOULD provide metavariables for all fields present in the HTTP request header, with the exception of those involved with access control. Servers MAY at their @@ -1599,54 +1593,4 @@ Fax: +44 (1223) 506288 Email: drtr@etrade.co.uk - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Coar, et al. INTERNET-DRAFT [Page 28] - cherokee-0.5.5/doc/develop/draft-coar-cgi-v11-03.txt /home/jas/rfc/draft-coar-cgi-v11-03.txt differ: byte 99, line 2 tar xfz /data/debian/pool/main/c/cherokee/cherokee_0.5.5.orig.tar.gz cherokee-0.5.5/doc/develop/rfc1952.txt 7c4ee539faa6c908c3860588df424be1 - cherokee-0.5.5/doc/develop/rfc1952.txt 7c4ee539faa6c908c3860588df424be1 - /home/jas/rfc/rfc1952.txt MATCH rfc1952.txt tar xfz /data/debian/pool/main/c/cherokee/cherokee_0.5.5.orig.tar.gz cherokee-0.5.5/doc/develop/rfc2616.txt 9fa63f5083e4d2112d2e71b008e387e8 - cherokee-0.5.5/doc/develop/rfc2616.txt 9fa63f5083e4d2112d2e71b008e387e8 - /home/jas/rfc/rfc2616.txt MATCH rfc2616.txt tar xfz /data/debian/pool/main/c/cherokee/cherokee_0.5.5.orig.tar.gz cherokee-0.5.5/doc/develop/rfc2817.txt 05cb3db005513992813a9507dbfe3da7 - cherokee-0.5.5/doc/develop/rfc2817.txt 05cb3db005513992813a9507dbfe3da7 - /home/jas/rfc/rfc2817.txt MATCH rfc2817.txt pkg dante ver 1.1.18-2 lastfile dante_1.1.18.orig.tar.gz files dante-1.1.18/doc/rfc1928.txt dante-1.1.18/doc/rfc1929.txt tar xfz /data/debian/pool/main/d/dante/dante_1.1.18.orig.tar.gz dante-1.1.18/doc/rfc1928.txt ab640b10e71a9a54395c3a579684d4e8 - dante-1.1.18/doc/rfc1928.txt ab640b10e71a9a54395c3a579684d4e8 - /home/jas/rfc/rfc1928.txt MATCH rfc1928.txt tar xfz /data/debian/pool/main/d/dante/dante_1.1.18.orig.tar.gz dante-1.1.18/doc/rfc1929.txt 66ba166825b661664eb5160747b85b30 - dante-1.1.18/doc/rfc1929.txt 66ba166825b661664eb5160747b85b30 - /home/jas/rfc/rfc1929.txt MATCH rfc1929.txt pkg dhcp ver 2.0pl5-19.4 lastfile dhcp_2.0pl5.orig.tar.gz files dhcp-2.0pl5/doc/rfc2131.txt dhcp-2.0pl5/doc/rfc2132.txt dhcp-2.0pl5/doc/rfc951.txt tar xfz /data/debian/pool/main/d/dhcp/dhcp_2.0pl5.orig.tar.gz dhcp-2.0pl5/doc/rfc2131.txt e613923cffa21ad97b5095fb347a068f - dhcp-2.0pl5/doc/rfc2131.txt e613923cffa21ad97b5095fb347a068f - /home/jas/rfc/rfc2131.txt MATCH rfc2131.txt tar xfz /data/debian/pool/main/d/dhcp/dhcp_2.0pl5.orig.tar.gz dhcp-2.0pl5/doc/rfc2132.txt cd3c902afab4260aece7e4e674bc83d8 - dhcp-2.0pl5/doc/rfc2132.txt cd3c902afab4260aece7e4e674bc83d8 - /home/jas/rfc/rfc2132.txt MATCH rfc2132.txt tar xfz /data/debian/pool/main/d/dhcp/dhcp_2.0pl5.orig.tar.gz dhcp-2.0pl5/doc/rfc951.txt 9df4c6abdc1241b61eff00b3fedef6c9 - dhcp-2.0pl5/doc/rfc951.txt 9df4c6abdc1241b61eff00b3fedef6c9 - /home/jas/rfc/rfc951.txt MATCH rfc951.txt pkg dictd ver 1.10.2-3 lastfile dictd_1.10.2.orig.tar.gz files dictd-1.10.2/doc/rfc2229.txt tar xfz /data/debian/pool/main/d/dictd/dictd_1.10.2.orig.tar.gz dictd-1.10.2/doc/rfc2229.txt b6f6fe69fcc9b1c587f98886ab9640da - dictd-1.10.2/doc/rfc2229.txt b6f6fe69fcc9b1c587f98886ab9640da - /home/jas/rfc/rfc2229.txt MATCH rfc2229.txt pkg dnswalk ver 2.0.2-8 lastfile dnswalk_2.0.2.orig.tar.gz files dnswalk-2.0.2.orig/rfc1912.txt tar xfz /data/debian/pool/main/d/dnswalk/dnswalk_2.0.2.orig.tar.gz dnswalk-2.0.2.orig/rfc1912.txt c22968ec71bcea98253316226dab7cba - dnswalk-2.0.2.orig/rfc1912.txt c22968ec71bcea98253316226dab7cba - /home/jas/rfc/rfc1912.txt MATCH rfc1912.txt pkg e2fsprogs ver 1.39-1 lastfile e2fsprogs_1.39.orig.tar.gz files e2fsprogs-1.39/doc/draft-leach-uuids-guids-01.txt tar xfz /data/debian/pool/main/e/e2fsprogs/e2fsprogs_1.39.orig.tar.gz e2fsprogs-1.39/doc/draft-leach-uuids-guids-01.txt f3a365522eafa24367a6d4e5364b6e0e - e2fsprogs-1.39/doc/draft-leach-uuids-guids-01.txt f3a365522eafa24367a6d4e5364b6e0e - /home/jas/rfc/draft-leach-uuids-guids-01.txt MATCH draft-leach-uuids-guids-01.txt pkg erlang ver 1:11.b.1-1 lastfile erlang_11.b.1.orig.tar.gz files otp_src_R11B-1/lib/megaco/doc/standard/draft-ietf-megaco-h248v2-04.txt otp_src_R11B-1/lib/megaco/doc/standard/rfc2327.txt otp_src_R11B-1/lib/megaco/doc/standard/rfc3525.txt otp_src_R11B-1/lib/megaco/doc/standard/rfc3266.txt otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.txt otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.txt otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-04.txt otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/megaco/doc/standard/draft-ietf-megaco-h248v2-04.txt f85c898d1a4e229451bf3dd966ea66f4 - otp_src_R11B-1/lib/megaco/doc/standard/draft-ietf-megaco-h248v2-04.txt f85c898d1a4e229451bf3dd966ea66f4 - /home/jas/rfc/draft-ietf-megaco-h248v2-04.txt MATCH draft-ietf-megaco-h248v2-04.txt tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/megaco/doc/standard/rfc2327.txt d274633e715c4bc2dae059ecda7dd917 - otp_src_R11B-1/lib/megaco/doc/standard/rfc2327.txt d274633e715c4bc2dae059ecda7dd917 - /home/jas/rfc/rfc2327.txt MATCH rfc2327.txt tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/megaco/doc/standard/rfc3525.txt 3de5e8aef94e4e426663c6d8065c9287 - otp_src_R11B-1/lib/megaco/doc/standard/rfc3525.txt 3de5e8aef94e4e426663c6d8065c9287 - /home/jas/rfc/rfc3525.txt MATCH rfc3525.txt tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/megaco/doc/standard/rfc3266.txt 88daa9072945924cc4f87d2167c22c00 - otp_src_R11B-1/lib/megaco/doc/standard/rfc3266.txt 88daa9072945924cc4f87d2167c22c00 - /home/jas/rfc/rfc3266.txt MATCH rfc3266.txt tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt 01f2fb2fcd0589a3abbd870b087f9852 - otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt 00d7f76feb49fdd93b5344a677f930de - /home/jas/rfc/draft-ietf-secsh-architecture-15.txt MISMATCH draft-ietf-secsh-architecture-15.txt --- otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt 2004-09-14 14:09:00.000000000 +0200 +++ /home/jas/rfc/draft-ietf-secsh-architecture-15.txt 2004-03-29 05:54:34.000000000 +0200 @@ -1,6 +1,3 @@ - - - Network Working Group T. Ylonen Internet-Draft SSH Communications Security Corp Expires: March 31, 2004 D. Moffat, Ed. otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt /home/jas/rfc/draft-ietf-secsh-architecture-15.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.txt 31021c2c75d25a1b2db83270e56ec610 - otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.txt 6ac774171fca95282cecda539756f44d - /home/jas/rfc/draft-ietf-secsh-filexfer-02.txt MISMATCH draft-ietf-secsh-filexfer-02.txt --- otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.txt 2004-09-14 14:09:03.000000000 +0200 +++ /home/jas/rfc/draft-ietf-secsh-filexfer-02.txt 2002-06-05 16:00:00.000000000 +0200 @@ -1,6 +1,5 @@ - Network Working Group T. Ylonen Internet-Draft S. Lehtinen Expires: April 1, 2002 SSH Communications Security Corp otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.txt /home/jas/rfc/draft-ietf-secsh-filexfer-02.txt differ: byte 3, line 3 tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt d1c4d151ca569ded6a05b1974b6519a5 - otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt b3382a576b74f32c483a9b6399c65a65 - /home/jas/rfc/draft-ietf-secsh-userauth-18.txt MISMATCH draft-ietf-secsh-userauth-18.txt --- otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt 2004-09-14 14:09:11.000000000 +0200 +++ /home/jas/rfc/draft-ietf-secsh-userauth-18.txt 2004-03-29 05:54:34.000000000 +0200 @@ -1,6 +1,3 @@ - - - Network Working Group T. Ylonen Internet-Draft SSH Communications Security Corp Expires: March 2, 2003 D. Moffat, Ed. otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt /home/jas/rfc/draft-ietf-secsh-userauth-18.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.txt d77bdfbc6674e7d3e44193306ec51299 - otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.txt d77bdfbc6674e7d3e44193306ec51299 - /home/jas/rfc/draft-ietf-secsh-filexfer-03.txt MATCH draft-ietf-secsh-filexfer-03.txt tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-04.txt 2bd3dcaf6a2ae2bea6e33c2656d923eb - otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-04.txt 2bd3dcaf6a2ae2bea6e33c2656d923eb - /home/jas/rfc/draft-ietf-secsh-filexfer-04.txt MATCH draft-ietf-secsh-filexfer-04.txt tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt 17daacc337a12b496d58cd6ab9a2c049 - otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt fec7a790c46405d5d42534aa7a4dc63b - /home/jas/rfc/draft-ietf-secsh-transport-17.txt MISMATCH draft-ietf-secsh-transport-17.txt --- otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt 2004-09-14 14:09:09.000000000 +0200 +++ /home/jas/rfc/draft-ietf-secsh-transport-17.txt 2004-03-29 05:54:34.000000000 +0200 @@ -1,6 +1,3 @@ - - - Network Working Group T. Ylonen Internet-Draft SSH Communications Security Corp Expires: March 31, 2004 D. Moffat, Editor, Ed. otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt /home/jas/rfc/draft-ietf-secsh-transport-17.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/e/erlang/erlang_11.b.1.orig.tar.gz otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt d9647ae0445aa91dc0acd90b26e21157 - otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt ebcecaa5f45bdb8aced976ddd5f706f1 - /home/jas/rfc/draft-ietf-secsh-connect-18.txt MISMATCH draft-ietf-secsh-connect-18.txt --- otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt 2004-09-14 14:09:02.000000000 +0200 +++ /home/jas/rfc/draft-ietf-secsh-connect-18.txt 2004-03-29 05:54:34.000000000 +0200 @@ -1,6 +1,3 @@ - - - Network Working Group T. Ylonen Internet-Draft SSH Communications Security Corp Expires: March 31, 2004 D. Moffat, Editor, Ed. otp_src_R11B-1/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt /home/jas/rfc/draft-ietf-secsh-connect-18.txt differ: byte 1, line 1 pkg evolution-exchange ver 2.6.3-1 lastfile evolution-exchange_2.6.3.orig.tar.gz files evolution-exchange-2.6.3/docs/ietf/draft-brezak-spnego-http-04.txt evolution-exchange-2.6.3/docs/ietf/rfc2518.txt evolution-exchange-2.6.3/docs/ietf/rfc2616.txt evolution-exchange-2.6.3/docs/ietf/draft-hopmann-collection-props-00.txt evolution-exchange-2.6.3/docs/ietf/draft-goland-http-udp-00.txt evolution-exchange-2.6.3/docs/ietf/draft-davis-dasl-protocol-00.txt tar xfz /data/debian/pool/main/e/evolution-exchange/evolution-exchange_2.6.3.orig.tar.gz evolution-exchange-2.6.3/docs/ietf/draft-brezak-spnego-http-04.txt 1292c1c81a3e34b7e30524986e0a980f - evolution-exchange-2.6.3/docs/ietf/draft-brezak-spnego-http-04.txt 1292c1c81a3e34b7e30524986e0a980f - /home/jas/rfc/draft-brezak-spnego-http-04.txt MATCH draft-brezak-spnego-http-04.txt tar xfz /data/debian/pool/main/e/evolution-exchange/evolution-exchange_2.6.3.orig.tar.gz evolution-exchange-2.6.3/docs/ietf/rfc2518.txt a49c2a00897f41160c3be233e3dede80 - evolution-exchange-2.6.3/docs/ietf/rfc2518.txt a49c2a00897f41160c3be233e3dede80 - /home/jas/rfc/rfc2518.txt MATCH rfc2518.txt tar xfz /data/debian/pool/main/e/evolution-exchange/evolution-exchange_2.6.3.orig.tar.gz evolution-exchange-2.6.3/docs/ietf/rfc2616.txt 9fa63f5083e4d2112d2e71b008e387e8 - evolution-exchange-2.6.3/docs/ietf/rfc2616.txt 9fa63f5083e4d2112d2e71b008e387e8 - /home/jas/rfc/rfc2616.txt MATCH rfc2616.txt tar xfz /data/debian/pool/main/e/evolution-exchange/evolution-exchange_2.6.3.orig.tar.gz evolution-exchange-2.6.3/docs/ietf/draft-hopmann-collection-props-00.txt 827510b652df6623444f9a762930ca78 - evolution-exchange-2.6.3/docs/ietf/draft-hopmann-collection-props-00.txt 1df6288d7ddb3da7ff9607bd13692f2d - /home/jas/rfc/draft-hopmann-collection-props-00.txt MISMATCH draft-hopmann-collection-props-00.txt --- evolution-exchange-2.6.3/docs/ietf/draft-hopmann-collection-props-00.txt 2004-05-11 17:09:03.000000000 +0200 +++ /home/jas/rfc/draft-hopmann-collection-props-00.txt 2002-04-09 16:00:00.000000000 +0200 @@ -1,3 +1,14 @@ +HTTP/1.1 200 OK +Date: Tue, 09 Apr 2002 00:26:44 GMT +Server: Apache/1.3.20 (Unix) +Last-Modified: Wed, 06 Jan 1999 18:24:32 GMT +ETag: "2e79bc-4370-3693aa60" +Accept-Ranges: bytes +Content-Length: 17264 +Connection: close +Content-Type: text/plain + + WebDAV Working Group Alex Hopmann, Microsoft Corporation Internet Draft Lisa Lippert, Microsoft Corporation Document: draft-hopmann-collection-props-00.txt Dec, 1998 @@ -204,8 +215,7 @@ A Structured document may contain collections. A structured document must have a default document (if the "defaultdocument" property is absent, the default - document is assumed by the client to be index.html). -Definition: + document is assumed by the client to be index.html). Definition: 1.8. The hassubs Property @@ -353,4 +363,3 @@ Redmond, WA 98052 Email: lisal@microsoft.com - evolution-exchange-2.6.3/docs/ietf/draft-hopmann-collection-props-00.txt /home/jas/rfc/draft-hopmann-collection-props-00.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/e/evolution-exchange/evolution-exchange_2.6.3.orig.tar.gz evolution-exchange-2.6.3/docs/ietf/draft-goland-http-udp-00.txt dbc46e68b6091cd2502821d029d26cad - evolution-exchange-2.6.3/docs/ietf/draft-goland-http-udp-00.txt dbc46e68b6091cd2502821d029d26cad - /home/jas/rfc/draft-goland-http-udp-00.txt MATCH draft-goland-http-udp-00.txt tar xfz /data/debian/pool/main/e/evolution-exchange/evolution-exchange_2.6.3.orig.tar.gz evolution-exchange-2.6.3/docs/ietf/draft-davis-dasl-protocol-00.txt 2035c70190c1c2ca65529ffc1548d207 - evolution-exchange-2.6.3/docs/ietf/draft-davis-dasl-protocol-00.txt ~/rfc /data/debian/bad/evolution-exchange-2.6.3-1 --15:17:50-- http://bgp.potaroo.net/ietf/all-ids//draft-davis-dasl-protocol-00.txt => `draft-davis-dasl-protocol-00.txt' Resolving bgp.potaroo.net... 203.50.0.159 Connecting to bgp.potaroo.net|203.50.0.159|:80... connected. HTTP request sent, awaiting response... 404 Not Found 15:17:51 ERROR 404: Not Found. FETCH-FAIL draft-davis-dasl-protocol-00.txt /data/debian/bad/evolution-exchange-2.6.3-1 d41d8cd98f00b204e9800998ecf8427e - /home/jas/rfc/draft-davis-dasl-protocol-00.txt MISMATCH draft-davis-dasl-protocol-00.txt diff: /home/jas/rfc/draft-davis-dasl-protocol-00.txt: No such file or directory cmp: /home/jas/rfc/draft-davis-dasl-protocol-00.txt: No such file or directory pkg firedns ver 0.9.12-6 lastfile firedns_0.9.12.orig.tar.gz files firedns/doc/spf-draft-20040209.txt tar xfz /data/debian/pool/main/f/firedns/firedns_0.9.12.orig.tar.gz firedns/doc/spf-draft-20040209.txt 0987f531713c2f41ed8d331abf2594b5 - firedns/doc/spf-draft-20040209.txt ~/rfc /data/debian/bad/firedns-0.9.12-6 --15:17:52-- http://bgp.potaroo.net/ietf/all-ids//spf-draft-20040209.txt => `spf-draft-20040209.txt' Resolving bgp.potaroo.net... 203.50.0.159 Connecting to bgp.potaroo.net|203.50.0.159|:80... connected. HTTP request sent, awaiting response... 404 Not Found 15:17:53 ERROR 404: Not Found. FETCH-FAIL spf-draft-20040209.txt /data/debian/bad/firedns-0.9.12-6 d41d8cd98f00b204e9800998ecf8427e - /home/jas/rfc/spf-draft-20040209.txt MISMATCH spf-draft-20040209.txt diff: /home/jas/rfc/spf-draft-20040209.txt: No such file or directory cmp: /home/jas/rfc/spf-draft-20040209.txt: No such file or directory pkg firefox ver 1.5.dfsg+1.5.0.7-1 lastfile firefox_1.5.dfsg+1.5.0.7.orig.tar.gz files firefox-1.5.dfsg+1.5.0.7.orig/directory/c-sdk/ldap/docs/draft-ietf-ldapext-ldap-c-api-05.txt firefox-1.5.dfsg+1.5.0.7.orig/netwerk/protocol/ftp/doc/rfc959.txt tar xfz /data/debian/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.7.orig.tar.gz firefox-1.5.dfsg+1.5.0.7.orig/directory/c-sdk/ldap/docs/draft-ietf-ldapext-ldap-c-api-05.txt 94d7310dfd0f455b4db3540285037169 - firefox-1.5.dfsg+1.5.0.7.orig/directory/c-sdk/ldap/docs/draft-ietf-ldapext-ldap-c-api-05.txt b88674b6ec99af3da549509f661eb056 - /home/jas/rfc/draft-ietf-ldapext-ldap-c-api-05.txt MISMATCH draft-ietf-ldapext-ldap-c-api-05.txt firefox-1.5.dfsg+1.5.0.7.orig/directory/c-sdk/ldap/docs/draft-ietf-ldapext-ldap-c-api-05.txt /home/jas/rfc/draft-ietf-ldapext-ldap-c-api-05.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.7.orig.tar.gz firefox-1.5.dfsg+1.5.0.7.orig/netwerk/protocol/ftp/doc/rfc959.txt 61fe27e8453911367a6b1efdb218faa7 - firefox-1.5.dfsg+1.5.0.7.orig/netwerk/protocol/ftp/doc/rfc959.txt 61fe27e8453911367a6b1efdb218faa7 - /home/jas/rfc/rfc959.txt MATCH rfc959.txt pkg gidentd ver 0.4.5-7.2 lastfile gidentd_0.4.5.orig.tar.gz files gidentd-0.4.5/docs/rfc1413.txt tar xfz /data/debian/pool/main/g/gidentd/gidentd_0.4.5.orig.tar.gz gidentd-0.4.5/docs/rfc1413.txt 7b72fafe2fb39b86316142416d248d22 - gidentd-0.4.5/docs/rfc1413.txt 7b72fafe2fb39b86316142416d248d22 - /home/jas/rfc/rfc1413.txt MATCH rfc1413.txt pkg gnome-utils ver 2.14.0-2 lastfile gnome-utils_2.14.0.orig.tar.gz files gnome-utils-2.14.0/gnome-dictionary/docs/rfc2229.txt tar xfz /data/debian/pool/main/g/gnome-utils/gnome-utils_2.14.0.orig.tar.gz gnome-utils-2.14.0/gnome-dictionary/docs/rfc2229.txt b6f6fe69fcc9b1c587f98886ab9640da - gnome-utils-2.14.0/gnome-dictionary/docs/rfc2229.txt b6f6fe69fcc9b1c587f98886ab9640da - /home/jas/rfc/rfc2229.txt MATCH rfc2229.txt pkg gtk-gnutella ver 0.96.1svn11444-3 lastfile gtk-gnutella_0.96.1svn11444.orig.tar.gz files gtk-gnutella-0.96.1svn11444/doc/gnutella/draft-nielsen-dime-02.txt gtk-gnutella-0.96.1svn11444/doc/other/rfc3548.txt tar xfz /data/debian/pool/main/g/gtk-gnutella/gtk-gnutella_0.96.1svn11444.orig.tar.gz gtk-gnutella-0.96.1svn11444/doc/gnutella/draft-nielsen-dime-02.txt c4335eca38ed30e286586e70fb15b61c - gtk-gnutella-0.96.1svn11444/doc/gnutella/draft-nielsen-dime-02.txt c4335eca38ed30e286586e70fb15b61c - /home/jas/rfc/draft-nielsen-dime-02.txt MATCH draft-nielsen-dime-02.txt tar xfz /data/debian/pool/main/g/gtk-gnutella/gtk-gnutella_0.96.1svn11444.orig.tar.gz gtk-gnutella-0.96.1svn11444/doc/other/rfc3548.txt 34e15bccaef79dc2fb8cefe2e467a04a - gtk-gnutella-0.96.1svn11444/doc/other/rfc3548.txt c0219adc099312bb73dc08ecb95f32b2 - /home/jas/rfc/rfc3548.txt MISMATCH rfc3548.txt --- gtk-gnutella-0.96.1svn11444/doc/other/rfc3548.txt 2006-08-07 02:00:50.000000000 +0200 +++ /home/jas/rfc/rfc3548.txt 2003-07-03 23:00:12.000000000 +0200 @@ -1,8 +1,14 @@ + + + + + Network Working Group S. Josefsson, Ed. Request for Comments: 3548 July 2003 Category: Informational + The Base16, Base32, and Base64 Data Encodings Status of this Memo @@ -44,10 +50,16 @@ 11. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 12 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 + + + + + Josefsson Informational [Page 1] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + 1. Introduction Base encoding of data is used in many situations to store or transfer @@ -92,10 +104,18 @@ directs base encoders to add line feeds after a specific number of characters. + + + + + + + Josefsson Informational [Page 2] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + 2.2. Padding of encoded data In some circumstances, the use of padding ("=") in base encoded data @@ -142,10 +162,16 @@ O, and 1 as I or L depending on case. (However, by default it should not, see previous section.) + + + + + Josefsson Informational [Page 3] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + o Encoded into structures that place other requirements. For base 16 and base 32, this determines the use of upper- or lowercase alphabets. For base 64, the non-alphanumeric characters (in @@ -181,10 +207,27 @@ characters. The character referenced by the index is placed in the output string. + + + + + + + + + + + + + + + + Josefsson Informational [Page 4] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + Table 1: The Base 64 Alphabet Value Encoding Value Encoding Value Encoding Value Encoding @@ -227,10 +270,20 @@ final unit of encoded output will be three characters followed by one "=" padding character. + + + + + + + + + Josefsson Informational [Page 5] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + 4. Base 64 Encoding with URL and Filename Safe Alphabet The Base 64 encoding with an URL and filename safe alphabet has been @@ -278,10 +331,15 @@ octets in a form that needs to be case insensitive but need not be humanly readable. + + + + Josefsson Informational [Page 6] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + A 33-character subset of US-ASCII is used, enabling 5 bits to be represented per printable character. (The extra 33rd character, "=", is used to signify a special processing function.) @@ -315,6 +373,7 @@ 7 H 16 Q 25 Z 8 I 17 R 26 2 + Special processing is performed if fewer than 40 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a body. When fewer than 40 input bits @@ -328,10 +387,15 @@ bits; here, the final unit of encoded output will be an integral multiple of 8 characters with no "=" padding, + + + + Josefsson Informational [Page 7] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by six "=" padding characters, @@ -379,10 +443,15 @@ Unlike base 32 and base 64, no special padding is necessary since a full code word is always available. + + + + Josefsson Informational [Page 8] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + 7. Illustrations and examples To translate between binary and a base encoding, the input is stored @@ -414,10 +483,31 @@ <====> 2nd character <===> 1st character + + + + + + + + + + + + + + + + + + + + Josefsson Informational [Page 9] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + The following example of Base64 data is from [4]. Input data: 0x14fb9c03d97e @@ -467,10 +557,13 @@ confidentiality. This has been known to cause security incidents when, e.g., a user reports details of a network protocol exchange + + Josefsson Informational [Page 10] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + (perhaps to illustrate some other problem) and accidentally reveals the password because she is unaware that the base encoding does not protect the password. @@ -518,19 +611,71 @@ specific uses of various base encodings. The author acknowledges the RSA Laboratories for supporting the work that led to this document. + + + + Josefsson Informational [Page 11] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + 11. Editor's Address Simon Josefsson EMail: simon@josefsson.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Josefsson Informational [Page 12] RFC 3548 The Base16, Base32, and Base64 Data Encodings July 2003 + 12. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. @@ -564,5 +709,23 @@ Funding for the RFC Editor function is currently provided by the Internet Society. + + + + + + + + + + + + + + + + + + Josefsson Informational [Page 13] gtk-gnutella-0.96.1svn11444/doc/other/rfc3548.txt /home/jas/rfc/rfc3548.txt differ: byte 2, line 2 pkg httptunnel ver 3.3-3 lastfile httptunnel_3.3.orig.tar.gz files httptunnel-3.3/doc/rfc1945.txt httptunnel-3.3/doc/rfc2068.txt httptunnel-3.3/doc/rfc2045.txt tar xfz /data/debian/pool/main/h/httptunnel/httptunnel_3.3.orig.tar.gz httptunnel-3.3/doc/rfc1945.txt c53fa98f094c1d0df6bd4107c514184d - httptunnel-3.3/doc/rfc1945.txt c53fa98f094c1d0df6bd4107c514184d - /home/jas/rfc/rfc1945.txt MATCH rfc1945.txt tar xfz /data/debian/pool/main/h/httptunnel/httptunnel_3.3.orig.tar.gz httptunnel-3.3/doc/rfc2068.txt 6d2dfe825deb83d36c12fd5a8079dc67 - httptunnel-3.3/doc/rfc2068.txt 6d2dfe825deb83d36c12fd5a8079dc67 - /home/jas/rfc/rfc2068.txt MATCH rfc2068.txt tar xfz /data/debian/pool/main/h/httptunnel/httptunnel_3.3.orig.tar.gz httptunnel-3.3/doc/rfc2045.txt d61fb11bcd7b60142207209bcfa7f4b1 - httptunnel-3.3/doc/rfc2045.txt d61fb11bcd7b60142207209bcfa7f4b1 - /home/jas/rfc/rfc2045.txt MATCH rfc2045.txt pkg imapsync ver 1.182-1 lastfile imapsync_1.182.orig.tar.gz files imapsync-1.182/rfc2342.txt tar xfz /data/debian/pool/main/i/imapsync/imapsync_1.182.orig.tar.gz imapsync-1.182/rfc2342.txt 2f0f339458a114b666cee21fcfdf17e6 - imapsync-1.182/rfc2342.txt 2f0f339458a114b666cee21fcfdf17e6 - /home/jas/rfc/rfc2342.txt MATCH rfc2342.txt pkg inetutils ver 2:1.4.3+20060719-2 lastfile inetutils_1.4.3+20060719.orig.tar.gz files inetutils-1.4.3+20060719/doc/rfc/rfc1282.txt tar xfz /data/debian/pool/main/i/inetutils/inetutils_1.4.3+20060719.orig.tar.gz inetutils-1.4.3+20060719/doc/rfc/rfc1282.txt fce0ba398792114ca8a0735cb245e725 - inetutils-1.4.3+20060719/doc/rfc/rfc1282.txt fce0ba398792114ca8a0735cb245e725 - /home/jas/rfc/rfc1282.txt MATCH rfc1282.txt pkg ircd-hybrid ver 1:7.2.2-2 lastfile ircd-hybrid_7.2.2.orig.tar.gz files ircd-hybrid-7.2.2/doc/technical/rfc1459.txt ircd-hybrid-7.2.2/doc/technical/draft-mitchell-irc-capabilities-01.txt ircd-hybrid-7.2.2/doc/technical/rfc2812.txt ircd-hybrid-7.2.2/doc/technical/rfc2813.txt tar xfz /data/debian/pool/main/i/ircd-hybrid/ircd-hybrid_7.2.2.orig.tar.gz ircd-hybrid-7.2.2/doc/technical/rfc1459.txt 1f633fb523d13de271531ae829ed1081 - ircd-hybrid-7.2.2/doc/technical/rfc1459.txt 946f69c2f13c4b2d5f51a039bff30d2e - /home/jas/rfc/rfc1459.txt MISMATCH rfc1459.txt --- ircd-hybrid-7.2.2/doc/technical/rfc1459.txt 2006-07-17 08:31:31.000000000 +0200 +++ /home/jas/rfc/rfc1459.txt 1993-05-25 00:37:12.000000000 +0200 @@ -1,9 +1,14 @@ -$Id: rfc1459.txt 33 2005-10-02 20:50:00Z knight $ + + + + + Network Working Group J. Oikarinen Request for Comments: 1459 D. Reed May 1993 + Internet Relay Chat Protocol Status of This Memo @@ -48,6 +53,13 @@ 3.2.3 To a host/server mask .............................. 12 3.3 One to all .............................................. 12 + + +Oikarinen & Reed [Page 1] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 3.3.1 Client to Client ................................... 12 3.3.2 Clients to Server .................................. 12 3.3.3 Server to Server ................................... 12 @@ -97,6 +109,13 @@ 5.2 Rehash command .......................................... 39 5.3 Restart command ......................................... 39 + + +Oikarinen & Reed [Page 2] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 5.4 Summon message .......................................... 40 5.5 Users message ........................................... 40 5.6 Operwall command ........................................ 41 @@ -140,6 +159,19 @@ 11. Security Considerations .................................... 65 12. Authors' Addresses ......................................... 65 + + + + + + + + +Oikarinen & Reed [Page 3] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 1. INTRODUCTION The IRC (Internet Relay Chat) protocol has been designed over a @@ -166,6 +198,7 @@ Fig. 1] where each server acts as a central node for the rest of the net it sees. + [ Server 15 ] [ Server 13 ] [ Server 14] / \ / / \ / @@ -188,6 +221,13 @@ [ Fig. 1. Format of IRC server network ] + + +Oikarinen & Reed [Page 4] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 1.2 Clients A client is anything connecting to a server that is not another @@ -237,6 +277,13 @@ There are two types of channels allowed by this protocol. One is a distributed channel which is known to all the servers that are + + +Oikarinen & Reed [Page 5] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + connected to the network. These channels are marked by the first character being a only clients on the server where it exists may join it. These are distinguished by a leading '&' character. On top of @@ -285,6 +332,14 @@ INVITE - Invite a client to an invite-only channel (mode +i) TOPIC - Change the channel topic in a mode +t channel + + + +Oikarinen & Reed [Page 6] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + A channel operator is identified by the '@' symbol next to their nickname whenever it is associated with a channel (ie replies to the NAMES, WHO and WHOIS commands). @@ -334,6 +389,13 @@ message itself. There must be no gap (whitespace) between the colon and the prefix. The prefix is used by servers to indicate the true + + +Oikarinen & Reed [Page 7] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + origin of the message. If the prefix is missing from the message, it is assumed to have originated from the connection from which it was received. Clients should not use prefix when sending a message from @@ -369,6 +431,7 @@ The BNF representation for this is: + ::= [':' ] ::= | [ '!' ] [ '@' ] ::= { } | @@ -382,6 +445,13 @@ ::= CR LF + + +Oikarinen & Reed [Page 8] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + NOTES: 1) is consists only of SPACE character(s) (0x20). @@ -431,6 +501,13 @@ ::= '0' ... '9' ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}' + + +Oikarinen & Reed [Page 9] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + ::= @@ -453,6 +530,8 @@ organization of the IRC protocol and how the current implementations deliver different classes of messages. + + 1--\ A D---4 2--/ \ / @@ -476,6 +555,15 @@ The following examples all refer to Figure 2 above. + + + + +Oikarinen & Reed [Page 10] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + Example 1: A message between clients 1 and 2 is only seen by server A, which sends it straight to client 2. @@ -523,6 +611,15 @@ Any channel with 1 client in it. Messages to the channel go to the server and then nowhere else. + + + + +Oikarinen & Reed [Page 11] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + Example 5: 2 clients in a channel. All messages traverse a path as if they were private messages between the two clients outside a channel. @@ -572,6 +669,13 @@ servers, this is only required for any message that affects either a user, channel or server. Since these are the basic items found in + + +Oikarinen & Reed [Page 12] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + IRC, nearly all messages originating from a server are broadcast to all other connected servers. @@ -620,12 +724,21 @@ give some level of security to the actual connections. The recommended order for a client to register is as follows: + + + +Oikarinen & Reed [Page 13] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 1. Pass message 2. Nick message 3. User message 4.1.1 Password message + Command: PASS Parameters: @@ -668,6 +781,13 @@ directly connected, it may issue an ERR_NICKCOLLISION to the local client, drop the NICK command, and not generate any kills. + + +Oikarinen & Reed [Page 14] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + Numeric Replies: ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME @@ -714,12 +834,21 @@ Examples: + USER guest tolmoon tolsun :Ronnie Reagan + + +Oikarinen & Reed [Page 15] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + ; User registering themselves with a username of "guest" and real name "Ronnie Reagan". + :testnick USER guest tolmoon tolsun :Ronnie Reagan ; message between servers with the nickname for which the USER command @@ -763,12 +892,21 @@ Example: + + + +Oikarinen & Reed [Page 16] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server ; New server test.oulu.fi introducing itself and attempting to register. The name in []'s is the hostname for the host running test.oulu.fi. + :tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server ; Server tolsun.oulu.fi is our uplink for csd.bu.edu which is 5 hops away. @@ -811,6 +949,13 @@ When netsplits (disconnecting of two servers) occur, the quit message + + +Oikarinen & Reed [Page 17] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + is composed of the names of two servers involved, separated by a space. The first name is that of the server which is still connected and the second name is that of the server that has become @@ -859,6 +1004,14 @@ server connections) for all other servers which are considered to be behind that link. + + + +Oikarinen & Reed [Page 18] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + Similarly, a QUIT message must be sent to the other connected servers rest of the network on behalf of all clients behind that link. In addition to this, all channel members of a channel which lost a @@ -907,6 +1060,14 @@ 1. the user must be invited if the channel is invite-only; + + + +Oikarinen & Reed [Page 19] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 2. the user's nick/username/hostname must not match any active bans; @@ -955,6 +1116,14 @@ Command: PART Parameters: {,} + + + +Oikarinen & Reed [Page 20] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + The PART message causes the client sending the message to be removed from the list of active users for all given channels listed in the parameter string. @@ -1004,6 +1173,13 @@ m - moderated channel; l - set the user limit to channel; + + +Oikarinen & Reed [Page 21] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + b - set a ban mask to keep users out; v - give/take the ability to speak on a moderated channel; k - set a channel key (password). @@ -1053,6 +1229,13 @@ MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on + + +Oikarinen & Reed [Page 22] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + channel #Finnish. MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish. @@ -1102,6 +1285,13 @@ RPL_NOTOPIC RPL_TOPIC ERR_CHANOPRIVSNEEDED + + +Oikarinen & Reed [Page 23] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + Examples: :Wiz TOPIC #test :New topic ;User Wiz setting the topic. @@ -1151,6 +1341,13 @@ topics) as channel "Prv" unless the client generating the query is actually on that channel. Likewise, secret channels are not listed + + +Oikarinen & Reed [Page 24] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + at all unless the client is a member of the channel in question. Numeric Replies: @@ -1200,6 +1397,13 @@ The KICK command can be used to forcibly remove a user from a channel. It 'kicks them out' of the channel (forced PART). + + +Oikarinen & Reed [Page 25] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + Only a channel operator may kick another user out of a channel. Each server that receives a KICK message checks that it is valid (ie the sender is actually a channel operator) before removing @@ -1248,6 +1452,14 @@ Command: VERSION Parameters: [] + + + +Oikarinen & Reed [Page 26] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + The VERSION message is used to query the version of the server program. An optional parameter is used to query the version of the server program which a client is not directly connected to. @@ -1297,6 +1509,13 @@ for that server; l - returns a list of the server's connections, showing how + + +Oikarinen & Reed [Page 27] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + long each connection has been established and the traffic over that connection in bytes and messages for each direction; @@ -1345,6 +1564,14 @@ Examples: + + + +Oikarinen & Reed [Page 28] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + LINKS *.au ; list all servers which have a name that matches *.au; @@ -1394,6 +1621,13 @@ CONNECT tolsun.oulu.fi ; Attempt to connect a server to tolsun.oulu.fi + + +Oikarinen & Reed [Page 29] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + :WiZ CONNECT eff.org 6667 csd.bu.edu ; CONNECT attempt by WiZ to get servers eff.org and csd.bu.edu connected on port @@ -1442,6 +1676,14 @@ TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi + + + +Oikarinen & Reed [Page 30] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + :WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust 4.3.7 Admin command @@ -1491,6 +1733,13 @@ :Avalon INFO *.fi ; INFO request from Avalon for first server found to match *.fi. + + +Oikarinen & Reed [Page 31] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + INFO Angel ; request info from the server that Angel is connected to. @@ -1540,6 +1789,13 @@ PRIVMSG jto@tolsun.oulu.fi :Hello ! ; Message to a client on server + + +Oikarinen & Reed [Page 32] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + tolsun.oulu.fi with username of "jto". PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. @@ -1589,6 +1845,13 @@ common channel with the requesting client) are listed. The same result can be achieved by using a of "0" or any wildcard which + + +Oikarinen & Reed [Page 33] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + will end up matching every entry possible. The passed to WHO is matched against users' host, server, real @@ -1638,6 +1901,13 @@ RPL_WHOISIDLE ERR_NOSUCHNICK RPL_ENDOFWHOIS + + +Oikarinen & Reed [Page 34] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + Examples: WHOIS wiz ; return available user information @@ -1685,6 +1955,15 @@ Messages in this category do not fit into any of the above categories but are nonetheless still a part of and required by the protocol. + + + + +Oikarinen & Reed [Page 35] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 4.6.1 Kill message Command: KILL @@ -1721,15 +2000,26 @@ ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS ERR_NOSUCHNICK ERR_CANTKILLSERVER + KILL David (csd.bu.edu <- tolsun.oulu.fi) ; Nickname collision between csd.bu.edu and tolson.oulu.fi + NOTE: It is recommended that only Operators be allowed to kill other users with KILL message. In an ideal world not even operators would need to do this and it would be left to servers to deal with. + + + + +Oikarinen & Reed [Page 36] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 4.6.2 Ping message Command: PING @@ -1779,6 +2069,13 @@ PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to + + +Oikarinen & Reed [Page 37] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + tolsun.oulu.fi 4.6.4 Error @@ -1828,6 +2125,13 @@ Command: AWAY Parameters: [message] + + +Oikarinen & Reed [Page 38] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + With the AWAY message, clients can set an automatic reply string for any PRIVMSG commands directed at them (not to a channel they are on). The automatic reply is sent by the server to client sending the @@ -1848,6 +2152,7 @@ :WiZ AWAY ; unmark WiZ as being away. + 5.2 Rehash message Command: REHASH @@ -1876,6 +2181,13 @@ risk to allow arbitrary people to connect to a server as an operator and execute this command, causing (at least) a disruption to service. + + +Oikarinen & Reed [Page 39] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + The RESTART command must always be fully processed by the server to which the sending client is connected and not be passed onto other connected servers. @@ -1919,11 +2231,19 @@ server named "tolsun.oulu.fi" is running. + 5.5 Users Command: USERS Parameters: [] + + +Oikarinen & Reed [Page 40] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + The USERS command returns a list of users logged into the server in a similar format to who(1), rusers(1) and finger(1). Some people may disable this command on their server for security related @@ -1973,6 +2293,13 @@ CONNECT message it received and acted upon from Joshua. + + +Oikarinen & Reed [Page 41] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 5.7 Userhost message Command: USERHOST @@ -2022,6 +2349,13 @@ ISON phone trillian WiZ jarlek Avalon Angel Monstah ; Sample ISON request for 7 nicks. + + +Oikarinen & Reed [Page 42] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 6. REPLIES The following is a list of numeric replies which are generated in @@ -2071,6 +2405,13 @@ 407 ERR_TOOMANYTARGETS " :Duplicate recipients. No message \ + + +Oikarinen & Reed [Page 43] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + delivered" - Returned to a client which is attempting to send a @@ -2120,6 +2461,13 @@ 424 ERR_FILEERROR ":File error doing on " + + +Oikarinen & Reed [Page 44] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + - Generic error message used to report a failed file operation during the processing of a message. @@ -2169,6 +2517,13 @@ - Returned when a client tries to invite a user to a channel they are already on. + + +Oikarinen & Reed [Page 45] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 444 ERR_NOLOGIN " :User not logged in" @@ -2209,6 +2564,7 @@ change part of the registered details (such as password or user details from second USER message). + 463 ERR_NOPERMFORHOST ":Your host isn't among the privileged" @@ -2217,6 +2573,13 @@ connections from the host the attempted connection is tried. + + +Oikarinen & Reed [Page 46] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 464 ERR_PASSWDMISMATCH ":Password incorrect" @@ -2265,6 +2628,14 @@ are to be refused and this error returned directly to the client. + + + +Oikarinen & Reed [Page 47] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 491 ERR_NOOPERHOST ":No O-lines for your host" @@ -2314,6 +2685,13 @@ 301 RPL_AWAY " :" + + +Oikarinen & Reed [Page 48] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 305 RPL_UNAWAY ":You are no longer marked as being away" 306 RPL_NOWAWAY @@ -2363,6 +2741,13 @@ the replies RPL_WHOWASUSER, RPL_WHOISSERVER or ERR_WASNOSUCHNICK for each nickname in the presented + + +Oikarinen & Reed [Page 49] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + list. At the end of all reply batches, there must be RPL_ENDOFWHOWAS (even if there was only one reply and it was an error). @@ -2412,6 +2797,13 @@ - Reply by the server showing its version details. The is the version of the software being + + +Oikarinen & Reed [Page 50] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + used (including any patchlevel revisions) and the is used to indicate if the server is running in "debug mode". @@ -2461,6 +2853,13 @@ " " 368 RPL_ENDOFBANLIST + + +Oikarinen & Reed [Page 51] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + " :End of channel ban list" - When listing the active 'bans' for a given channel, @@ -2510,6 +2909,13 @@ 391 RPL_TIME + + +Oikarinen & Reed [Page 52] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + " :" - When replying to the TIME message, a server must send @@ -2559,6 +2965,13 @@ response to the TRACE message. How many are returned is dependent on the the TRACE message and + + +Oikarinen & Reed [Page 53] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + whether it was sent by an operator or not. There is no predefined order for which occurs first. Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and @@ -2607,6 +3020,14 @@ 221 RPL_UMODEIS "" + + + +Oikarinen & Reed [Page 54] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + - To answer a query about a client's own mode, RPL_UMODEIS is sent back. @@ -2652,6 +3073,17 @@ contact for the server (an email address here is required) in RPL_ADMINEMAIL. + + + + + + +Oikarinen & Reed [Page 55] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 6.3 Reserved numerics. These numerics are not described above since they fall into one of @@ -2701,6 +3133,13 @@ version 2.8. Earlier versions may implement some or all of the commands described by this document with NOTICE messages replacing + + +Oikarinen & Reed [Page 56] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + many of the numeric replies. Unfortunately, due to backward compatibility requirements, the implementation of some parts of this document varies with what is laid out. On notable difference is: @@ -2750,6 +3189,13 @@ often has large amounts of data to send (especially when a new server-server link forms) and the small buffers provided in the + + +Oikarinen & Reed [Page 57] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + kernel are not enough for the outgoing queue. To alleviate this problem, a "send queue" is used as a FIFO queue for data to be sent. A typical "send queue" may grow to 200 Kbytes on a large IRC network @@ -2799,6 +3245,13 @@ When the initiating server receives a PASS/SERVER pair, it too then + + +Oikarinen & Reed [Page 58] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + checks that the server responding is authenticated properly before accepting the connection to be that server. @@ -2844,6 +3297,17 @@ for each server behind that connection) and a list of QUITs (again, one for each client behind that connection). + + + + + + +Oikarinen & Reed [Page 59] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 8.9 Tracking nickname changes All IRC servers are required to keep a history of recent nickname @@ -2893,6 +3357,13 @@ which in essence means that the client may send 1 message every 2 + + +Oikarinen & Reed [Page 60] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + seconds without being adversely affected. 8.11 Non-blocking lookups @@ -2942,6 +3413,13 @@ * hostnames and passwords for clients which wish to be given + + +Oikarinen & Reed [Page 61] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + access to restricted operator commands. In specifying hostnames, both domain names and use of the 'dot' @@ -2991,6 +3469,13 @@ should also store the password and other characteristics of that link. + + +Oikarinen & Reed [Page 62] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + 8.12.4 Administrivia To provide accurate and valid replies to the ADMIN command (see @@ -3040,6 +3525,13 @@ several people to want to use the same nick. If a nickname is chosen by two people using this protocol, either one will not succeed or + + +Oikarinen & Reed [Page 63] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + both will removed by use of KILL (4.6.1). 9.2.2 Channels @@ -3088,6 +3580,14 @@ Newsgroup: alt.irc + + + +Oikarinen & Reed [Page 64] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + Security Considerations Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and @@ -3102,9 +3602,42 @@ Email: jto@tolsun.oulu.fi + Darren Reed 4 Pateman Street Watsonia, Victoria 3087 Australia Email: avalon@coombs.anu.edu.au + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Oikarinen & Reed [Page 65] + \ No newline at end of file ircd-hybrid-7.2.2/doc/technical/rfc1459.txt /home/jas/rfc/rfc1459.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/i/ircd-hybrid/ircd-hybrid_7.2.2.orig.tar.gz ircd-hybrid-7.2.2/doc/technical/draft-mitchell-irc-capabilities-01.txt 737732f7209e96e960ccff35ebed97b6 - ircd-hybrid-7.2.2/doc/technical/draft-mitchell-irc-capabilities-01.txt 737732f7209e96e960ccff35ebed97b6 - /home/jas/rfc/draft-mitchell-irc-capabilities-01.txt MATCH draft-mitchell-irc-capabilities-01.txt tar xfz /data/debian/pool/main/i/ircd-hybrid/ircd-hybrid_7.2.2.orig.tar.gz ircd-hybrid-7.2.2/doc/technical/rfc2812.txt 2d5fb81b5bfb39a2daeade4df32319d2 - ircd-hybrid-7.2.2/doc/technical/rfc2812.txt b0ada74a6873f84e8f84c97dcfb40054 - /home/jas/rfc/rfc2812.txt MISMATCH rfc2812.txt --- ircd-hybrid-7.2.2/doc/technical/rfc2812.txt 2006-07-17 08:31:31.000000000 +0200 +++ /home/jas/rfc/rfc2812.txt 2000-04-27 23:26:23.000000000 +0200 @@ -1,10 +1,15 @@ -$Id: rfc2812.txt 33 2005-10-02 20:50:00Z knight $ + + + + + Network Working Group C. Kalt Request for Comments: 2812 April 2000 Updates: 1459 Category: Informational + Internet Relay Chat: Client Protocol Status of this Memo @@ -48,6 +53,13 @@ 2.2 Character codes ........................................ 5 2.3 Messages ............................................... 5 + + +Kalt Informational [Page 1] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 2.3.1 Message format in Augmented BNF ................... 6 2.4 Numeric replies ........................................ 8 2.5 Wildcard expressions ................................... 9 @@ -97,6 +109,13 @@ 3.7.3 Pong message ...................................... 37 3.7.4 Error ............................................. 37 + + +Kalt Informational [Page 2] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 4. Optional features .......................................... 38 4.1 Away ................................................... 38 4.2 Rehash message ......................................... 39 @@ -140,6 +159,19 @@ netwide unique identifier (whose format depends on the type of client) and the server which introduced the client. + + + + + + + + +Kalt Informational [Page 3] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 1.2.1 Users Each user is distinguished from other users by a unique nickname @@ -189,6 +221,13 @@ separator by the protocol). A colon (':') can also be used as a delimiter for the channel mask. Channel names are case insensitive. + + +Kalt Informational [Page 4] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + See the protocol grammar rules (section 2.3.1) for the exact syntax of a channel name. @@ -235,6 +274,16 @@ fifteen (15)). The prefix, command, and all parameters are separated by one ASCII space character (0x20) each. + + + + + +Kalt Informational [Page 5] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + The presence of a prefix is indicated with a single leading ASCII colon character (':', 0x3b), which MUST be the first character of the message itself. There MUST be NO gap (whitespace) between the colon @@ -283,6 +332,14 @@ SPACE = %x20 ; space character crlf = %x0D %x0A ; "carriage return" "linefeed" + + + +Kalt Informational [Page 6] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + NOTES: 1) After extracting the parameter list, all parameters are equal whether matched by or . is just a @@ -324,6 +381,21 @@ ; any octet except NUL, BELL, CR, LF, " ", "," and ":" channelid = 5( %x41-5A / digit ) ; 5( A-Z / 0-9 ) + + + + + + + + + + +Kalt Informational [Page 7] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Other parameter syntaxes are: user = 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF ) @@ -370,6 +442,16 @@ digits rather than a string of letters. A list of different replies is supplied in section 5 (Replies). + + + + + +Kalt Informational [Page 8] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 2.5 Wildcard expressions When wildcards are allowed in a string, it is referred as a "mask". @@ -419,6 +501,13 @@ In the case of incorrect messages which use parameter lists with comma as an item separator, a reply MUST be sent for each item. + + +Kalt Informational [Page 9] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 3.1 Connection Registration The commands described here are used to register a connection with an @@ -460,12 +549,21 @@ 3.1.2 Nick message + Command: NICK Parameters: NICK command is used to give user a nickname or change the existing one. + + + +Kalt Informational [Page 10] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Numeric Replies: ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME @@ -514,6 +612,14 @@ "Ronnie Reagan", and asking to be set invisible. + + + +Kalt Informational [Page 11] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 3.1.4 Oper message Command: OPER @@ -561,6 +667,15 @@ Additional modes may be available later on. + + + + +Kalt Informational [Page 12] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + The flag 'a' SHALL NOT be toggled by the user using the MODE command, instead use of the AWAY command is REQUIRED. @@ -607,6 +722,16 @@ specify the service nickname, distribution, type and info of a new service. + + + + + +Kalt Informational [Page 13] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + The parameter is used to specify the visibility of a service. The service may only be known to servers which have a name matching the distribution. For a matching server to have knowledge @@ -649,6 +774,20 @@ :syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User syrk has quit IRC to have lunch. + + + + + + + + + +Kalt Informational [Page 14] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 3.1.8 Squit Command: SQUIT @@ -696,6 +835,15 @@ (eventually reformatted) to the user with the prefix set to the user itself. + + + + +Kalt Informational [Page 15] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + The rules governing how channels are managed are enforced by the servers. These rules are beyond the scope of this document. More details are found in "Internet Relay Chat: Channel Management" [IRC- @@ -745,6 +893,13 @@ JOIN &foo fubar ; Command to join channel &foo using key "fubar". + + +Kalt Informational [Page 16] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + JOIN #foo,&bar fubar ; Command to join channel #foo using key "fubar" and &bar using no key. @@ -794,6 +949,13 @@ "#playzone" with the message "I lost". + + +Kalt Informational [Page 17] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 3.2.3 Channel mode message Command: MODE @@ -842,6 +1004,14 @@ MODE #42 -k oulu ; Command to remove the "oulu" channel key on channel "#42". + + + +Kalt Informational [Page 18] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + MODE #eu-opers +l 10 ; Command to set the limit for the number of users on channel "#eu-opers" to 10. @@ -888,6 +1058,16 @@ requesting it. If the parameter is an empty string, the topic for that channel will be removed. + + + + + +Kalt Informational [Page 19] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Numeric Replies: ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL @@ -934,6 +1114,16 @@ ERR_TOOMANYMATCHES ERR_NOSUCHSERVER RPL_NAMREPLY RPL_ENDOFNAMES + + + + + +Kalt Informational [Page 20] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Examples: NAMES #twilight_zone,#42 ; Command to list visible users on @@ -981,6 +1171,15 @@ are allowed to invite other users. When the channel has invite-only flag set, only channel operators may issue INVITE command. + + + + +Kalt Informational [Page 21] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Only the user inviting and the user being invited will receive notification of the invitation. Other channel members are not notified. (This is unlike the MODE changes, and is occasionally the @@ -1028,6 +1227,15 @@ ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED ERR_USERNOTINCHANNEL ERR_NOTONCHANNEL + + + + +Kalt Informational [Page 22] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Examples: KICK &Melbourne Matthew ; Command to kick Matthew from @@ -1077,6 +1285,13 @@ ERR_NOSUCHNICK RPL_AWAY + + +Kalt Informational [Page 23] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Examples: :Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ? @@ -1126,6 +1341,13 @@ between NOTICE and PRIVMSG is that automatic replies MUST NEVER be sent in response to a NOTICE message. This rule applies to servers + + +Kalt Informational [Page 24] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + too - they MUST NOT send any error reply back to the client on receipt of a notice. The object of this rule is to avoid loops between clients automatically sending something in response to @@ -1174,6 +1396,14 @@ IRC network. If no parameter is given, the reply will be about the whole net. If a is specified, then the reply will only + + + +Kalt Informational [Page 25] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + concern the part of the network formed by the servers matching the mask. Finally, if the parameter is specified, the request is forwarded to that server which will generate the reply. @@ -1221,6 +1451,15 @@ Wildcards are allowed in the parameter. + + + + +Kalt Informational [Page 26] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Except for the ones below, the list of valid queries is implementation dependent. The standard queries below SHOULD be supported by the server: @@ -1270,6 +1509,13 @@ ERR_NOSUCHSERVER RPL_LINKS RPL_ENDOFLINKS + + +Kalt Informational [Page 27] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Examples: LINKS *.au ; Command to list all servers which @@ -1319,6 +1565,13 @@ ERR_NOSUCHSERVER ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS + + +Kalt Informational [Page 28] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Examples: CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect local @@ -1366,6 +1619,15 @@ RPL_TRACELINK + + + + +Kalt Informational [Page 29] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + A TRACE reply may be composed of any number of the following numeric replies. @@ -1407,6 +1669,21 @@ ADMIN syrk ; ADMIN request for the server to which the user syrk is connected + + + + + + + + + + +Kalt Informational [Page 30] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 3.4.10 Info command Command: INFO @@ -1451,6 +1728,18 @@ RPL_SERVLIST RPL_SERVLISTEND + + + + + + + +Kalt Informational [Page 31] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 3.5.2 Squery Command: SQUERY @@ -1500,6 +1789,13 @@ The passed to WHO is matched against users' host, server, real name and nickname if the channel cannot be found. + + +Kalt Informational [Page 32] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + If the "o" parameter is passed only operators are returned according to the supplied. @@ -1546,6 +1842,16 @@ RPL_WHOISIDLE ERR_NOSUCHNICK RPL_ENDOFWHOIS + + + + + +Kalt Informational [Page 33] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Examples: WHOIS wiz ; return available user information @@ -1595,6 +1901,13 @@ Messages in this category do not fit into any of the above categories but are nonetheless still a part of and REQUIRED by the protocol. + + +Kalt Informational [Page 34] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 3.7.1 Kill message Command: KILL @@ -1640,6 +1953,17 @@ ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS ERR_NOSUCHNICK ERR_CANTKILLSERVER + + + + + + +Kalt Informational [Page 35] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + NOTE: It is RECOMMENDED that only Operators be allowed to kill other users with KILL command. This command has been the subject of many @@ -1680,6 +2004,22 @@ PING :irc.funet.fi ; Ping message sent by server "irc.funet.fi" + + + + + + + + + + + +Kalt Informational [Page 36] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 3.7.3 Pong message Command: PONG @@ -1726,6 +2066,16 @@ None. + + + + + +Kalt Informational [Page 37] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Examples: ERROR :Server *.fi already exists ; ERROR message to the other server @@ -1772,6 +2122,16 @@ RPL_UNAWAY RPL_NOWAWAY + + + + + +Kalt Informational [Page 38] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Example: AWAY :Gone to lunch. Back in 5 ; Command to set away message to @@ -1790,6 +2150,7 @@ RPL_REHASHING ERR_NOPRIVILEGES + Example: REHASH ; message from user with operator @@ -1818,6 +2179,15 @@ DIE ; no parameters required. + + + + +Kalt Informational [Page 39] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 4.4 Restart message Command: RESTART @@ -1863,6 +2233,17 @@ ERR_NOLOGIN ERR_NOSUCHSERVER ERR_SUMMONDISABLED RPL_SUMMONING + + + + + + +Kalt Informational [Page 40] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + Examples: SUMMON jto ; summon user jto on the server's @@ -1912,6 +2293,13 @@ connected users who have set the 'w' user mode for themselves. (See Section 3.1.5 "User modes"). + + +Kalt Informational [Page 41] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + After implementing WALLOPS as a user command it was found that it was often and commonly abused as a means of sending a message to a lot of people. Due to this, it is RECOMMENDED that the implementation of @@ -1961,6 +2349,13 @@ on IRC. ISON only takes one (1) type of parameter: a space-separated list of nicks. For each nickname in the list that is present, the + + +Kalt Informational [Page 42] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + server adds that to its reply string. Thus the reply string may return empty (none of the given nicks are present), an exact copy of the parameter string (all of them present) or any other subset of the @@ -2009,6 +2404,14 @@ - The server sends Replies 001 to 004 to a user upon successful registration. + + + +Kalt Informational [Page 43] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 005 RPL_BOUNCE "Try server , port " @@ -2057,6 +2460,14 @@ 313 RPL_WHOISOPERATOR " :is an IRC operator" + + + +Kalt Informational [Page 44] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 317 RPL_WHOISIDLE " :seconds idle" 318 RPL_ENDOFWHOIS @@ -2104,6 +2515,15 @@ command. If there are no channels available to return, only the end reply MUST be sent. + + + + +Kalt Informational [Page 45] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 325 RPL_UNIQOPIS " " @@ -2150,6 +2570,16 @@ 349 RPL_ENDOFEXCEPTLIST " :End of channel exception list" + + + + + +Kalt Informational [Page 46] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + - When listing the 'exception masks' for a given channel, a server is required to send the list back using the RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages. A @@ -2199,6 +2629,13 @@ server back to the client. If there is no channel found as in the query, then only RPL_ENDOFNAMES is + + +Kalt Informational [Page 47] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + returned. The exception to this is when a NAMES message is sent with no parameters and all visible channels and contents are sent back in a series of @@ -2247,6 +2684,14 @@ is found, the file is displayed line by line, with each line no longer than 80 characters, using + + + +Kalt Informational [Page 48] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + RPL_MOTD format replies. These MUST be surrounded by a RPL_MOTDSTART (before the RPL_MOTDs) and an RPL_ENDOFMOTD (after). @@ -2296,6 +2741,13 @@ or a single RPL_NOUSER. Following this is RPL_ENDOFUSERS. + + +Kalt Informational [Page 49] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 200 RPL_TRACELINK "Link V @@ -2344,6 +2796,14 @@ network should reflect the actual connectivity of the servers themselves along that path. + + + +Kalt Informational [Page 50] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + RPL_TRACENEWTYPE is to be used for any connection which does not fit in the other categories but is being displayed anyway. @@ -2393,6 +2853,13 @@ 234 RPL_SERVLIST " " + + +Kalt Informational [Page 51] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 235 RPL_SERVLISTEND " :End of service listing" @@ -2442,6 +2909,13 @@ the server is in is expected, followed by details of the institution (RPL_ADMINLOC2) + + +Kalt Informational [Page 52] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + and finally the administrative contact for the server (an email address here is REQUIRED) in RPL_ADMINEMAIL. @@ -2490,6 +2964,14 @@ number of allowed channels and they try to join another channel. + + + +Kalt Informational [Page 53] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 406 ERR_WASNOSUCHNICK " :There was no such nickname" @@ -2538,6 +3020,14 @@ are returned when an invalid use of "PRIVMSG $" or "PRIVMSG #" is attempted. + + + +Kalt Informational [Page 54] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 421 ERR_UNKNOWNCOMMAND " :Unknown command" @@ -2582,6 +3072,18 @@ in an attempt to change to a currently existing nickname. + + + + + + + +Kalt Informational [Page 55] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 436 ERR_NICKCOLLISION " :Nickname collision KILL from @" @@ -2625,6 +3127,19 @@ user was unable to be performed since they were not logged in. + + + + + + + + +Kalt Informational [Page 56] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 445 ERR_SUMMONDISABLED ":SUMMON has been disabled" @@ -2673,6 +3188,14 @@ a connection for which a password was required and was either not given or incorrect. + + + +Kalt Informational [Page 57] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 465 ERR_YOUREBANNEDCREEP ":You are banned from this server" @@ -2719,6 +3242,16 @@ making the attempt is not a chanop on the specified channel. + + + + + +Kalt Informational [Page 58] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 483 ERR_CANTKILLSERVER ":You can't kill a server!" @@ -2767,6 +3300,14 @@ 1. no longer in use; + + + +Kalt Informational [Page 59] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 2. reserved for future planned use; 3. in current use but are part of a non-generic 'feature' of @@ -2814,6 +3355,15 @@ by two people using this protocol, either one will not succeed or both will removed by use of a server KILL (See Section 3.7.1). + + + + +Kalt Informational [Page 60] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 7.2 Limitation of wildcards There is no way to escape the escape character "\" (%x5C). While @@ -2850,6 +3400,26 @@ Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl. + + + + + + + + + + + + + + + +Kalt Informational [Page 61] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 10. References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate @@ -2882,6 +3452,30 @@ EMail: kalt@stealth.net + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 62] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + 12. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. @@ -2914,3 +3508,24 @@ Funding for the RFC Editor function is currently provided by the Internet Society. + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 63] + ircd-hybrid-7.2.2/doc/technical/rfc2812.txt /home/jas/rfc/rfc2812.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/i/ircd-hybrid/ircd-hybrid_7.2.2.orig.tar.gz ircd-hybrid-7.2.2/doc/technical/rfc2813.txt 3aea98960c9ea03b069c2df91348c0d4 - ircd-hybrid-7.2.2/doc/technical/rfc2813.txt 77f7bf3c11b515adfbd849c36d0344e5 - /home/jas/rfc/rfc2813.txt MISMATCH rfc2813.txt --- ircd-hybrid-7.2.2/doc/technical/rfc2813.txt 2006-07-17 08:31:31.000000000 +0200 +++ /home/jas/rfc/rfc2813.txt 2000-04-27 23:34:30.000000000 +0200 @@ -1,10 +1,15 @@ -$Id: rfc2813.txt 33 2005-10-02 20:50:00Z knight $ + + + + + Network Working Group C. Kalt Request for Comments: 2813 April 2000 Updates: 1459 Category: Informational + Internet Relay Chat: Server Protocol Status of this Memo @@ -33,6 +38,28 @@ scalability has allowed existing world-wide networks to keep growing and reach sizes which defy the old specification. + + + + + + + + + + + + + + + + + +Kalt Informational [Page 1] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + Table of Contents 1. Introduction ............................................... 3 @@ -82,6 +109,13 @@ 6.1 Scalability ............................................ 21 6.2 Labels ................................................. 22 + + +Kalt Informational [Page 2] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + 6.2.1 Nicknames ......................................... 22 6.2.2 Channels .......................................... 22 6.2.3 Servers ........................................... 22 @@ -130,6 +164,14 @@ instead they are presented with a virtual server which has the hostmask for name. + + + +Kalt Informational [Page 3] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + 2.2 Clients For each client, all servers MUST have the following information: a @@ -172,6 +214,20 @@ to a server, the server MUST keep track of the channel members, as well as the channel modes. + + + + + + + + + +Kalt Informational [Page 4] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + 3. The IRC Server Specification 3.1 Overview @@ -221,6 +277,13 @@ from themselves; if they use one, the only valid prefix is the registered nickname associated with the client. + + +Kalt Informational [Page 5] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + When a server receives a message, it MUST identify its source using the (eventually assumed) prefix. If the prefix cannot be found in the server's internal database, it MUST be discarded, and if the @@ -267,6 +330,16 @@ messages in order to provide clients with more useful information about who a message is from without the need for additional queries. + + + + + +Kalt Informational [Page 6] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + 3.4 Numeric replies Most of the messages sent to the server generate a reply of some @@ -316,6 +389,13 @@ following pages apply to some of these messages, they are additions to the message specifications which are only relevant to server to + + +Kalt Informational [Page 7] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + server communication, or to the server implementation. The messages which are introduced here are only used for server to server communication. @@ -363,6 +443,15 @@ The only options defined by the protocol are link compression (using the character "Z"), and an abuse protection flag (using the character + + + + +Kalt Informational [Page 8] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + "P"). See sections 5.3.1.1 (Compressed server to server links) and 5.3.1.2 (Anti abuse protections) respectively for more information on these options. @@ -411,6 +500,14 @@ SERVER). Because of the severity of such event, error replies are usually sent using the "ERROR" command rather than a numeric. + + + +Kalt Informational [Page 9] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + If a SERVER message is parsed and it attempts to introduce a server which is already known to the receiving server, the connection, from which that message arrived, MUST be closed (following the correct @@ -460,6 +557,13 @@ a user is from its home server. A local connection has a hopcount of 0. The hopcount value is incremented by each passed server. + + +Kalt Informational [Page 10] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + The parameter replaces the parameter of the USER (See section 4.1.2 for more information on server tokens). @@ -507,6 +611,15 @@ The parameter is currently reserved for future usage. + + + + +Kalt Informational [Page 11] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + Numeric Replies: ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS @@ -556,6 +669,13 @@ None. + + +Kalt Informational [Page 12] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + Examples: :WiZ QUIT :Gone to have lunch ; Preferred message format. @@ -604,6 +724,14 @@ SHOULD add the nickname to the list of temporarily unavailable nicknames in an attempt to prevent future nickname collisions. See + + + +Kalt Informational [Page 13] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + section 5.7 (Tracking recently used nicknames) for more information on this procedure. @@ -651,6 +779,15 @@ wasn't received from a server. This format MUST NOT be sent to clients, it can only be used between servers and SHOULD be avoided. + + + + +Kalt Informational [Page 14] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + The JOIN command MUST be broadcast to all servers so that each server knows where to find the users who are on the channel. This allows optimal delivery of PRIVMSG and NOTICE messages to the channel. @@ -700,6 +837,13 @@ voice privilege and avalon with no privilege. + + +Kalt Informational [Page 15] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + 4.2.3 Mode message The MODE message is a dual-purpose command in IRC. It allows both @@ -749,6 +893,13 @@ (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it MAY send any introductory messages which may be deemed appropriate. + + +Kalt Informational [Page 16] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + In particular the server SHALL send the current user/service/server count (as per the LUSER reply) and finally the MOTD (if any, as per the MOTD reply). @@ -795,6 +946,16 @@ document) but a particular link MAY set specific options using the PASS message (See Section 4.1.1). + + + + + +Kalt Informational [Page 17] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + 5.3.1.1 Compressed server to server links If a server wishes to establish a compressed link with its peer, it @@ -841,6 +1002,16 @@ command overwrites any old topic information, so at best, the two sides of the connection would exchange topics. + + + + + +Kalt Informational [Page 18] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + By passing the state information about servers first, any collisions with servers that already exist occur before nickname collisions caused by a second server introducing a particular nickname. Due to @@ -887,6 +1058,16 @@ above command it is RECOMMENDED that a time range be given and entries which are too old ignored. + + + + + +Kalt Informational [Page 19] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + For a reasonable history, a server SHOULD be able to keep previous nickname for every client it knows about if they all decided to change. This size is limited by other factors (such as memory, etc). @@ -935,6 +1116,14 @@ two (2) seconds without being adversely affected. Services MAY also be subject to this mechanism. + + + +Kalt Informational [Page 20] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + 5.9 Non-blocking lookups In a real-time environment, it is essential that a server process @@ -980,6 +1169,17 @@ so that the path length between any two points is kept minimal and the spanning tree as strongly branched as possible. + + + + + + +Kalt Informational [Page 21] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + 6.2 Labels The current IRC protocol has 4 types of labels: the nickname, the @@ -1026,6 +1226,16 @@ avoid N^2 algorithms such as checking the channel list of a set of clients. + + + + + +Kalt Informational [Page 22] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + In current server versions, there are only few database consistency checks, most of the time each server assumes that a neighbouring server is correct. This opens the door to large problems if a @@ -1071,6 +1281,17 @@ clear text, a stream layer encryption mechanism (like "The TLS Protocol" [TLS]) could be used to protect these transactions. + + + + + + +Kalt Informational [Page 23] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + 8. Current support and availability Mailing lists for IRC related discussion: @@ -1112,12 +1333,21 @@ [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000. + [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000. [ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. + + + +Kalt Informational [Page 24] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + [DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996. @@ -1139,6 +1369,41 @@ EMail: kalt@stealth.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 25] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + 12. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. @@ -1171,3 +1436,24 @@ Funding for the RFC Editor function is currently provided by the Internet Society. + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 26] + ircd-hybrid-7.2.2/doc/technical/rfc2813.txt /home/jas/rfc/rfc2813.txt differ: byte 1, line 1 pkg jta ver 2.5-2 lastfile jta_2.5.orig.tar.gz files jta-2.5/doc/rfc854.txt tar xfz /data/debian/pool/main/j/jta/jta_2.5.orig.tar.gz jta-2.5/doc/rfc854.txt c7f9a40d99694de6b3261cbb3cd1bdf2 - jta-2.5/doc/rfc854.txt 7cf8b015f80efb64504375454b925f4b - /home/jas/rfc/rfc854.txt MISMATCH rfc854.txt --- jta-2.5/doc/rfc854.txt 2004-11-12 16:44:59.000000000 +0100 +++ /home/jas/rfc/rfc854.txt 1990-10-05 23:52:30.000000000 +0100 @@ -852,4 +852,3 @@ Postel & Reynolds [Page 15] - jta-2.5/doc/rfc854.txt /home/jas/rfc/rfc854.txt differ: byte 2539, line 56 pkg kdelibs ver 4:3.5.5a-1 lastfile kdelibs_3.5.5a.orig.tar.gz files kdelibs-3.5.5/kioslave/http/rfc3253.txt kdelibs-3.5.5/kioslave/http/rfc2616.txt kdelibs-3.5.5/kioslave/http/rfc2518.txt kdelibs-3.5.5/kioslave/http/rfc2617.txt kdelibs-3.5.5/kioslave/http/rfc3229.txt kdelibs-3.5.5/kioslave/http/rfc2817.txt kdelibs-3.5.5/kioslave/http/rfc2818.txt tar xfz /data/debian/pool/main/k/kdelibs/kdelibs_3.5.5a.orig.tar.gz kdelibs-3.5.5/kioslave/http/rfc3253.txt 2387258aa9663877515e264f7820cbe5 - kdelibs-3.5.5/kioslave/http/rfc3253.txt 2387258aa9663877515e264f7820cbe5 - /home/jas/rfc/rfc3253.txt MATCH rfc3253.txt tar xfz /data/debian/pool/main/k/kdelibs/kdelibs_3.5.5a.orig.tar.gz kdelibs-3.5.5/kioslave/http/rfc2616.txt 9fa63f5083e4d2112d2e71b008e387e8 - kdelibs-3.5.5/kioslave/http/rfc2616.txt 9fa63f5083e4d2112d2e71b008e387e8 - /home/jas/rfc/rfc2616.txt MATCH rfc2616.txt tar xfz /data/debian/pool/main/k/kdelibs/kdelibs_3.5.5a.orig.tar.gz kdelibs-3.5.5/kioslave/http/rfc2518.txt a49c2a00897f41160c3be233e3dede80 - kdelibs-3.5.5/kioslave/http/rfc2518.txt a49c2a00897f41160c3be233e3dede80 - /home/jas/rfc/rfc2518.txt MATCH rfc2518.txt tar xfz /data/debian/pool/main/k/kdelibs/kdelibs_3.5.5a.orig.tar.gz kdelibs-3.5.5/kioslave/http/rfc2617.txt 91ba285f507b3234d606b3cfd64b28ad - kdelibs-3.5.5/kioslave/http/rfc2617.txt e233eeb1d2813b1e0c2424ee8302b51f - /home/jas/rfc/rfc2617.txt MISMATCH rfc2617.txt --- kdelibs-3.5.5/kioslave/http/rfc2617.txt 2005-09-10 10:26:41.000000000 +0200 +++ /home/jas/rfc/rfc2617.txt 1999-06-10 01:33:29.000000000 +0200 @@ -1,4 +1,9 @@ + + + + + Network Working Group J. Franks Request for Comments: 2617 Northwestern University Obsoletes: 2069 P. Hallam-Baker kdelibs-3.5.5/kioslave/http/rfc2617.txt /home/jas/rfc/rfc2617.txt differ: byte 2, line 2 tar xfz /data/debian/pool/main/k/kdelibs/kdelibs_3.5.5a.orig.tar.gz kdelibs-3.5.5/kioslave/http/rfc3229.txt 00135d9e3ab1b04d71631a815b7077fa - kdelibs-3.5.5/kioslave/http/rfc3229.txt 00135d9e3ab1b04d71631a815b7077fa - /home/jas/rfc/rfc3229.txt MATCH rfc3229.txt tar xfz /data/debian/pool/main/k/kdelibs/kdelibs_3.5.5a.orig.tar.gz kdelibs-3.5.5/kioslave/http/rfc2817.txt 05cb3db005513992813a9507dbfe3da7 - kdelibs-3.5.5/kioslave/http/rfc2817.txt 05cb3db005513992813a9507dbfe3da7 - /home/jas/rfc/rfc2817.txt MATCH rfc2817.txt tar xfz /data/debian/pool/main/k/kdelibs/kdelibs_3.5.5a.orig.tar.gz kdelibs-3.5.5/kioslave/http/rfc2818.txt 299b2d1e6957215b4aa34950e92ed70e - kdelibs-3.5.5/kioslave/http/rfc2818.txt 299b2d1e6957215b4aa34950e92ed70e - /home/jas/rfc/rfc2818.txt MATCH rfc2818.txt pkg keynote ver 2.3-11 lastfile keynote_2.3.orig.tar.gz files keynote-2.3/doc/rfc2704.txt keynote-2.3/doc/rfc2792.txt tar xfz /data/debian/pool/main/k/keynote/keynote_2.3.orig.tar.gz keynote-2.3/doc/rfc2704.txt 046cd8db9eec39c5e2df59f27657a53c - keynote-2.3/doc/rfc2704.txt 046cd8db9eec39c5e2df59f27657a53c - /home/jas/rfc/rfc2704.txt MATCH rfc2704.txt tar xfz /data/debian/pool/main/k/keynote/keynote_2.3.orig.tar.gz keynote-2.3/doc/rfc2792.txt 0911638c1730023e41c1b947b341fb8b - keynote-2.3/doc/rfc2792.txt 0911638c1730023e41c1b947b341fb8b - /home/jas/rfc/rfc2792.txt MATCH rfc2792.txt pkg krb5 ver 1.4.4-3 lastfile krb5_1.4.4.orig.tar.gz files krb5-1.4.4/doc/krb5-protocol/rfc1510.txt krb5-1.4.4/doc/kadmin/draft-ietf-cat-kerb-chg-password-02.txt tar xfz /data/debian/pool/main/k/krb5/krb5_1.4.4.orig.tar.gz krb5-1.4.4/doc/krb5-protocol/rfc1510.txt dac767e3662f66516187fb7e34664d99 - krb5-1.4.4/doc/krb5-protocol/rfc1510.txt dac767e3662f66516187fb7e34664d99 - /home/jas/rfc/rfc1510.txt MATCH rfc1510.txt tar xfz /data/debian/pool/main/k/krb5/krb5_1.4.4.orig.tar.gz krb5-1.4.4/doc/kadmin/draft-ietf-cat-kerb-chg-password-02.txt a90feb6fe954e47b76228cd281fd670b - krb5-1.4.4/doc/kadmin/draft-ietf-cat-kerb-chg-password-02.txt a90feb6fe954e47b76228cd281fd670b - /home/jas/rfc/draft-ietf-cat-kerb-chg-password-02.txt MATCH draft-ietf-cat-kerb-chg-password-02.txt pkg l2tpd ver 0.70-pre20031121-2.1 lastfile l2tpd_0.70-pre20031121.orig.tar.gz files l2tpd-0.70-pre20031121.orig/doc/rfc2661.txt tar xfz /data/debian/pool/main/l/l2tpd/l2tpd_0.70-pre20031121.orig.tar.gz l2tpd-0.70-pre20031121.orig/doc/rfc2661.txt 50c69b2e04a3679b3eff36bf742716a9 - l2tpd-0.70-pre20031121.orig/doc/rfc2661.txt 50c69b2e04a3679b3eff36bf742716a9 - /home/jas/rfc/rfc2661.txt MATCH rfc2661.txt pkg libdatetime-format-mail-perl ver 0.2901-2 lastfile libdatetime-format-mail-perl_0.2901.orig.tar.gz files DateTime-Format-Mail-0.2901/notes/rfc822.txt DateTime-Format-Mail-0.2901/notes/rfc2822.txt tar xfz /data/debian/pool/main/libd/libdatetime-format-mail-perl/libdatetime-format-mail-perl_0.2901.orig.tar.gz DateTime-Format-Mail-0.2901/notes/rfc822.txt ac6cee92808f230782ef7a307d309e48 - DateTime-Format-Mail-0.2901/notes/rfc822.txt 59975cc77db34020d4f62e69c6f53dcf - /home/jas/rfc/rfc822.txt MISMATCH rfc822.txt --- DateTime-Format-Mail-0.2901/notes/rfc822.txt 2003-10-21 17:24:22.000000000 +0200 +++ /home/jas/rfc/rfc822.txt 1991-10-17 18:47:17.000000000 +0100 @@ -1,28 +1,2850 @@ -[Extracts from RFC822] -[...] + + + + + + RFC # 822 + + Obsoletes: RFC #733 (NIC #41952) + + + + + + + + + + + + + STANDARD FOR THE FORMAT OF + + ARPA INTERNET TEXT MESSAGES + + + + + + + August 13, 1982 + + + + + + + Revised by + + David H. Crocker + + + Dept. of Electrical Engineering + University of Delaware, Newark, DE 19711 + Network: DCrocker @ UDel-Relay + + + + + + + + + + + + + + + + Standard for ARPA Internet Text Messages + + + TABLE OF CONTENTS + + + PREFACE .................................................... ii + + 1. INTRODUCTION ........................................... 1 + + 1.1. Scope ............................................ 1 + 1.2. Communication Framework .......................... 2 + + 2. NOTATIONAL CONVENTIONS ................................. 3 + + 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 + + 3.1. General Description .............................. 5 + 3.2. Header Field Definitions ......................... 9 + 3.3. Lexical Tokens ................................... 10 + 3.4. Clarifications ................................... 11 + + 4. MESSAGE SPECIFICATION .................................. 17 + + 4.1. Syntax ........................................... 17 + 4.2. Forwarding ....................................... 19 + 4.3. Trace Fields ..................................... 20 + 4.4. Originator Fields ................................ 21 + 4.5. Receiver Fields .................................. 23 + 4.6. Reference Fields ................................. 23 + 4.7. Other Fields ..................................... 24 + + 5. DATE AND TIME SPECIFICATION ............................ 26 + + 5.1. Syntax ........................................... 26 + 5.2. Semantics ........................................ 26 + + 6. ADDRESS SPECIFICATION .................................. 27 + + 6.1. Syntax ........................................... 27 + 6.2. Semantics ........................................ 27 + 6.3. Reserved Address ................................. 33 + + 7. BIBLIOGRAPHY ........................................... 34 + + + APPENDIX + + A. EXAMPLES ............................................... 36 + B. SIMPLE FIELD PARSING ................................... 40 + C. DIFFERENCES FROM RFC #733 .............................. 41 + D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 + + + August 13, 1982 - i - RFC #822 + + + + + Standard for ARPA Internet Text Messages + + + PREFACE + + + By 1977, the Arpanet employed several informal standards for + the text messages (mail) sent among its host computers. It was + felt necessary to codify these practices and provide for those + features that seemed imminent. The result of that effort was + Request for Comments (RFC) #733, "Standard for the Format of ARPA + Network Text Message", by Crocker, Vittal, Pogran, and Henderson. + The specification attempted to avoid major changes in existing + software, while permitting several new features. + + This document revises the specifications in RFC #733, in + order to serve the needs of the larger and more complex ARPA + Internet. Some of RFC #733's features failed to gain adequate + acceptance. In order to simplify the standard and the software + that follows it, these features have been removed. A different + addressing scheme is used, to handle the case of inter-network + mail; and the concept of re-transmission has been introduced. + + This specification is intended for use in the ARPA Internet. + However, an attempt has been made to free it of any dependence on + that environment, so that it can be applied to other network text + message systems. + + The specification of RFC #733 took place over the course of + one year, using the ARPANET mail environment, itself, to provide + an on-going forum for discussing the capabilities to be included. + More than twenty individuals, from across the country, partici- + pated in the original discussion. The development of this + revised specification has, similarly, utilized network mail-based + group discussion. Both specification efforts greatly benefited + from the comments and ideas of the participants. + + The syntax of the standard, in RFC #733, was originally + specified in the Backus-Naur Form (BNF) meta-language. Ken L. + Harrenstien, of SRI International, was responsible for re-coding + the BNF into an augmented BNF that makes the representation + smaller and easier to understand. + + + + + + + + + + + + + August 13, 1982 - ii - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1. INTRODUCTION + + 1.1. SCOPE + + This standard specifies a syntax for text messages that are + sent among computer users, within the framework of "electronic + mail". The standard supersedes the one specified in ARPANET + Request for Comments #733, "Standard for the Format of ARPA Net- + work Text Messages". + + In this context, messages are viewed as having an envelope + and contents. The envelope contains whatever information is + needed to accomplish transmission and delivery. The contents + compose the object to be delivered to the recipient. This stan- + dard applies only to the format and some of the semantics of mes- + sage contents. It contains no specification of the information + in the envelope. + + However, some message systems may use information from the + contents to create the envelope. It is intended that this stan- + dard facilitate the acquisition of such information by programs. + + Some message systems may store messages in formats that + differ from the one specified in this standard. This specifica- + tion is intended strictly as a definition of what message content + format is to be passed BETWEEN hosts. + + Note: This standard is NOT intended to dictate the internal for- + mats used by sites, the specific message system features + that they are expected to support, or any of the charac- + teristics of user interface programs that create or read + messages. + + A distinction should be made between what the specification + REQUIRES and what it ALLOWS. Messages can be made complex and + rich with formally-structured components of information or can be + kept small and simple, with a minimum of such information. Also, + the standard simplifies the interpretation of differing visual + formats in messages; only the visual aspect of a message is + affected and not the interpretation of information within it. + Implementors may choose to retain such visual distinctions. + + The formal definition is divided into four levels. The bot- + tom level describes the meta-notation used in this document. The + second level describes basic lexical analyzers that feed tokens + to higher-level parsers. Next is an overall specification for + messages; it permits distinguishing individual fields. Finally, + there is definition of the contents of several structured fields. + + + + August 13, 1982 - 1 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1.2. COMMUNICATION FRAMEWORK + + Messages consist of lines of text. No special provisions + are made for encoding drawings, facsimile, speech, or structured + text. No significant consideration has been given to questions + of data compression or to transmission and storage efficiency, + and the standard tends to be free with the number of bits con- + sumed. For example, field names are specified as free text, + rather than special terse codes. + + A general "memo" framework is used. That is, a message con- + sists of some information in a rigid format, followed by the main + part of the message, with a format that is not specified in this + document. The syntax of several fields of the rigidly-formated + ("headers") section is defined in this specification; some of + these fields must be included in all messages. + + The syntax that distinguishes between header fields is + specified separately from the internal syntax for particular + fields. This separation is intended to allow simple parsers to + operate on the general structure of messages, without concern for + the detailed structure of individual header fields. Appendix B + is provided to facilitate construction of these parsers. + + In addition to the fields specified in this document, it is + expected that other fields will gain common use. As necessary, + the specifications for these "extension-fields" will be published + through the same mechanism used to publish this document. Users + may also wish to extend the set of fields that they use + privately. Such "user-defined fields" are permitted. + + The framework severely constrains document tone and appear- + ance and is primarily useful for most intra-organization communi- + cations and well-structured inter-organization communication. + It also can be used for some types of inter-process communica- + tion, such as simple file transfer and remote job entry. A more + robust framework might allow for multi-font, multi-color, multi- + dimension encoding of information. A less robust one, as is + present in most single-machine message systems, would more + severely constrain the ability to add fields and the decision to + include specific fields. In contrast with paper-based communica- + tion, it is interesting to note that the RECEIVER of a message + can exercise an extraordinary amount of control over the + message's appearance. The amount of actual control available to + message receivers is contingent upon the capabilities of their + individual message systems. + + + + + + August 13, 1982 - 2 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2. NOTATIONAL CONVENTIONS + + This specification uses an augmented Backus-Naur Form (BNF) + notation. The differences from standard BNF involve naming rules + and indicating repetition and "local" alternatives. + + 2.1. RULE NAMING + + Angle brackets ("<", ">") are not used, in general. The + name of a rule is simply the name itself, rather than "". + Quotation-marks enclose literal text (which may be upper and/or + lower case). Certain basic rules are in uppercase, such as + SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in + rule definitions, and in the rest of this document, whenever + their presence will facilitate discerning the use of rule names. + + 2.2. RULE1 / RULE2: ALTERNATIVES + + Elements separated by slash ("/") are alternatives. There- + fore "foo / bar" will accept foo or bar. + + 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES + + Elements enclosed in parentheses are treated as a single + element. Thus, "(elem (foo / bar) elem)" allows the token + sequences "elem foo elem" and "elem bar elem". + + 2.4. *RULE: REPETITION + + The character "*" preceding an element indicates repetition. + The full form is: + + *element + + indicating at least and at most occurrences of element. + Default values are 0 and infinity so that "*(element)" allows any + number, including zero; "1*element" requires at least one; and + "1*2element" allows one or two. + + 2.5. [RULE]: OPTIONAL + + Square brackets enclose optional elements; "[foo bar]" is + equivalent to "*1(foo bar)". + + 2.6. NRULE: SPECIFIC REPETITION + + "(element)" is equivalent to "*(element)"; that is, + exactly occurrences of (element). Thus 2DIGIT is a 2-digit + number, and 3ALPHA is a string of three alphabetic characters. + + + August 13, 1982 - 3 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2.7. #RULE: LISTS + + A construct "#" is defined, similar to "*", as follows: + + #element + + indicating at least and at most elements, each separated + by one or more commas (","). This makes the usual form of lists + very easy; a rule such as '(element *("," element))' can be shown + as "1#element". Wherever this construct is used, null elements + are allowed, but do not contribute to the count of elements + present. That is, "(element),,(element)" is permitted, but + counts as only two elements. Therefore, where at least one ele- + ment is required, at least one non-null element must be present. + Default values are 0 and infinity so that "#(element)" allows any + number, including zero; "1#element" requires at least one; and + "1#2element" allows one or two. + + 2.8. ; COMMENTS + + A semi-colon, set off some distance to the right of rule + text, starts a comment that continues to the end of line. This + is a simple way of including useful notes in parallel with the + specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 4 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3. LEXICAL ANALYSIS OF MESSAGES + + 3.1. GENERAL DESCRIPTION + + A message consists of header fields and, optionally, a body. + The body is simply a sequence of lines containing ASCII charac- + ters. It is separated from the headers by a null line (i.e., a + line with nothing preceding the CRLF). + + 3.1.1. LONG HEADER FIELDS + + Each header field can be viewed as a single, logical line of + ASCII characters, comprising a field-name and a field-body. + For convenience, the field-body portion of this conceptual + entity can be split into a multiple-line representation; this + is called "folding". The general rule is that wherever there + may be linear-white-space (NOT simply LWSP-chars), a CRLF + immediately followed by AT LEAST one LWSP-char may instead be + inserted. Thus, the single line + + To: "Joe & J. Harvey" , JJV @ BBN + + can be represented as: + + To: "Joe & J. Harvey" , + JJV@BBN + + and + + To: "Joe & J. Harvey" + , JJV + @BBN + + and + + To: "Joe & + J. Harvey" , JJV @ BBN + + The process of moving from this folded multiple-line + representation of a header field to its single line represen- + tation is called "unfolding". Unfolding is accomplished by + regarding CRLF immediately followed by a LWSP-char as + equivalent to the LWSP-char. + + Note: While the standard permits folding wherever linear- + white-space is permitted, it is recommended that struc- + tured fields, such as those containing addresses, limit + folding to higher-level syntactic breaks. For address + fields, it is recommended that such folding occur + + + August 13, 1982 - 5 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + between addresses, after the separating comma. + + 3.1.2. STRUCTURE OF HEADER FIELDS + + Once a field has been unfolded, it may be viewed as being com- + posed of a field-name followed by a colon (":"), followed by a + field-body, and terminated by a carriage-return/line-feed. + The field-name must be composed of printable ASCII characters + (i.e., characters that have values between 33. and 126., + decimal, except colon). The field-body may be composed of any + ASCII characters, except CR or LF. (While CR and/or LF may be + present in the actual text, they are removed by the action of + unfolding the field.) + + Certain field-bodies of headers may be interpreted according + to an internal syntax that some systems may wish to parse. + These fields are called "structured fields". Examples + include fields containing dates and addresses. Other fields, + such as "Subject" and "Comments", are regarded simply as + strings of text. + + Note: Any field which has a field-body that is defined as + other than simply is to be treated as a struc- + tured field. + + Field-names, unstructured field bodies and structured + field bodies each are scanned by their own, independent + "lexical" analyzers. + + 3.1.3. UNSTRUCTURED FIELD BODIES + + For some fields, such as "Subject" and "Comments", no struc- + turing is assumed, and they are treated simply as s, as + in the message body. Rules of folding apply to these fields, + so that such field bodies which occupy several lines must + therefore have the second and successive lines indented by at + least one LWSP-char. + + 3.1.4. STRUCTURED FIELD BODIES + + To aid in the creation and reading of structured fields, the + free insertion of linear-white-space (which permits folding + by inclusion of CRLFs) is allowed between lexical tokens. + Rather than obscuring the syntax specifications for these + structured fields with explicit syntax for this linear-white- + space, the existence of another "lexical" analyzer is assumed. + This analyzer does not apply for unstructured field bodies + that are simply strings of text, as described above. The + analyzer provides an interpretation of the unfolded text + + + August 13, 1982 - 6 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + composing the body of the field as a sequence of lexical sym- + bols. + + These symbols are: + + - individual special characters + - quoted-strings + - domain-literals + - comments + - atoms + + The first four of these symbols are self-delimiting. Atoms + are not; they are delimited by the self-delimiting symbols and + by linear-white-space. For the purposes of regenerating + sequences of atoms and quoted-strings, exactly one SPACE is + assumed to exist, and should be used, between them. (Also, in + the "Clarifications" section on "White Space", below, note the + rules about treatment of multiple contiguous LWSP-chars.) + + So, for example, the folded body of an address field + + ":sysmail"@ Some-Group. Some-Org, + Muhammed.(I am the greatest) Ali @(the)Vegas.WBA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 7 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + is analyzed into the following lexical symbols and types: + + :sysmail quoted string + @ special + Some-Group atom + . special + Some-Org atom + , special + Muhammed atom + . special + (I am the greatest) comment + Ali atom + @ atom + (the) comment + Vegas atom + . special + WBA atom + + The canonical representations for the data in these addresses + are the following strings: + + ":sysmail"@Some-Group.Some-Org + + and + + Muhammed.Ali@Vegas.WBA + + Note: For purposes of display, and when passing such struc- + tured information to other systems, such as mail proto- + col services, there must be NO linear-white-space + between s that are separated by period (".") or + at-sign ("@") and exactly one SPACE between all other + s. Also, headers should be in a folded form. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 8 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.2. HEADER FIELD DEFINITIONS + + These rules show a field meta-syntax, without regard for the + particular type or internal syntax. Their purpose is to permit + detection of fields; also, they present to higher-level parsers + an image of each field as fitting on one line. + + field = field-name ":" [ field-body ] CRLF + + field-name = 1* + + field-body = field-body-contents + [CRLF LWSP-char field-body] + + field-body-contents = + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 9 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.3. LEXICAL TOKENS + + The following rules are used to define an underlying lexical + analyzer, which feeds tokens to higher level parsers. See the + ANSI references, in the Bibliography. + + ; ( Octal, Decimal.) + CHAR = ; ( 0-177, 0.-127.) + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + DIGIT = ; ( 60- 71, 48.- 57.) + CTL = ; ( 177, 127.) + CR = ; ( 15, 13.) + LF = ; ( 12, 10.) + SPACE = ; ( 40, 32.) + HTAB = ; ( 11, 9.) + <"> = ; ( 42, 34.) + CRLF = CR LF + + LWSP-char = SPACE / HTAB ; semantics = SPACE + + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + + delimiters = specials / linear-white-space / comment + + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + + atom = 1* + + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + + domain-literal = "[" *(dtext / quoted-pair) "]" + + + + + August 13, 1982 - 10 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + + comment = "(" *(ctext / quoted-pair / comment) ")" + + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + + quoted-pair = "\" CHAR ; may quote any char + + phrase = 1*word ; Sequence of words + + word = atom / quoted-string + + + 3.4. CLARIFICATIONS + + 3.4.1. QUOTING + + Some characters are reserved for special interpretation, such + as delimiting lexical tokens. To permit use of these charac- + ters as uninterpreted data, a quoting mechanism is provided. + To quote a character, precede it with a backslash ("\"). + + This mechanism is not fully general. Characters may be quoted + only within a subset of the lexical constructs. In particu- + lar, quoting is limited to use within: + + - quoted-string + - domain-literal + - comment + + Within these constructs, quoting is REQUIRED for CR and "\" + and for the character(s) that delimit the token (e.g., "(" and + ")" for a comment). However, quoting is PERMITTED for any + character. + + Note: In particular, quoting is NOT permitted within atoms. + For example when the local-part of an addr-spec must + contain a special character, a quoted string must be + used. Therefore, a specification such as: + + Full\ Name@Domain + + is not legal and must be specified as: + + "Full Name"@Domain + + + August 13, 1982 - 11 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.2. WHITE SPACE + + Note: In structured field bodies, multiple linear space ASCII + characters (namely HTABs and SPACEs) are treated as + single spaces and may freely surround any symbol. In + all header fields, the only place in which at least one + LWSP-char is REQUIRED is at the beginning of continua- + tion lines in a folded field. + + When passing text to processes that do not interpret text + according to this standard (e.g., mail protocol servers), then + NO linear-white-space characters should occur between a period + (".") or at-sign ("@") and a . Exactly ONE SPACE should + be used in place of arbitrary linear-white-space and comment + sequences. + + Note: Within systems conforming to this standard, wherever a + member of the list of delimiters is allowed, LWSP-chars + may also occur before and/or after it. + + Writers of mail-sending (i.e., header-generating) programs + should realize that there is no network-wide definition of the + effect of ASCII HT (horizontal-tab) characters on the appear- + ance of text at another network host; therefore, the use of + tabs in message headers, though permitted, is discouraged. + + 3.4.3. COMMENTS + + A comment is a set of ASCII characters, which is enclosed in + matching parentheses and which is not within a quoted-string + The comment construct permits message originators to add text + which will be useful for human readers, but which will be + ignored by the formal semantics. Comments should be retained + while the message is subject to interpretation according to + this standard. However, comments must NOT be included in + other cases, such as during protocol exchanges with mail + servers. + + Comments nest, so that if an unquoted left parenthesis occurs + in a comment string, there must also be a matching right + parenthesis. When a comment acts as the delimiter between a + sequence of two lexical symbols, such as two atoms, it is lex- + ically equivalent with a single SPACE, for the purposes of + regenerating the sequence, such as when passing the sequence + onto a mail protocol server. Comments are detected as such + only within field-bodies of structured fields. + + If a comment is to be "folded" onto multiple lines, then the + syntax for folding must be adhered to. (See the "Lexical + + + August 13, 1982 - 12 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Analysis of Messages" section on "Folding Long Header Fields" + above, and the section on "Case Independence" below.) Note + that the official semantics therefore do not "see" any + unquoted CRLFs that are in comments, although particular pars- + ing programs may wish to note their presence. For these pro- + grams, it would be reasonable to interpret a "CRLF LWSP-char" + as being a CRLF that is part of the comment; i.e., the CRLF is + kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a + backslash followed by a CR followed by a LF) still must be + followed by at least one LWSP-char. + + 3.4.4. DELIMITING AND QUOTING CHARACTERS + + The quote character (backslash) and characters that delimit + syntactic units are not, generally, to be taken as data that + are part of the delimited or quoted unit(s). In particular, + the quotation-marks that define a quoted-string, the + parentheses that define a comment and the backslash that + quotes a following character are NOT part of the quoted- + string, comment or quoted character. A quotation-mark that is + to be part of a quoted-string, a parenthesis that is to be + part of a comment and a backslash that is to be part of either + must each be preceded by the quote-character backslash ("\"). + Note that the syntax allows any character to be quoted within + a quoted-string or comment; however only certain characters + MUST be quoted to be included as data. These characters are + the ones that are not part of the alternate text group (i.e., + ctext or qtext). + + The one exception to this rule is that a single SPACE is + assumed to exist between contiguous words in a phrase, and + this interpretation is independent of the actual number of + LWSP-chars that the creator places between the words. To + include more than one SPACE, the creator must make the LWSP- + chars be part of a quoted-string. + + Quotation marks that delimit a quoted string and backslashes + that quote the following character should NOT accompany the + quoted-string when the string is passed to processes that do + not interpret data according to this specification (e.g., mail + protocol servers). + + 3.4.5. QUOTED-STRINGS + + Where permitted (i.e., in words in structured fields) quoted- + strings are treated as a single symbol. That is, a quoted- + string is equivalent to an atom, syntactically. If a quoted- + string is to be "folded" onto multiple lines, then the syntax + for folding must be adhered to. (See the "Lexical Analysis of + + + August 13, 1982 - 13 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Messages" section on "Folding Long Header Fields" above, and + the section on "Case Independence" below.) Therefore, the + official semantics do not "see" any bare CRLFs that are in + quoted-strings; however particular parsing programs may wish + to note their presence. For such programs, it would be rea- + sonable to interpret a "CRLF LWSP-char" as being a CRLF which + is part of the quoted-string; i.e., the CRLF is kept and the + LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- + lowed by a CR followed by a LF) are also subject to rules of + folding, but the presence of the quoting character (backslash) + explicitly indicates that the CRLF is data to the quoted + string. Stripping off the first following LWSP-char is also + appropriate when parsing quoted CRLFs. + + 3.4.6. BRACKETING CHARACTERS + + There is one type of bracket which must occur in matched pairs + and may have pairs nested within each other: + + o Parentheses ("(" and ")") are used to indicate com- + ments. + + There are three types of brackets which must occur in matched + pairs, and which may NOT be nested: + + o Colon/semi-colon (":" and ";") are used in address + specifications to indicate that the included list of + addresses are to be treated as a group. + + o Angle brackets ("<" and ">") are generally used to + indicate the presence of a one machine-usable refer- + ence (e.g., delimiting mailboxes), possibly including + source-routing to the machine. + + o Square brackets ("[" and "]") are used to indicate the + presence of a domain-literal, which the appropriate + name-domain is to use directly, bypassing normal + name-resolution mechanisms. + + 3.4.7. CASE INDEPENDENCE + + Except as noted, alphabetic strings may be represented in any + combination of upper and lower case. The only syntactic units + + + + + + + + + August 13, 1982 - 14 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + which requires preservation of case information are: + + - text + - qtext + - dtext + - ctext + - quoted-pair + - local-part, except "Postmaster" + + When matching any other syntactic unit, case is to be ignored. + For example, the field-names "From", "FROM", "from", and even + "FroM" are semantically equal and should all be treated ident- + ically. + + When generating these units, any mix of upper and lower case + alphabetic characters may be used. The case shown in this + specification is suggested for message-creating processes. + + Note: The reserved local-part address unit, "Postmaster", is + an exception. When the value "Postmaster" is being + interpreted, it must be accepted in any mixture of + case, including "POSTMASTER", and "postmaster". + + 3.4.8. FOLDING LONG HEADER FIELDS + + Each header field may be represented on exactly one line con- + sisting of the name of the field and its body, and terminated + by a CRLF; this is what the parser sees. For readability, the + field-body portion of long header fields may be "folded" onto + multiple lines of the actual field. "Long" is commonly inter- + preted to mean greater than 65 or 72 characters. The former + length serves as a limit, when the message is to be viewed on + most simple terminals which use simple display software; how- + ever, the limit is not imposed by this standard. + + Note: Some display software often can selectively fold lines, + to suit the display terminal. In such cases, sender- + provided folding can interfere with the display + software. + + 3.4.9. BACKSPACE CHARACTERS + + ASCII BS characters (Backspace, decimal 8) may be included in + texts and quoted-strings to effect overstriking. However, any + use of backspaces which effects an overstrike to the left of + the beginning of the text or quoted-string is prohibited. + + + + + + August 13, 1982 - 15 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS + + During transmission through heterogeneous networks, it may be + necessary to force data to conform to a network's local con- + ventions. For example, it may be required that a CR be fol- + lowed either by LF, making a CRLF, or by , if the CR is + to stand alone). Such transformations are reversed, when the + message exits that network. + + When crossing network boundaries, the message should be + treated as passing through two modules. It will enter the + first module containing whatever network-specific transforma- + tions that were necessary to permit migration through the + "current" network. It then passes through the modules: + + o Transformation Reversal + + The "current" network's idiosyncracies are removed and + the message is returned to the canonical form speci- + fied in this standard. + + o Transformation + + The "next" network's local idiosyncracies are imposed + on the message. + + ------------------ + From ==> | Remove Net-A | + Net-A | idiosyncracies | + ------------------ + || + \/ + Conformance + with standard + || + \/ + ------------------ + | Impose Net-B | ==> To + | idiosyncracies | Net-B + ------------------ + + + + + + + + + + + + August 13, 1982 - 16 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 4. MESSAGE SPECIFICATION + + 4.1. SYNTAX + + Note: Due to an artifact of the notational conventions, the syn- + tax indicates that, when present, some fields, must be in + a particular order. Header fields are NOT required to + occur in any particular order, except that the message + body must occur AFTER the headers. It is recommended + that, if present, headers be sent in the order "Return- + Path", "Received", "Date", "From", "Subject", "Sender", + "To", "cc", etc. + + This specification permits multiple occurrences of most + fields. Except as noted, their interpretation is not + specified here, and their use is discouraged. + + The following syntax for the bodies of various fields should + be thought of as describing each field body as a single long + string (or line). The "Lexical Analysis of Message" section on + "Long Header Fields", above, indicates how such long strings can + be represented on more than one line in the actual transmitted + message. + + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + + trace = return ; path to sender + 1*received ; receipt tags + + return = "Return-path" ":" route-addr ; return address + + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + + + August 13, 1982 - 17 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + ";" date-time ; time received + + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + + dates = orig-date ; Original + [ resent-date ] ; Forwarded + + orig-date = "Date" ":" date-time + + resent-date = "Resent-Date" ":" date-time + + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + + msg-id = "<" addr-spec ">" ; Unique message id + + + + + + + August 13, 1982 - 18 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + extension-field = + + + user-defined-field = + + + 4.2. FORWARDING + + Some systems permit mail recipients to forward a message, + retaining the original headers, by adding some new fields. This + standard supports such a service, through the "Resent-" prefix to + field names. + + Whenever the string "Resent-" begins a field name, the field + has the same semantics as a field whose name does not have the + prefix. However, the message is assumed to have been forwarded + by an original recipient who attached the "Resent-" field. This + new field is treated as being more recent than the equivalent, + original field. For example, the "Resent-From", indicates the + person that forwarded the message, whereas the "From" field indi- + cates the original author. + + Use of such precedence information depends upon partici- + pants' communication needs. For example, this standard does not + dictate when a "Resent-From:" address should receive replies, in + lieu of sending them to the "From:" address. + + Note: In general, the "Resent-" fields should be treated as con- + taining a set of information that is independent of the + set of original fields. Information for one set should + not automatically be taken from the other. The interpre- + tation of multiple "Resent-" fields, of the same type, is + undefined. + + In the remainder of this specification, occurrence of legal + "Resent-" fields are treated identically with the occurrence of + + + + + + + + + August 13, 1982 - 19 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + fields whose names do not contain this prefix. + + 4.3. TRACE FIELDS + + Trace information is used to provide an audit trail of mes- + sage handling. In addition, it indicates a route back to the + sender of the message. + + The list of known "via" and "with" values are registered + with the Network Information Center, SRI International, Menlo + Park, California. + + 4.3.1. RETURN-PATH + + This field is added by the final transport system that + delivers the message to its recipient. The field is intended + to contain definitive information about the address and route + back to the message's originator. + + Note: The "Reply-To" field is added by the originator and + serves to direct replies, whereas the "Return-Path" + field is used to identify a path back to the origina- + tor. + + While the syntax indicates that a route specification is + optional, every attempt should be made to provide that infor- + mation in this field. + + 4.3.2. RECEIVED + + A copy of this field is added by each transport service that + relays the message. The information in the field can be quite + useful for tracing transport problems. + + The names of the sending and receiving hosts and time-of- + receipt may be specified. The "via" parameter may be used, to + indicate what physical mechanism the message was sent over, + such as Arpanet or Phonenet, and the "with" parameter may be + used to indicate the mail-, or connection-, level protocol + that was used, such as the SMTP mail protocol, or X.25 tran- + sport protocol. + + Note: Several "with" parameters may be included, to fully + specify the set of protocols that were used. + + Some transport services queue mail; the internal message iden- + tifier that is assigned to the message may be noted, using the + "id" parameter. When the sending host uses a destination + address specification that the receiving host reinterprets, by + + + August 13, 1982 - 20 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + expansion or transformation, the receiving host may wish to + record the original specification, using the "for" parameter. + For example, when a copy of mail is sent to the member of a + distribution list, this parameter may be used to record the + original address that was used to specify the list. + + 4.4. ORIGINATOR FIELDS + + The standard allows only a subset of the combinations possi- + ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, + and Resent-Reply-To fields. The limitation is intentional. + + 4.4.1. FROM / RESENT-FROM + + This field contains the identity of the person(s) who wished + this message to be sent. The message-creation process should + default this field to be a single, authenticated machine + address, indicating the AGENT (person, system or process) + entering the message. If this is not done, the "Sender" field + MUST be present. If the "From" field IS defaulted this way, + the "Sender" field is optional and is redundant with the + "From" field. In all cases, addresses in the "From" field + must be machine-usable (addr-specs) and may not contain named + lists (groups). + + 4.4.2. SENDER / RESENT-SENDER + + This field contains the authenticated identity of the AGENT + (person, system or process) that sends the message. It is + intended for use when the sender is not the author of the mes- + sage, or to indicate who among a group of authors actually + sent the message. If the contents of the "Sender" field would + be completely redundant with the "From" field, then the + "Sender" field need not be present and its use is discouraged + (though still legal). In particular, the "Sender" field MUST + be present if it is NOT the same as the "From" Field. + + The Sender mailbox specification includes a word sequence + which must correspond to a specific agent (i.e., a human user + or a computer program) rather than a standard address. This + indicates the expectation that the field will identify the + single AGENT (person, system, or process) responsible for + sending the mail and not simply include the name of a mailbox + from which the mail was sent. For example in the case of a + shared login name, the name, by itself, would not be adequate. + The local-part address unit, which refers to this agent, is + expected to be a computer system term, and not (for example) a + generalized person reference which can be used outside the + network text message context. + + + August 13, 1982 - 21 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Since the critical function served by the "Sender" field is + identification of the agent responsible for sending mail and + since computer programs cannot be held accountable for their + behavior, it is strongly recommended that when a computer pro- + gram generates a message, the HUMAN who is responsible for + that program be referenced as part of the "Sender" field mail- + box specification. + + 4.4.3. REPLY-TO / RESENT-REPLY-TO + + This field provides a general mechanism for indicating any + mailbox(es) to which responses are to be sent. Three typical + uses for this feature can be distinguished. In the first + case, the author(s) may not have regular machine-based mail- + boxes and therefore wish(es) to indicate an alternate machine + address. In the second case, an author may wish additional + persons to be made aware of, or responsible for, replies. A + somewhat different use may be of some help to "text message + teleconferencing" groups equipped with automatic distribution + services: include the address of that service in the "Reply- + To" field of all messages submitted to the teleconference; + then participants can "reply" to conference submissions to + guarantee the correct distribution of any submission of their + own. + + Note: The "Return-Path" field is added by the mail transport + service, at the time of final deliver. It is intended + to identify a path back to the orginator of the mes- + sage. The "Reply-To" field is added by the message + originator and is intended to direct replies. + + 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO + + For systems which automatically generate address lists for + replies to messages, the following recommendations are made: + + o The "Sender" field mailbox should be sent notices of + any problems in transport or delivery of the original + messages. If there is no "Sender" field, then the + "From" field mailbox should be used. + + o The "Sender" field mailbox should NEVER be used + automatically, in a recipient's reply message. + + o If the "Reply-To" field exists, then the reply should + go to the addresses indicated in that field and not to + the address(es) indicated in the "From" field. + + + + + August 13, 1982 - 22 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + o If there is a "From" field, but no "Reply-To" field, + the reply should be sent to the address(es) indicated + in the "From" field. + + Sometimes, a recipient may actually wish to communicate with + the person that initiated the message transfer. In such + cases, it is reasonable to use the "Sender" address. + + This recommendation is intended only for automated use of + originator-fields and is not intended to suggest that replies + may not also be sent to other recipients of messages. It is + up to the respective mail-handling programs to decide what + additional facilities will be provided. + + Examples are provided in Appendix A. + + 4.5. RECEIVER FIELDS + + 4.5.1. TO / RESENT-TO + + This field contains the identity of the primary recipients of + the message. + + 4.5.2. CC / RESENT-CC + + This field contains the identity of the secondary (informa- + tional) recipients of the message. + + 4.5.3. BCC / RESENT-BCC + + This field contains the identity of additional recipients of + the message. The contents of this field are not included in + copies of the message sent to the primary and secondary reci- + pients. Some systems may choose to include the text of the + "Bcc" field only in the author(s)'s copy, while others may + also include it in the text sent to all those indicated in the + "Bcc" list. + + 4.6. REFERENCE FIELDS + + 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID + + This field contains a unique identifier (the local-part + address unit) which refers to THIS version of THIS message. + The uniqueness of the message identifier is guaranteed by the + host which generates it. This identifier is intended to be + machine readable and not necessarily meaningful to humans. A + message identifier pertains to exactly one instantiation of a + particular message; subsequent revisions to the message should + + + August 13, 1982 - 23 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + each receive new message identifiers. + + 4.6.2. IN-REPLY-TO + + The contents of this field identify previous correspon- + dence which this message answers. Note that if message iden- + tifiers are used in this field, they must use the msg-id + specification format. + + 4.6.3. REFERENCES + + The contents of this field identify other correspondence + which this message references. Note that if message identif- + iers are used, they must use the msg-id specification format. + + 4.6.4. KEYWORDS + + This field contains keywords or phrases, separated by + commas. + + 4.7. OTHER FIELDS + + 4.7.1. SUBJECT + + This is intended to provide a summary, or indicate the + nature, of the message. + + 4.7.2. COMMENTS + + Permits adding text comments onto the message without + disturbing the contents of the message's body. + + 4.7.3. ENCRYPTED + + Sometimes, data encryption is used to increase the + privacy of message contents. If the body of a message has + been encrypted, to keep its contents private, the "Encrypted" + field can be used to note the fact and to indicate the nature + of the encryption. The first parameter indicates the + software used to encrypt the body, and the second, optional + is intended to aid the recipient in selecting the + proper decryption key. This code word may be viewed as an + index to a table of keys held by the recipient. + + Note: Unfortunately, headers must contain envelope, as well + as contents, information. Consequently, it is neces- + sary that they remain unencrypted, so that mail tran- + sport services may access them. Since names, + addresses, and "Subject" field contents may contain + + + August 13, 1982 - 24 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + sensitive information, this requirement limits total + message privacy. + + Names of encryption software are registered with the Net- + work Information Center, SRI International, Menlo Park, Cali- + fornia. + + 4.7.4. EXTENSION-FIELD + + A limited number of common fields have been defined in + this document. As network mail requirements dictate, addi- + tional fields may be standardized. To provide user-defined + fields with a measure of safety, in name selection, such + extension-fields will never have names that begin with the + string "X-". + + Names of Extension-fields are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 4.7.5. USER-DEFINED-FIELD + + Individual users of network mail are free to define and + use additional header fields. Such fields must have names + which are not already used in the current specification or in + any definitions of extension-fields, and the overall syntax of + these user-defined-fields must conform to this specification's + rules for delimiting and folding fields. Due to the + extension-field publishing process, the name of a user- + defined-field may be pre-empted + + Note: The prefatory string "X-" will never be used in the + names of Extension-fields. This provides user-defined + fields with a protected set of names. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 25 - RFC #822 + + + + Standard for ARPA Internet Text Messages + 5. DATE AND TIME SPECIFICATION - 5.1. SYNTAX + 5.1. SYNTAX + + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + + time = hour zone ; ANSI and Military + + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + ; A:-1; (J not used) + ; M:-12; N:+1; Y:+12 + / ( ("+" / "-") 4DIGIT ) ; Local differential + ; hours+min. (HHMM) + + 5.2. SEMANTICS + + If included, day-of-week must be the day implied by the date + specification. + + Time zone may be indicated in several ways. "UT" is Univer- + sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- + mitted as a reference to Universal Time. The military standard + uses a single character for each zone. "Z" is Universal Time. + "A" indicates one hour earlier, and "M" indicates 12 hours ear- + lier; "N" is one hour later, and "Y" is 12 hours later. The + letter "J" is not used. The other remaining two forms are taken + from ANSI standard X3.51-1975. One allows explicit indication of + the amount of offset from UT; the other uses common 3-character + strings for indicating time zones in North America. + + + August 13, 1982 - 26 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 6. ADDRESS SPECIFICATION + + 6.1. SYNTAX + + address = mailbox ; one addressee + / group ; named list + + group = phrase ":" [#mailbox] ";" + + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + + route-addr = "<" [route] addr-spec ">" + + route = 1#("@" domain) ":" ; path-relative + + addr-spec = local-part "@" domain ; global address + + local-part = word *("." word) ; uninterpreted + ; case-preserved + + domain = sub-domain *("." sub-domain) + + sub-domain = domain-ref / domain-literal + + domain-ref = atom ; symbolic reference + + 6.2. SEMANTICS + + A mailbox receives mail. It is a conceptual entity which + does not necessarily pertain to file storage. For example, some + sites may choose to print mail on their line printer and deliver + the output to the addressee's desk. + + A mailbox specification comprises a person, system or pro- + cess name reference, a domain-dependent string, and a name-domain + reference. The name reference is optional and is usually used to + indicate the human name of a recipient. The name-domain refer- + ence specifies a sequence of sub-domains. The domain-dependent + string is uninterpreted, except by the final sub-domain; the rest + of the mail service merely transmits it as a literal string. + + 6.2.1. DOMAINS + + A name-domain is a set of registered (mail) names. A name- + domain specification resolves to a subordinate name-domain + specification or to a terminal domain-dependent string. + Hence, domain specification is extensible, permitting any + number of registration levels. + + + August 13, 1982 - 27 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Name-domains model a global, logical, hierarchical addressing + scheme. The model is logical, in that an address specifica- + tion is related to name registration and is not necessarily + tied to transmission path. The model's hierarchy is a + directed graph, called an in-tree, such that there is a single + path from the root of the tree to any node in the hierarchy. + If more than one path actually exists, they are considered to + be different addresses. + + The root node is common to all addresses; consequently, it is + not referenced. Its children constitute "top-level" name- + domains. Usually, a service has access to its own full domain + specification and to the names of all top-level name-domains. + + The "top" of the domain addressing hierarchy -- a child of the + root -- is indicated by the right-most field, in a domain + specification. Its child is specified to the left, its child + to the left, and so on. + + Some groups provide formal registration services; these con- + stitute name-domains that are independent logically of + specific machines. In addition, networks and machines impli- + citly compose name-domains, since their membership usually is + registered in name tables. + + In the case of formal registration, an organization implements + a (distributed) data base which provides an address-to-route + mapping service for addresses of the form: + + person@registry.organization + + Note that "organization" is a logical entity, separate from + any particular communication network. + + A mechanism for accessing "organization" is universally avail- + able. That mechanism, in turn, seeks an instantiation of the + registry; its location is not indicated in the address specif- + ication. It is assumed that the system which operates under + the name "organization" knows how to find a subordinate regis- + try. The registry will then use the "person" string to deter- + mine where to send the mail specification. + + The latter, network-oriented case permits simple, direct, + attachment-related address specification, such as: + + user@host.network + + Once the network is accessed, it is expected that a message + will go directly to the host and that the host will resolve + + + August 13, 1982 - 28 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + the user name, placing the message in the user's mailbox. + + 6.2.2. ABBREVIATED DOMAIN SPECIFICATION + + Since any number of levels is possible within the domain + hierarchy, specification of a fully qualified address can + become inconvenient. This standard permits abbreviated domain + specification, in a special case: + + For the address of the sender, call the left-most + sub-domain Level N. In a header address, if all of + the sub-domains above (i.e., to the right of) Level N + are the same as those of the sender, then they do not + have to appear in the specification. Otherwise, the + address must be fully qualified. + + This feature is subject to approval by local sub- + domains. Individual sub-domains may require their + member systems, which originate mail, to provide full + domain specification only. When permitted, abbrevia- + tions may be present only while the message stays + within the sub-domain of the sender. + + Use of this mechanism requires the sender's sub-domain + to reserve the names of all top-level domains, so that + full specifications can be distinguished from abbrevi- + ated specifications. + + For example, if a sender's address is: + + sender@registry-A.registry-1.organization-X + + and one recipient's address is: + + recipient@registry-B.registry-1.organization-X + + and another's is: + + recipient@registry-C.registry-2.organization-X + + then ".registry-1.organization-X" need not be specified in the + the message, but "registry-C.registry-2" DOES have to be + specified. That is, the first two addresses may be abbrevi- + ated, but the third address must be fully specified. + + When a message crosses a domain boundary, all addresses must + be specified in the full format, ending with the top-level + name-domain in the right-most field. It is the responsibility + of mail forwarding services to ensure that addresses conform + + + August 13, 1982 - 29 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + with this requirement. In the case of abbreviated addresses, + the relaying service must make the necessary expansions. It + should be noted that it often is difficult for such a service + to locate all occurrences of address abbreviations. For exam- + ple, it will not be possible to find such abbreviations within + the body of the message. The "Return-Path" field can aid + recipients in recovering from these errors. + + Note: When passing any portion of an addr-spec onto a process + which does not interpret data according to this stan- + dard (e.g., mail protocol servers). There must be NO + LWSP-chars preceding or following the at-sign or any + delimiting period ("."), such as shown in the above + examples, and only ONE SPACE between contiguous + s. + + 6.2.3. DOMAIN TERMS + + A domain-ref must be THE official name of a registry, network, + or host. It is a symbolic reference, within a name sub- + domain. At times, it is necessary to bypass standard mechan- + isms for resolving such references, using more primitive + information, such as a network host address rather than its + associated host name. + + To permit such references, this standard provides the domain- + literal construct. Its contents must conform with the needs + of the sub-domain in which it is interpreted. + + Domain-literals which refer to domains within the ARPA Inter- + net specify 32-bit Internet addresses, in four 8-bit fields + noted in decimal, as described in Request for Comments #820, + "Assigned Numbers." For example: + + [10.0.3.19] + + Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It + is permitted only as a means of bypassing temporary + system limitations, such as name tables which are not + complete. + + The names of "top-level" domains, and the names of domains + under in the ARPA Internet, are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 6.2.4. DOMAIN-DEPENDENT LOCAL STRING + + The local-part of an addr-spec in a mailbox specification + (i.e., the host's name for the mailbox) is understood to be + + + August 13, 1982 - 30 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + whatever the receiving mail protocol server allows. For exam- + ple, some systems do not understand mailbox references of the + form "P. D. Q. Bach", but others do. + + This specification treats periods (".") as lexical separators. + Hence, their presence in local-parts which are not quoted- + strings, is detected. However, such occurrences carry NO + semantics. That is, if a local-part has periods within it, an + address parser will divide the local-part into several tokens, + but the sequence of tokens will be treated as one uninter- + preted unit. The sequence will be re-assembled, when the + address is passed outside of the system such as to a mail pro- + tocol service. + + For example, the address: + + First.Last@Registry.Org + + is legal and does not require the local-part to be surrounded + with quotation-marks. (However, "First Last" DOES require + quoting.) The local-part of the address, when passed outside + of the mail system, within the Registry.Org domain, is + "First.Last", again without quotation marks. + + 6.2.5. BALANCING LOCAL-PART AND DOMAIN + + In some cases, the boundary between local-part and domain can + be flexible. The local-part may be a simple string, which is + used for the final determination of the recipient's mailbox. + All other levels of reference are, therefore, part of the + domain. + + For some systems, in the case of abbreviated reference to the + local and subordinate sub-domains, it may be possible to + specify only one reference within the domain part and place + the other, subordinate name-domain references within the + local-part. This would appear as: + + mailbox.sub1.sub2@this-domain + + Such a specification would be acceptable to address parsers + which conform to RFC #733, but do not support this newer + Internet standard. While contrary to the intent of this stan- + dard, the form is legal. + + Also, some sub-domains have a specification syntax which does + not conform to this standard. For example: + + sub-net.mailbox@sub-domain.domain + + + August 13, 1982 - 31 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + uses a different parsing sequence for local-part than for + domain. + + Note: As a rule, the domain specification should contain + fields which are encoded according to the syntax of + this standard and which contain generally-standardized + information. The local-part specification should con- + tain only that portion of the address which deviates + from the form or intention of the domain field. + + 6.2.6. MULTIPLE MAILBOXES + + An individual may have several mailboxes and wish to receive + mail at whatever mailbox is convenient for the sender to + access. This standard does not provide a means of specifying + "any member of" a list of mailboxes. + + A set of individuals may wish to receive mail as a single unit + (i.e., a distribution list). The construct permits + specification of such a list. Recipient mailboxes are speci- + fied within the bracketed part (":" - ";"). A copy of the + transmitted message is to be sent to each mailbox listed. + This standard does not permit recursive specification of + groups within groups. + + While a list must be named, it is not required that the con- + tents of the list be included. In this case, the
+ serves only as an indication of group distribution and would + appear in the form: + + name:; + + Some mail services may provide a group-list distribution + facility, accepting a single mailbox reference, expanding it + to the full distribution list, and relaying the mail to the + list's members. This standard provides no additional syntax + for indicating such a service. Using the address + alternative, while listing one mailbox in it, can mean either + that the mailbox reference will be expanded to a list or that + there is a group with one member. + + 6.2.7. EXPLICIT PATH SPECIFICATION + + At times, a message originator may wish to indicate the + transmission path that a message should follow. This is + called source routing. The normal addressing scheme, used in + an addr-spec, is carefully separated from such information; + the portion of a route-addr is provided for such occa- + sions. It specifies the sequence of hosts and/or transmission + + + August 13, 1982 - 32 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + services that are to be traversed. Both domain-refs and + domain-literals may be used. + + Note: The use of source routing is discouraged. Unless the + sender has special need of path restriction, the choice + of transmission route should be left to the mail tran- + sport service. + + 6.3. RESERVED ADDRESS + + It often is necessary to send mail to a site, without know- + ing any of its valid addresses. For example, there may be mail + system dysfunctions, or a user may wish to find out a person's + correct address, at that site. + + This standard specifies a single, reserved mailbox address + (local-part) which is to be valid at each site. Mail sent to + that address is to be routed to a person responsible for the + site's mail system or to a person with responsibility for general + site operation. The name of the reserved local-part address is: + + Postmaster + + so that "Postmaster@domain" is required to be valid. + + Note: This reserved local-part must be matched without sensi- + tivity to alphabetic case, so that "POSTMASTER", "postmas- + ter", and even "poStmASteR" is to be accepted. + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 33 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 7. BIBLIOGRAPHY + + + ANSI. "USA Standard Code for Information Interchange," X3.4. + American National Standards Institute: New York (1968). Also + in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- + book", NIC 7104. + + ANSI. "Representations of Universal Time, Local Time Differen- + tials, and United States Time Zone References for Information + Interchange," X3.51-1975. American National Standards Insti- + tute: New York (1975). + + Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. + 1979). + + Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- + ford and Appleton Laboratory: Didcot, England. + + Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. + "Standardizing Network Mail Headers," ARPANET Request for + Comments No. 561, Network Information Center No. 18516; SRI + International: Menlo Park (September 1973). + + Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. + "Grapevine: An Exercise in Distributed Computing," Communica- + tions of the ACM 25, 4 (April 1982), 260-274. + + Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. + "Standard for the Format of ARPA Network Text Message," + ARPANET Request for Comments No. 733, Network Information + Center No. 41952. SRI International: Menlo Park (November + 1977). + + Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- + work Information Center No. 7104 (NTIS AD A003890). SRI + International: Menlo Park (April 1976). + + Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. + (1969). + + Levin, R. and Schroeder, M. "Transport of Electronic Messages + through a Network," TeleInformatics 79, pp. 29-33. North + Holland (1979). Also as Xerox Palo Alto Research Center + Technical Report CSL-79-4. + + Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," + ARPANET Request for Comments, No. 680, Network Information + Center No. 32116. SRI International: Menlo Park (1975). + + + August 13, 1982 - 34 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + NBS. "Specification of Message Format for Computer Based Message + Systems, Recommended Federal Information Processing Standard." + National Bureau of Standards: Gaithersburg, Maryland + (October 1981). + + NIC. Internet Protocol Transition Workbook. Network Information + Center, SRI-International, Menlo Park, California (March + 1982). + + Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized + Agent for Locating Named Objects in a Distributed Environ- + ment," OPD-T8103. Xerox Office Products Division: Palo Alto, + CA. (October 1981). + + Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, + No. 820. SRI International: Menlo Park (August 1982). + + Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request + for Comments, No. 821. SRI International: Menlo Park (August + 1982). + + Shoch, J.F. "Internetwork naming, addressing and routing," in + Proc. 17th IEEE Computer Society International Conference, pp. + 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. + + Su, Z. and Postel, J. "The Domain Naming Convention for Internet + User Applications," ARPANET Request for Comments, No. 819. + SRI International: Menlo Park (August 1982). + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 35 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + APPENDIX + + + A. EXAMPLES + + A.1. ADDRESSES + + A.1.1. Alfred Neuman + + A.1.2. Neuman@BBN-TENEXA + + These two "Alfred Neuman" examples have identical seman- + tics, as far as the operation of the local host's mail sending + (distribution) program (also sometimes called its "mailer") + and the remote host's mail protocol server are concerned. In + the first example, the "Alfred Neuman" is ignored by the + mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- + pient. The second example contains no superfluous informa- + tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- + pient. + + Note: When the message crosses name-domain boundaries, then + these specifications must be changed, so as to indicate + the remainder of the hierarchy, starting with the top + level. + + A.1.3. "George, Ted" + + This form might be used to indicate that a single mailbox + is shared by several users. The quoted string is ignored by + the originating host's mailer, because "Shared@Group.Arpanet" + completely specifies the destination mailbox. + + A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US + + The "(the Stilt)" is a comment, which is NOT included in + the destination mailbox address handed to the originating + system's mailer. The local-part of the address is the string + "Wilt.Chamberlain", with NO space between the first and second + words. + + A.1.5. Address Lists + + Gourmets: Pompous Person , + Childs@WGBH.Boston, Galloping Gourmet@ + ANT.Down-Under (Australian National Television), + Cheapie@Discount-Liquors;, + Cruisers: Port@Portugal, Jones@SEA;, + Another@Somewhere.SomeOrg + + + August 13, 1982 - 36 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + This group list example points out the use of comments and the + mixing of addresses and groups. + + A.2. ORIGINATOR ITEMS + + A.2.1. Author-sent + + George Jones logs into his host as "Jones". He sends + mail himself. + + From: Jones@Group.Org + + or + + From: George Jones + + A.2.2. Secretary-sent + + George Jones logs in as Jones on his host. His secre- + tary, who logs in as Secy sends mail for him. Replies to the + mail should go to George. + + From: George Jones + Sender: Secy@Other-Group + + A.2.3. Secretary-sent, for user of shared directory + + George Jones' secretary sends mail for George. Replies + should go to George. + + From: George Jones + Sender: Secy@Other-Group + + Note that there need not be a space between "Jones" and the + "<", but adding a space enhances readability (as is the case + in other examples. + + A.2.4. Committee activity, with one author + + George is a member of a committee. He wishes to have any + replies to his message go to all committee members. + + From: George Jones + Sender: Jones@Host + Reply-To: The Committee: Jones@Host.Net, + Smith@Other.Org, + Doe@Somewhere-Else; + + Note that if George had not included himself in the + + + August 13, 1982 - 37 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + enumeration of The Committee, he would not have gotten an + implicit reply; the presence of the "Reply-to" field SUPER- + SEDES the sending of a reply to the person named in the "From" + field. + + A.2.5. Secretary acting as full agent of author + + George Jones asks his secretary (Secy@Host) to send a + message for him in his capacity as Group. He wants his secre- + tary to handle all replies. + + From: George Jones + Sender: Secy@Host + Reply-To: Secy@Host + + A.2.6. Agent for user without online mailbox + + A friend of George's, Sarah, is visiting. George's + secretary sends some mail to a friend of Sarah in computer- + land. Replies should go to George, whose mailbox is Jones at + Registry. + + From: Sarah Friendly + Sender: Secy-Name + Reply-To: Jones@Registry. + + A.2.7. Agent for member of a committee + + George's secretary sends out a message which was authored + jointly by all the members of a committee. Note that the name + of the committee cannot be specified, since names are + not permitted in the From field. + + From: Jones@Host, + Smith@Other-Host, + Doe@Somewhere-Else + Sender: Secy@SHost + + + + + + + + + + + + + + + August 13, 1982 - 38 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + A.3. COMPLETE HEADERS + + A.3.1. Minimum required + + Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT + From: Jones@Registry.Org or From: Jones@Registry.Org + Bcc: To: Smith@Registry.Org + + Note that the "Bcc" field may be empty, while the "To" field + is required to have at least one address. + + A.3.2. Using some of the additional fields + + Date: 26 Aug 76 1430 EDT + From: George Jones + Sender: Secy@SHOST + To: "Al Neuman"@Mad-Host, + Sam.Irving@Other-Host + Message-ID: + + A.3.3. About as complex as you're going to get + + Date : 27 Aug 76 0932 PDT + From : Ken Davis + Subject : Re: The Syntax in the RFC + Sender : KSecy@Other-Host + Reply-To : Sam.Irving@Reg.Organization + To : George Jones , + Al.Neuman@MAD.Publisher + cc : Important folk: + Tom Softwood , + "Sam Irving"@Other-Host;, + Standard Distribution: + /main/davis/people/standard@Other-Host, + "standard.dist.3"@Tops-20-Host>; + Comment : Sam is away on business. He asked me to handle + his mail for him. He'll be able to provide a + more accurate explanation when he returns + next week. + In-Reply-To: , George's message + X-Special-action: This is a sample of user-defined field- + names. There could also be a field-name + "Special-action", but its name might later be + preempted + Message-ID: <4231.629.XYzi-What@Other-Host> + + + + + + + August 13, 1982 - 39 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + B. SIMPLE FIELD PARSING + + Some mail-reading software systems may wish to perform only + minimal processing, ignoring the internal syntax of structured + field-bodies and treating them the same as unstructured-field- + bodies. Such software will need only to distinguish: + + o Header fields from the message body, + + o Beginnings of fields from lines which continue fields, + + o Field-names from field-contents. + + The abbreviated set of syntactic rules which follows will + suffice for this purpose. It describes a limited view of mes- + sages and is a subset of the syntactic rules provided in the main + part of this specification. One small exception is that the con- + tents of field-bodies consist only of text: + + B.1. SYNTAX + + + message = *field *(CRLF *text) + + field = field-name ":" [field-body] CRLF + + field-name = 1* + + field-body = *text [CRLF LWSP-char field-body] + + + B.2. SEMANTICS + + Headers occur before the message body and are terminated by + a null line (i.e., two contiguous CRLFs). + + A line which continues a header field begins with a SPACE or + HTAB character, while a line beginning a field starts with a + printable character which is not a colon. + + A field-name consists of one or more printable characters + (excluding colon, space, and control-characters). A field-name + MUST be contained on one line. Upper and lower case are not dis- + tinguished when comparing field-names. + + + + + + + + August 13, 1982 - 40 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C. DIFFERENCES FROM RFC #733 + + The following summarizes the differences between this stan- + dard and the one specified in Arpanet Request for Comments #733, + "Standard for the Format of ARPA Network Text Messages". The + differences are listed in the order of their occurrence in the + current specification. + + C.1. FIELD DEFINITIONS + + C.1.1. FIELD NAMES + + These now must be a sequence of printable characters. They + may not contain any LWSP-chars. + + C.2. LEXICAL TOKENS + + C.2.1. SPECIALS + + The characters period ("."), left-square bracket ("["), and + right-square bracket ("]") have been added. For presentation + purposes, and when passing a specification to a system that + does not conform to this standard, periods are to be contigu- + ous with their surrounding lexical tokens. No linear-white- + space is permitted between them. The presence of one LWSP- + char between other tokens is still directed. + + C.2.2. ATOM + + Atoms may not contain SPACE. + + C.2.3. SPECIAL TEXT + + ctext and qtext have had backslash ("\") added to the list of + prohibited characters. + + C.2.4. DOMAINS + + The lexical tokens and have been + added. + + C.3. MESSAGE SPECIFICATION + + C.3.1. TRACE + + The "Return-path:" and "Received:" fields have been specified. + + + + + + August 13, 1982 - 41 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.3.2. FROM + + The "From" field must contain machine-usable addresses (addr- + spec). Multiple addresses may be specified, but named-lists + (groups) may not. + + C.3.3. RESENT + + The meta-construct of prefacing field names with the string + "Resent-" has been added, to indicate that a message has been + forwarded by an intermediate recipient. + + C.3.4. DESTINATION + + A message must contain at least one destination address field. + "To" and "CC" are required to contain at least one address. + + C.3.5. IN-REPLY-TO + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.6. REFERENCE + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.7. ENCRYPTED + + A field has been specified that permits senders to indicate + that the body of a message has been encrypted. + + C.3.8. EXTENSION-FIELD + + Extension fields are prohibited from beginning with the char- + acters "X-". + + C.4. DATE AND TIME SPECIFICATION + + C.4.1. SIMPLIFICATION + Fewer optional forms are permitted and the list of three- + letter time zones has been shortened. + + C.5. ADDRESS SPECIFICATION + + + + + + + August 13, 1982 - 42 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.5.1. ADDRESS + + The use of quoted-string, and the ":"-atom-":" construct, have + been removed. An address now is either a single mailbox + reference or is a named list of addresses. The latter indi- + cates a group distribution. + + C.5.2. GROUPS + + Group lists are now required to to have a name. Group lists + may not be nested. + + C.5.3. MAILBOX + + A mailbox specification may indicate a person's name, as + before. Such a named list no longer may specify multiple + mailboxes and may not be nested. + + C.5.4. ROUTE ADDRESSING + + Addresses now are taken to be absolute, global specifications, + independent of transmission paths. The construct has + been provided, to permit explicit specification of transmis- + sion path. RFC #733's use of multiple at-signs ("@") was + intended as a general syntax for indicating routing and/or + hierarchical addressing. The current standard separates these + specifications and only one at-sign is permitted. + + C.5.5. AT-SIGN + + The string " at " no longer is used as an address delimiter. + Only at-sign ("@") serves the function. + + C.5.6. DOMAINS + + Hierarchical, logical name-domains have been added. + + C.6. RESERVED ADDRESS + + The local-part "Postmaster" has been reserved, so that users can + be guaranteed at least one valid address at a site. + + + + + + + + + + + August 13, 1982 - 43 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + D. ALPHABETICAL LISTING OF SYNTAX RULES + + address = mailbox ; one addressee + / group ; named list + addr-spec = local-part "@" domain ; global address + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + atom = 1* + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + CHAR = ; ( 0-177, 0.-127.) + comment = "(" *(ctext / quoted-pair / comment) ")" + CR = ; ( 15, 13.) + CRLF = CR LF + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + CTL = ; ( 177, 127.) + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + dates = orig-date ; Original + [ resent-date ] ; Forwarded date-time = [ day "," ] date time ; dd mm yy ; hh:mm:ss zzz - day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" + delimiters = specials / linear-white-space / comment + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + DIGIT = ; ( 60- 71, 48.- 57.) + domain = sub-domain *("." sub-domain) + domain-literal = "[" *(dtext / quoted-pair) "]" + domain-ref = atom ; symbolic reference + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + extension-field = + + + + August 13, 1982 - 44 - RFC #822 - date = 1*2DIGIT month 2DIGIT ; day month year - ; e.g. 20 Jun 82 + + Standard for ARPA Internet Text Messages + + + field = field-name ":" [ field-body ] CRLF + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + field-body = field-body-contents + [CRLF LWSP-char field-body] + field-body-contents = + + field-name = 1* + group = phrase ":" [#mailbox] ";" + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + HTAB = ; ( 11, 9.) + LF = ; ( 12, 10.) + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + local-part = word *("." word) ; uninterpreted + ; case-preserved + LWSP-char = SPACE / HTAB ; semantics = SPACE + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" + msg-id = "<" addr-spec ">" ; Unique message id + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + orig-date = "Date" ":" date-time + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + phrase = 1*word ; Sequence of words + + + + August 13, 1982 - 45 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + quoted-pair = "\" CHAR ; may quote any char + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + ";" date-time ; time received + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + resent-date = "Resent-Date" ":" date-time + return = "Return-path" ":" route-addr ; return address + route = 1#("@" domain) ":" ; path-relative + route-addr = "<" [route] addr-spec ">" + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + SPACE = ; ( 40, 32.) + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + sub-domain = domain-ref / domain-literal + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. time = hour zone ; ANSI and Military + trace = return ; path to sender + 1*received ; receipt tags + user-defined-field = + + word = atom / quoted-string + + + + + August 13, 1982 - 46 - RFC #822 + + + + Standard for ARPA Internet Text Messages - hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] - ; 00:00:00 - 23:59:59 zone = "UT" / "GMT" ; Universal Time ; North American : UT @@ -31,25 +2853,49 @@ / "MST" / "MDT" ; Mountain: - 7/ - 6 / "PST" / "PDT" ; Pacific: - 8/ - 7 / 1ALPHA ; Military: Z = UT; - ; A:-1; (J not used) - ; M:-12; N:+1; Y:+12 - / ( ("+" / "-") 4DIGIT ) ; Local differential - ; hours+min. (HHMM) + <"> = ; ( 42, 34.) - 5.2. SEMANTICS - If included, day-of-week must be the day implied by the date - specification. - Time zone may be indicated in several ways. "UT" is Univer- - sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- - mitted as a reference to Universal Time. The military standard - uses a single character for each zone. "Z" is Universal Time. - "A" indicates one hour earlier, and "M" indicates 12 hours ear- - lier; "N" is one hour later, and "Y" is 12 hours later. The - letter "J" is not used. The other remaining two forms are taken - from ANSI standard X3.51-1975. One allows explicit indication of - the amount of offset from UT; the other uses common 3-character - strings for indicating time zones in North America. -[...] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 47 - RFC #822 + DateTime-Format-Mail-0.2901/notes/rfc822.txt /home/jas/rfc/rfc822.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/libd/libdatetime-format-mail-perl/libdatetime-format-mail-perl_0.2901.orig.tar.gz DateTime-Format-Mail-0.2901/notes/rfc2822.txt 6ba1204a2aea566a86dac9bb66b18c67 - DateTime-Format-Mail-0.2901/notes/rfc2822.txt 97c538a7a2df52a8470781dcbd2d456c - /home/jas/rfc/rfc2822.txt MISMATCH rfc2822.txt --- DateTime-Format-Mail-0.2901/notes/rfc2822.txt 2003-10-21 17:24:22.000000000 +0200 +++ /home/jas/rfc/rfc2822.txt 2001-04-18 17:43:45.000000000 +0200 @@ -1,159 +1,2716 @@ -[Extracts from RFC2822] -[...] + + + + +Network Working Group P. Resnick, Editor +Request for Comments: 2822 QUALCOMM Incorporated +Obsoletes: 822 April 2001 +Category: Standards Track + + + Internet Message Format + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This standard specifies a syntax for text messages that are sent + between computer users, within the framework of "electronic mail" + messages. This standard supersedes the one specified in Request For + Comments (RFC) 822, "Standard for the Format of ARPA Internet Text + Messages", updating it to reflect current practice and incorporating + incremental changes that were specified in other RFCs. + +Table of Contents + + 1. Introduction ............................................... 3 + 1.1. Scope .................................................... 3 + 1.2. Notational conventions ................................... 4 + 1.2.1. Requirements notation .................................. 4 + 1.2.2. Syntactic notation ..................................... 4 + 1.3. Structure of this document ............................... 4 + 2. Lexical Analysis of Messages ............................... 5 + 2.1. General Description ...................................... 5 + 2.1.1. Line Length Limits ..................................... 6 + 2.2. Header Fields ............................................ 7 + 2.2.1. Unstructured Header Field Bodies ....................... 7 + 2.2.2. Structured Header Field Bodies ......................... 7 + 2.2.3. Long Header Fields ..................................... 7 + 2.3. Body ..................................................... 8 + 3. Syntax ..................................................... 9 + 3.1. Introduction ............................................. 9 + 3.2. Lexical Tokens ........................................... 9 + + + +Resnick Standards Track [Page 1] + +RFC 2822 Internet Message Format April 2001 + + + 3.2.1. Primitive Tokens ....................................... 9 + 3.2.2. Quoted characters ......................................10 + 3.2.3. Folding white space and comments .......................11 + 3.2.4. Atom ...................................................12 + 3.2.5. Quoted strings .........................................13 + 3.2.6. Miscellaneous tokens ...................................13 + 3.3. Date and Time Specification ..............................14 + 3.4. Address Specification ....................................15 + 3.4.1. Addr-spec specification ................................16 + 3.5 Overall message syntax ....................................17 + 3.6. Field definitions ........................................18 + 3.6.1. The origination date field .............................20 + 3.6.2. Originator fields ......................................21 + 3.6.3. Destination address fields .............................22 + 3.6.4. Identification fields ..................................23 + 3.6.5. Informational fields ...................................26 + 3.6.6. Resent fields ..........................................26 + 3.6.7. Trace fields ...........................................28 + 3.6.8. Optional fields ........................................29 + 4. Obsolete Syntax ............................................29 + 4.1. Miscellaneous obsolete tokens ............................30 + 4.2. Obsolete folding white space .............................31 + 4.3. Obsolete Date and Time ...................................31 + 4.4. Obsolete Addressing ......................................33 + 4.5. Obsolete header fields ...................................33 + 4.5.1. Obsolete origination date field ........................34 + 4.5.2. Obsolete originator fields .............................34 + 4.5.3. Obsolete destination address fields ....................34 + 4.5.4. Obsolete identification fields .........................35 + 4.5.5. Obsolete informational fields ..........................35 + 4.5.6. Obsolete resent fields .................................35 + 4.5.7. Obsolete trace fields ..................................36 + 4.5.8. Obsolete optional fields ...............................36 + 5. Security Considerations ....................................36 + 6. Bibliography ...............................................37 + 7. Editor's Address ...........................................38 + 8. Acknowledgements ...........................................39 + Appendix A. Example messages ..................................41 + A.1. Addressing examples ......................................41 + A.1.1. A message from one person to another with simple + addressing .............................................41 + A.1.2. Different types of mailboxes ...........................42 + A.1.3. Group addresses ........................................43 + A.2. Reply messages ...........................................43 + A.3. Resent messages ..........................................44 + A.4. Messages with trace fields ...............................46 + A.5. White space, comments, and other oddities ................47 + A.6. Obsoleted forms ..........................................47 + + + +Resnick Standards Track [Page 2] + +RFC 2822 Internet Message Format April 2001 + + + A.6.1. Obsolete addressing ....................................48 + A.6.2. Obsolete dates .........................................48 + A.6.3. Obsolete white space and comments ......................48 + Appendix B. Differences from earlier standards ................49 + Appendix C. Notices ...........................................50 + Full Copyright Statement ......................................51 + +1. Introduction + +1.1. Scope + + This standard specifies a syntax for text messages that are sent + between computer users, within the framework of "electronic mail" + messages. This standard supersedes the one specified in Request For + Comments (RFC) 822, "Standard for the Format of ARPA Internet Text + Messages" [RFC822], updating it to reflect current practice and + incorporating incremental changes that were specified in other RFCs + [STD3]. + + This standard specifies a syntax only for text messages. In + particular, it makes no provision for the transmission of images, + audio, or other sorts of structured data in electronic mail messages. + There are several extensions published, such as the MIME document + series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the + transmission of such data through electronic mail, either by + extending the syntax provided here or by structuring such messages to + conform to this syntax. Those mechanisms are outside of the scope of + this standard. + + In the context of electronic mail, messages are viewed as having an + envelope and contents. The envelope contains whatever information is + needed to accomplish transmission and delivery. (See [RFC2821] for a + discussion of the envelope.) The contents comprise the object to be + delivered to the recipient. This standard applies only to the format + and some of the semantics of message contents. It contains no + specification of the information in the envelope. + + However, some message systems may use information from the contents + to create the envelope. It is intended that this standard facilitate + the acquisition of such information by programs. + + This specification is intended as a definition of what message + content format is to be passed between systems. Though some message + systems locally store messages in this format (which eliminates the + need for translation between formats) and others use formats that + differ from the one specified in this standard, local storage is + outside of the scope of this standard. + + + + +Resnick Standards Track [Page 3] + +RFC 2822 Internet Message Format April 2001 + + + Note: This standard is not intended to dictate the internal formats + used by sites, the specific message system features that they are + expected to support, or any of the characteristics of user interface + programs that create or read messages. In addition, this standard + does not specify an encoding of the characters for either transport + or storage; that is, it does not specify the number of bits used or + how those bits are specifically transferred over the wire or stored + on disk. + +1.2. Notational conventions + +1.2.1. Requirements notation + + This document occasionally uses terms that appear in capital letters. + When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD + NOT", and "MAY" appear capitalized, they are being used to indicate + particular requirements of this specification. A discussion of the + meanings of these terms appears in [RFC2119]. + +1.2.2. Syntactic notation + + This standard uses the Augmented Backus-Naur Form (ABNF) notation + specified in [RFC2234] for the formal definitions of the syntax of + messages. Characters will be specified either by a decimal value + (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by + a case-insensitive literal value enclosed in quotation marks (e.g., + "A" for either uppercase or lowercase A). See [RFC2234] for the full + description of the notation. + +1.3. Structure of this document + + This document is divided into several sections. + + This section, section 1, is a short introduction to the document. + + Section 2 lays out the general description of a message and its + constituent parts. This is an overview to help the reader understand + some of the general principles used in the later portions of this + document. Any examples in this section MUST NOT be taken as + specification of the formal syntax of any part of a message. + + Section 3 specifies formal ABNF rules for the structure of each part + of a message (the syntax) and describes the relationship between + those parts and their meaning in the context of a message (the + semantics). That is, it describes the actual rules for the structure + of each part of a message (the syntax) as well as a description of + the parts and instructions on how they ought to be interpreted (the + semantics). This includes analysis of the syntax and semantics of + + + +Resnick Standards Track [Page 4] + +RFC 2822 Internet Message Format April 2001 + + + subparts of messages that have specific structure. The syntax + included in section 3 represents messages as they MUST be created. + There are also notes in section 3 to indicate if any of the options + specified in the syntax SHOULD be used over any of the others. + + Both sections 2 and 3 describe messages that are legal to generate + for purposes of this standard. + + Section 4 of this document specifies an "obsolete" syntax. There are + references in section 3 to these obsolete syntactic elements. The + rules of the obsolete syntax are elements that have appeared in + earlier revisions of this standard or have previously been widely + used in Internet messages. As such, these elements MUST be + interpreted by parsers of messages in order to be conformant to this + standard. However, since items in this syntax have been determined + to be non-interoperable or to cause significant problems for + recipients of messages, they MUST NOT be generated by creators of + conformant messages. + + Section 5 details security considerations to take into account when + implementing this standard. + + Section 6 is a bibliography of references in this document. + + Section 7 contains the editor's address. + + Section 8 contains acknowledgements. + + Appendix A lists examples of different sorts of messages. These + examples are not exhaustive of the types of messages that appear on + the Internet, but give a broad overview of certain syntactic forms. + + Appendix B lists the differences between this standard and earlier + standards for Internet messages. + + Appendix C has copyright and intellectual property notices. + +2. Lexical Analysis of Messages + +2.1. General Description + + At the most basic level, a message is a series of characters. A + message that is conformant with this standard is comprised of + characters with values in the range 1 through 127 and interpreted as + US-ASCII characters [ASCII]. For brevity, this document sometimes + refers to this range of characters as simply "US-ASCII characters". + + + + + +Resnick Standards Track [Page 5] + +RFC 2822 Internet Message Format April 2001 + + + Note: This standard specifies that messages are made up of characters + in the US-ASCII range of 1 through 127. There are other documents, + specifically the MIME document series [RFC2045, RFC2046, RFC2047, + RFC2048, RFC2049], that extend this standard to allow for values + outside of that range. Discussion of those mechanisms is not within + the scope of this standard. + + Messages are divided into lines of characters. A line is a series of + characters that is delimited with the two characters carriage-return + and line-feed; that is, the carriage return (CR) character (ASCII + value 13) followed immediately by the line feed (LF) character (ASCII + value 10). (The carriage-return/line-feed pair is usually written in + this document as "CRLF".) + + A message consists of header fields (collectively called "the header + of the message") followed, optionally, by a body. The header is a + sequence of lines of characters with special syntax as defined in + this standard. The body is simply a sequence of characters that + follows the header and is separated from the header by an empty line + (i.e., a line with nothing preceding the CRLF). + +2.1.1. Line Length Limits + + There are two limits that this standard places on the number of + characters in a line. Each line of characters MUST be no more than + 998 characters, and SHOULD be no more than 78 characters, excluding + the CRLF. + + The 998 character limit is due to limitations in many implementations + which send, receive, or store Internet Message Format messages that + simply cannot handle more than 998 characters on a line. Receiving + implementations would do well to handle an arbitrarily large number + of characters in a line for robustness sake. However, there are so + many implementations which (in compliance with the transport + requirements of [RFC2821]) do not accept messages containing more + than 1000 character including the CR and LF per line, it is important + for implementations not to create such messages. + + The more conservative 78 character recommendation is to accommodate + the many implementations of user interfaces that display these + messages which may truncate, or disastrously wrap, the display of + more than 78 characters per line, in spite of the fact that such + implementations are non-conformant to the intent of this + specification (and that of [RFC2821] if they actually cause + information to be lost). Again, even though this limitation is put on + messages, it is encumbant upon implementations which display messages + + + + + +Resnick Standards Track [Page 6] + +RFC 2822 Internet Message Format April 2001 + + + to handle an arbitrarily large number of characters in a line + (certainly at least up to the 998 character limit) for the sake of + robustness. + +2.2. Header Fields + + Header fields are lines composed of a field name, followed by a colon + (":"), followed by a field body, and terminated by CRLF. A field + name MUST be composed of printable US-ASCII characters (i.e., + characters that have values between 33 and 126, inclusive), except + colon. A field body may be composed of any US-ASCII characters, + except for CR and LF. However, a field body may contain CRLF when + used in header "folding" and "unfolding" as described in section + 2.2.3. All field bodies MUST conform to the syntax described in + sections 3 and 4 of this standard. + +2.2.1. Unstructured Header Field Bodies + + Some field bodies in this standard are defined simply as + "unstructured" (which is specified below as any US-ASCII characters, + except for CR and LF) with no further restrictions. These are + referred to as unstructured field bodies. Semantically, unstructured + field bodies are simply to be treated as a single line of characters + with no further processing (except for header "folding" and + "unfolding" as described in section 2.2.3). + +2.2.2. Structured Header Field Bodies + + Some field bodies in this standard have specific syntactical + structure more restrictive than the unstructured field bodies + described above. These are referred to as "structured" field bodies. + Structured field bodies are sequences of specific lexical tokens as + described in sections 3 and 4 of this standard. Many of these tokens + are allowed (according to their syntax) to be introduced or end with + comments (as described in section 3.2.3) as well as the space (SP, + ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters + (together known as the white space characters, WSP), and those WSP + characters are subject to header "folding" and "unfolding" as + described in section 2.2.3. Semantic analysis of structured field + bodies is given along with their syntax. + +2.2.3. Long Header Fields + + Each header field is logically a single line of characters comprising + the field name, the colon, and the field body. For convenience + however, and to deal with the 998/78 character limitations per line, + the field body portion of a header field can be split into a multiple + line representation; this is called "folding". The general rule is + + + +Resnick Standards Track [Page 7] + +RFC 2822 Internet Message Format April 2001 + + + that wherever this standard allows for folding white space (not + simply WSP characters), a CRLF may be inserted before any WSP. For + example, the header field: + + Subject: This is a test + + can be represented as: + + Subject: This + is a test + + Note: Though structured field bodies are defined in such a way that + folding can take place between many of the lexical tokens (and even + within some of the lexical tokens), folding SHOULD be limited to + placing the CRLF at higher-level syntactic breaks. For instance, if + a field body is defined as comma-separated values, it is recommended + that folding occur after the comma separating the structured items in + preference to other places where the field could be folded, even if + it is allowed elsewhere. + + The process of moving from this folded multiple-line representation + of a header field to its single line representation is called + "unfolding". Unfolding is accomplished by simply removing any CRLF + that is immediately followed by WSP. Each header field should be + treated in its unfolded form for further syntactic and semantic + evaluation. + +2.3. Body + + The body of a message is simply lines of US-ASCII characters. The + only two limitations on the body are as follows: + + - CR and LF MUST only occur together as CRLF; they MUST NOT appear + independently in the body. + + - Lines of characters in the body MUST be limited to 998 characters, + and SHOULD be limited to 78 characters, excluding the CRLF. + + Note: As was stated earlier, there are other standards documents, + specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049] + that extend this standard to allow for different sorts of message + bodies. Again, these mechanisms are beyond the scope of this + document. + + + + + + + + +Resnick Standards Track [Page 8] + +RFC 2822 Internet Message Format April 2001 + + +3. Syntax + +3.1. Introduction + + The syntax as given in this section defines the legal syntax of + Internet messages. Messages that are conformant to this standard + MUST conform to the syntax in this section. If there are options in + this section where one option SHOULD be generated, that is indicated + either in the prose or in a comment next to the syntax. + + For the defined expressions, a short description of the syntax and + use is given, followed by the syntax in ABNF, followed by a semantic + analysis. Primitive tokens that are used but otherwise unspecified + come from [RFC2234]. + + In some of the definitions, there will be nonterminals whose names + start with "obs-". These "obs-" elements refer to tokens defined in + the obsolete syntax in section 4. In all cases, these productions + are to be ignored for the purposes of generating legal Internet + messages and MUST NOT be used as part of such a message. However, + when interpreting messages, these tokens MUST be honored as part of + the legal syntax. In this sense, section 3 defines a grammar for + generation of messages, with "obs-" elements that are to be ignored, + while section 4 adds grammar for interpretation of messages. + +3.2. Lexical Tokens + + The following rules are used to define an underlying lexical + analyzer, which feeds tokens to the higher-level parsers. This + section defines the tokens used in structured header field bodies. + + Note: Readers of this standard need to pay special attention to how + these lexical tokens are used in both the lower-level and + higher-level syntax later in the document. Particularly, the white + space tokens and the comment tokens defined in section 3.2.3 get used + in the lower-level tokens defined here, and those lower-level tokens + are in turn used as parts of the higher-level tokens defined later. + Therefore, the white space and comments may be allowed in the + higher-level tokens even though they may not explicitly appear in a + particular definition. + +3.2.1. Primitive Tokens + + The following are primitive tokens referred to elsewhere in this + standard, but not otherwise defined in [RFC2234]. Some of them will + not appear anywhere else in the syntax, but they are convenient to + refer to in other parts of this document. + + + + +Resnick Standards Track [Page 9] + +RFC 2822 Internet Message Format April 2001 + + + Note: The "specials" below are just such an example. Though the + specials token does not appear anywhere else in this standard, it is + useful for implementers who use tools that lexically analyze + messages. Each of the characters in specials can be used to indicate + a tokenization point in lexical analysis. + +NO-WS-CTL = %d1-8 / ; US-ASCII control characters + %d11 / ; that do not include the + %d12 / ; carriage return, line feed, + %d14-31 / ; and white space characters + %d127 + +text = %d1-9 / ; Characters excluding CR and LF + %d11 / + %d12 / + %d14-127 / + obs-text + +specials = "(" / ")" / ; Special characters used in + "<" / ">" / ; other parts of the syntax + "[" / "]" / + ":" / ";" / + "@" / "\" / + "," / "." / + DQUOTE + + No special semantics are attached to these tokens. They are simply + single characters. + +3.2.2. Quoted characters + + Some characters are reserved for special interpretation, such as + delimiting lexical tokens. To permit use of these characters as + uninterpreted data, a quoting mechanism is provided. + +quoted-pair = ("\" text) / obs-qp + + Where any quoted-pair appears, it is to be interpreted as the text + character alone. That is to say, the "\" character that appears as + part of a quoted-pair is semantically "invisible". + + Note: The "\" character may appear in a message where it is not part + of a quoted-pair. A "\" character that does not appear in a + quoted-pair is not semantically invisible. The only places in this + standard where quoted-pair currently appears are ccontent, qcontent, + dcontent, no-fold-quote, and no-fold-literal. + + + + + +Resnick Standards Track [Page 10] + +RFC 2822 Internet Message Format April 2001 + + +3.2.3. Folding white space and comments + + White space characters, including white space used in folding + (described in section 2.2.3), may appear between many elements in + header field bodies. Also, strings of characters that are treated as + comments may be included in structured field bodies as characters + enclosed in parentheses. The following defines the folding white + space (FWS) and comment constructs. + + Strings of characters enclosed in parentheses are considered comments + so long as they do not appear within a "quoted-string", as defined in + section 3.2.5. Comments may nest. + + There are several places in this standard where comments and FWS may + be freely inserted. To accommodate that syntax, an additional token + for "CFWS" is defined for places where comments and/or FWS can occur. + However, where CFWS occurs in this standard, it MUST NOT be inserted + in such a way that any line of a folded header field is made up + entirely of WSP characters and nothing else. + +FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space + obs-FWS + +ctext = NO-WS-CTL / ; Non white space controls + + %d33-39 / ; The rest of the US-ASCII + %d42-91 / ; characters not including "(", + %d93-126 ; ")", or "\" + +ccontent = ctext / quoted-pair / comment + +comment = "(" *([FWS] ccontent) [FWS] ")" + +CFWS = *([FWS] comment) (([FWS] comment) / FWS) + + Throughout this standard, where FWS (the folding white space token) + appears, it indicates a place where header folding, as discussed in + section 2.2.3, may take place. Wherever header folding appears in a + message (that is, a header field body containing a CRLF followed by + any WSP), header unfolding (removal of the CRLF) is performed before + any further lexical analysis is performed on that header field + according to this standard. That is to say, any CRLF that appears in + FWS is semantically "invisible." + + A comment is normally used in a structured field body to provide some + human readable informational text. Since a comment is allowed to + contain FWS, folding is permitted within the comment. Also note that + since quoted-pair is allowed in a comment, the parentheses and + + + +Resnick Standards Track [Page 11] + +RFC 2822 Internet Message Format April 2001 + + + backslash characters may appear in a comment so long as they appear + as a quoted-pair. Semantically, the enclosing parentheses are not + part of the comment; the comment is what is contained between the two + parentheses. As stated earlier, the "\" in any quoted-pair and the + CRLF in any FWS that appears within the comment are semantically + "invisible" and therefore not part of the comment either. + + Runs of FWS, comment or CFWS that occur between lexical tokens in a + structured field header are semantically interpreted as a single + space character. + +3.2.4. Atom + + Several productions in structured header field bodies are simply + strings of certain basic characters. Such productions are called + atoms. + + Some of the structured header field bodies also allow the period + character (".", ASCII value 46) within runs of atext. An additional + "dot-atom" token is defined for those purposes. + +atext = ALPHA / DIGIT / ; Any character except controls, + "!" / "#" / ; SP, and specials. + "$" / "%" / ; Used for atoms + "&" / "'" / + "*" / "+" / + "-" / "/" / + "=" / "?" / + "^" / "_" / + "`" / "{" / + "|" / "}" / + "~" + +atom = [CFWS] 1*atext [CFWS] + +dot-atom = [CFWS] dot-atom-text [CFWS] + +dot-atom-text = 1*atext *("." 1*atext) + + Both atom and dot-atom are interpreted as a single unit, comprised of + the string of characters that make it up. Semantically, the optional + comments and FWS surrounding the rest of the characters are not part + of the atom; the atom is only the run of atext characters in an atom, + or the atext and "." characters in a dot-atom. + + + + + + + +Resnick Standards Track [Page 12] + +RFC 2822 Internet Message Format April 2001 + + +3.2.5. Quoted strings + + Strings of characters that include characters other than those + allowed in atoms may be represented in a quoted string format, where + the characters are surrounded by quote (DQUOTE, ASCII value 34) + characters. + +qtext = NO-WS-CTL / ; Non white space controls + + %d33 / ; The rest of the US-ASCII + %d35-91 / ; characters not including "\" + %d93-126 ; or the quote character + +qcontent = qtext / quoted-pair + +quoted-string = [CFWS] + DQUOTE *([FWS] qcontent) [FWS] DQUOTE + [CFWS] + + A quoted-string is treated as a unit. That is, quoted-string is + identical to atom, semantically. Since a quoted-string is allowed to + contain FWS, folding is permitted. Also note that since quoted-pair + is allowed in a quoted-string, the quote and backslash characters may + appear in a quoted-string so long as they appear as a quoted-pair. + + Semantically, neither the optional CFWS outside of the quote + characters nor the quote characters themselves are part of the + quoted-string; the quoted-string is what is contained between the two + quote characters. As stated earlier, the "\" in any quoted-pair and + the CRLF in any FWS/CFWS that appears within the quoted-string are + semantically "invisible" and therefore not part of the quoted-string + either. + +3.2.6. Miscellaneous tokens + + Three additional tokens are defined, word and phrase for combinations + of atoms and/or quoted-strings, and unstructured for use in + unstructured header fields and in some places within structured + header fields. + +word = atom / quoted-string + +phrase = 1*word / obs-phrase + + + + + + + + +Resnick Standards Track [Page 13] + +RFC 2822 Internet Message Format April 2001 + + +utext = NO-WS-CTL / ; Non white space controls + %d33-126 / ; The rest of US-ASCII + obs-utext + +unstructured = *([FWS] utext) [FWS] 3.3. Date and Time Specification - Date and time occur in several header fields. This section specifies - the syntax for a full date and time specification. Though folding - white space is permitted throughout the date-time specification, it - is RECOMMENDED that a single space be used in each place that FWS - appears (whether it is required or optional); some older - implementations may not interpret other occurrences of folding white - space correctly. + Date and time occur in several header fields. This section specifies + the syntax for a full date and time specification. Though folding + white space is permitted throughout the date-time specification, it + is RECOMMENDED that a single space be used in each place that FWS + appears (whether it is required or optional); some older + implementations may not interpret other occurrences of folding white + space correctly. + +date-time = [ day-of-week "," ] date FWS time [CFWS] + +day-of-week = ([FWS] day-name) / obs-day-of-week + +day-name = "Mon" / "Tue" / "Wed" / "Thu" / + "Fri" / "Sat" / "Sun" + +date = day month year + +year = 4*DIGIT / obs-year + +month = (FWS month-name FWS) / obs-month + +month-name = "Jan" / "Feb" / "Mar" / "Apr" / + "May" / "Jun" / "Jul" / "Aug" / + "Sep" / "Oct" / "Nov" / "Dec" + +day = ([FWS] 1*2DIGIT) / obs-day + +time = time-of-day FWS zone + +time-of-day = hour ":" minute [ ":" second ] + +hour = 2DIGIT / obs-hour + +minute = 2DIGIT / obs-minute + +second = 2DIGIT / obs-second + +zone = (( "+" / "-" ) 4DIGIT) / obs-zone + + + + + +Resnick Standards Track [Page 14] + +RFC 2822 Internet Message Format April 2001 + + + The day is the numeric day of the month. The year is any numeric + year 1900 or later. + + The time-of-day specifies the number of hours, minutes, and + optionally seconds since midnight of the date indicated. + + The date and time-of-day SHOULD express local time. + + The zone specifies the offset from Coordinated Universal Time (UTC, + formerly referred to as "Greenwich Mean Time") that the date and + time-of-day represent. The "+" or "-" indicates whether the + time-of-day is ahead of (i.e., east of) or behind (i.e., west of) + Universal Time. The first two digits indicate the number of hours + difference from Universal Time, and the last two digits indicate the + number of minutes difference from Universal Time. (Hence, +hhmm + means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) + minutes). The form "+0000" SHOULD be used to indicate a time zone at + Universal Time. Though "-0000" also indicates Universal Time, it is + used to indicate that the time was generated on a system that may be + in a local time zone other than Universal Time and therefore + indicates that the date-time contains no information about the local + time zone. + + A date-time specification MUST be semantically valid. That is, the + day-of-the-week (if included) MUST be the day implied by the date, + the numeric day-of-month MUST be between 1 and the number of days + allowed for the specified month (in the specified year), the + time-of-day MUST be in the range 00:00:00 through 23:59:60 (the + number of seconds allowing for a leap second; see [STD12]), and the + zone MUST be within the range -9959 through +9959. + +3.4. Address Specification + + Addresses occur in several message header fields to indicate senders + and recipients of messages. An address may either be an individual + mailbox, or a group of mailboxes. + +address = mailbox / group + +mailbox = name-addr / addr-spec + +name-addr = [display-name] angle-addr + +angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr + +group = display-name ":" [mailbox-list / CFWS] ";" + [CFWS] + + + + +Resnick Standards Track [Page 15] + +RFC 2822 Internet Message Format April 2001 + + +display-name = phrase + +mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list + +address-list = (address *("," address)) / obs-addr-list + + A mailbox receives mail. It is a conceptual entity which does not + necessarily pertain to file storage. For example, some sites may + choose to print mail on a printer and deliver the output to the + addressee's desk. Normally, a mailbox is comprised of two parts: (1) + an optional display name that indicates the name of the recipient + (which could be a person or a system) that could be displayed to the + user of a mail application, and (2) an addr-spec address enclosed in + angle brackets ("<" and ">"). There is also an alternate simple form + of a mailbox where the addr-spec address appears alone, without the + recipient's name or the angle brackets. The Internet addr-spec + address is described in section 3.4.1. + + Note: Some legacy implementations used the simple form where the + addr-spec appears without the angle brackets, but included the name + of the recipient in parentheses as a comment following the addr-spec. + Since the meaning of the information in a comment is unspecified, + implementations SHOULD use the full name-addr form of the mailbox, + instead of the legacy form, to specify the display name associated + with a mailbox. Also, because some legacy implementations interpret + the comment, comments generally SHOULD NOT be used in address fields + to avoid confusing such implementations. + + When it is desirable to treat several mailboxes as a single unit + (i.e., in a distribution list), the group construct can be used. The + group construct allows the sender to indicate a named group of + recipients. This is done by giving a display name for the group, + followed by a colon, followed by a comma separated list of any number + of mailboxes (including zero and one), and ending with a semicolon. + Because the list of mailboxes can be empty, using the group construct + is also a simple way to communicate to recipients that the message + was sent to one or more named sets of recipients, without actually + providing the individual mailbox address for each of those + recipients. + +3.4.1. Addr-spec specification + + An addr-spec is a specific Internet identifier that contains a + locally interpreted string followed by the at-sign character ("@", + ASCII value 64) followed by an Internet domain. The locally + interpreted string is either a quoted-string or a dot-atom. If the + string can be represented as a dot-atom (that is, it contains no + characters other than atext characters or "." surrounded by atext + + + +Resnick Standards Track [Page 16] + +RFC 2822 Internet Message Format April 2001 + + + characters), then the dot-atom form SHOULD be used and the + quoted-string form SHOULD NOT be used. Comments and folding white + space SHOULD NOT be used around the "@" in the addr-spec. + +addr-spec = local-part "@" domain + +local-part = dot-atom / quoted-string / obs-local-part + +domain = dot-atom / domain-literal / obs-domain + +domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] + +dcontent = dtext / quoted-pair + +dtext = NO-WS-CTL / ; Non white space controls + + %d33-90 / ; The rest of the US-ASCII + %d94-126 ; characters not including "[", + ; "]", or "\" + + The domain portion identifies the point to which the mail is + delivered. In the dot-atom form, this is interpreted as an Internet + domain name (either a host name or a mail exchanger name) as + described in [STD3, STD13, STD14]. In the domain-literal form, the + domain is interpreted as the literal Internet address of the + particular host. In both cases, how addressing is used and how + messages are transported to a particular host is covered in the mail + transport document [RFC2821]. These mechanisms are outside of the + scope of this document. + + The local-part portion is a domain dependent string. In addresses, + it is simply interpreted on the particular host as a name of a + particular mailbox. + +3.5 Overall message syntax + + A message consists of header fields, optionally followed by a message + body. Lines in a message MUST be a maximum of 998 characters + excluding the CRLF, but it is RECOMMENDED that lines be limited to 78 + characters excluding the CRLF. (See section 2.1.1 for explanation.) + In a message body, though all of the characters listed in the text + rule MAY be used, the use of US-ASCII control characters (values 1 + through 8, 11, 12, and 14 through 31) is discouraged since their + interpretation by receivers for display is not guaranteed. + + + + + + + +Resnick Standards Track [Page 17] + +RFC 2822 Internet Message Format April 2001 + + +message = (fields / obs-fields) + [CRLF body] + +body = *(*998text CRLF) *998text + + The header fields carry most of the semantic information and are + defined in section 3.6. The body is simply a series of lines of text + which are uninterpreted for the purposes of this standard. + +3.6. Field definitions + + The header fields of a message are defined here. All header fields + have the same general syntactic structure: A field name, followed by + a colon, followed by the field body. The specific syntax for each + header field is defined in the subsequent sections. + + Note: In the ABNF syntax for each field in subsequent sections, each + field name is followed by the required colon. However, for brevity + sometimes the colon is not referred to in the textual description of + the syntax. It is, nonetheless, required. + + It is important to note that the header fields are not guaranteed to + be in a particular order. They may appear in any order, and they + have been known to be reordered occasionally when transported over + the Internet. However, for the purposes of this standard, header + fields SHOULD NOT be reordered when a message is transported or + transformed. More importantly, the trace header fields and resent + header fields MUST NOT be reordered, and SHOULD be kept in blocks + prepended to the message. See sections 3.6.6 and 3.6.7 for more + information. + + The only required header fields are the origination date field and + the originator address field(s). All other header fields are + syntactically optional. More information is contained in the table + following this definition. + +fields = *(trace + *(resent-date / + resent-from / + resent-sender / + resent-to / + resent-cc / + resent-bcc / + resent-msg-id)) + *(orig-date / + from / + sender / + reply-to / + + + +Resnick Standards Track [Page 18] + +RFC 2822 Internet Message Format April 2001 + + + to / + cc / + bcc / + message-id / + in-reply-to / + references / + subject / + comments / + keywords / + optional-field) + + The following table indicates limits on the number of times each + field may occur in a message header as well as any special + limitations on the use of those fields. An asterisk next to a value + in the minimum or maximum column indicates that a special restriction + appears in the Notes column. + +Field Min number Max number Notes + +trace 0 unlimited Block prepended - see + 3.6.7 + +resent-date 0* unlimited* One per block, required + if other resent fields + present - see 3.6.6 + +resent-from 0 unlimited* One per block - see + 3.6.6 + +resent-sender 0* unlimited* One per block, MUST + occur with multi-address + resent-from - see 3.6.6 + +resent-to 0 unlimited* One per block - see + 3.6.6 + +resent-cc 0 unlimited* One per block - see + 3.6.6 + +resent-bcc 0 unlimited* One per block - see + 3.6.6 + +resent-msg-id 0 unlimited* One per block - see + 3.6.6 + +orig-date 1 1 + +from 1 1 See sender and 3.6.2 + + + +Resnick Standards Track [Page 19] + +RFC 2822 Internet Message Format April 2001 + + +sender 0* 1 MUST occur with multi- + address from - see 3.6.2 + +reply-to 0 1 + +to 0 1 + +cc 0 1 + +bcc 0 1 + +message-id 0* 1 SHOULD be present - see + 3.6.4 + +in-reply-to 0* 1 SHOULD occur in some + replies - see 3.6.4 + +references 0* 1 SHOULD occur in some + replies - see 3.6.4 + +subject 0 1 + +comments 0 unlimited + +keywords 0 unlimited + +optional-field 0 unlimited + + The exact interpretation of each field is described in subsequent + sections. + +3.6.1. The origination date field + + The origination date field consists of the field name "Date" followed + by a date-time specification. + +orig-date = "Date:" date-time CRLF + + The origination date specifies the date and time at which the creator + of the message indicated that the message was complete and ready to + enter the mail delivery system. For instance, this might be the time + that a user pushes the "send" or "submit" button in an application + program. In any case, it is specifically not intended to convey the + time that the message is actually transported, but rather the time at + which the human or other creator of the message has put the message + into its final form, ready for transport. (For example, a portable + computer user who is not connected to a network might queue a message + + + + +Resnick Standards Track [Page 20] + +RFC 2822 Internet Message Format April 2001 + + + for delivery. The origination date is intended to contain the date + and time that the user queued the message, not the time when the user + connected to the network to send the message.) + +3.6.2. Originator fields + + The originator fields of a message consist of the from field, the + sender field (when applicable), and optionally the reply-to field. + The from field consists of the field name "From" and a + comma-separated list of one or more mailbox specifications. If the + from field contains more than one mailbox specification in the + mailbox-list, then the sender field, containing the field name + "Sender" and a single mailbox specification, MUST appear in the + message. In either case, an optional reply-to field MAY also be + included, which contains the field name "Reply-To" and a + comma-separated list of one or more addresses. + +from = "From:" mailbox-list CRLF + +sender = "Sender:" mailbox CRLF + +reply-to = "Reply-To:" address-list CRLF + + The originator fields indicate the mailbox(es) of the source of the + message. The "From:" field specifies the author(s) of the message, + that is, the mailbox(es) of the person(s) or system(s) responsible + for the writing of the message. The "Sender:" field specifies the + mailbox of the agent responsible for the actual transmission of the + message. For example, if a secretary were to send a message for + another person, the mailbox of the secretary would appear in the + "Sender:" field and the mailbox of the actual author would appear in + the "From:" field. If the originator of the message can be indicated + by a single mailbox and the author and transmitter are identical, the + "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD + appear. + + The originator fields also provide the information required when + replying to a message. When the "Reply-To:" field is present, it + indicates the mailbox(es) to which the author of the message suggests + that replies be sent. In the absence of the "Reply-To:" field, + replies SHOULD by default be sent to the mailbox(es) specified in the + "From:" field unless otherwise specified by the person composing the + reply. + + In all cases, the "From:" field SHOULD NOT contain any mailbox that + does not belong to the author(s) of the message. See also section + 3.6.3 for more information on forming the destination addresses for a + reply. + + + +Resnick Standards Track [Page 21] + +RFC 2822 Internet Message Format April 2001 + + +3.6.3. Destination address fields + + The destination fields of a message consist of three possible fields, + each of the same form: The field name, which is either "To", "Cc", or + "Bcc", followed by a comma-separated list of one or more addresses + (either mailbox or group syntax). + +to = "To:" address-list CRLF + +cc = "Cc:" address-list CRLF + +bcc = "Bcc:" (address-list / [CFWS]) CRLF + + The destination fields specify the recipients of the message. Each + destination field may have one or more addresses, and each of the + addresses indicate the intended recipients of the message. The only + difference between the three fields is how each is used. + + The "To:" field contains the address(es) of the primary recipient(s) + of the message. + + The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of + making a copy on a typewriter using carbon paper) contains the + addresses of others who are to receive the message, though the + content of the message may not be directed at them. + + The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains + addresses of recipients of the message whose addresses are not to be + revealed to other recipients of the message. There are three ways in + which the "Bcc:" field is used. In the first case, when a message + containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is + removed even though all of the recipients (including those specified + in the "Bcc:" field) are sent a copy of the message. In the second + case, recipients specified in the "To:" and "Cc:" lines each are sent + a copy of the message with the "Bcc:" line removed as above, but the + recipients on the "Bcc:" line get a separate copy of the message + containing a "Bcc:" line. (When there are multiple recipient + addresses in the "Bcc:" field, some implementations actually send a + separate copy of the message to each recipient with a "Bcc:" + containing only the address of that particular recipient.) Finally, + since a "Bcc:" field may contain no addresses, a "Bcc:" field can be + sent without any addresses indicating to the recipients that blind + copies were sent to someone. Which method to use with "Bcc:" fields + is implementation dependent, but refer to the "Security + Considerations" section of this document for a discussion of each. + + + + + + +Resnick Standards Track [Page 22] + +RFC 2822 Internet Message Format April 2001 + + + When a message is a reply to another message, the mailboxes of the + authors of the original message (the mailboxes in the "From:" field) + or mailboxes specified in the "Reply-To:" field (if it exists) MAY + appear in the "To:" field of the reply since these would normally be + the primary recipients of the reply. If a reply is sent to a message + that has destination fields, it is often desirable to send a copy of + the reply to all of the recipients of the message, in addition to the + author. When such a reply is formed, addresses in the "To:" and + "Cc:" fields of the original message MAY appear in the "Cc:" field of + the reply, since these are normally secondary recipients of the + reply. If a "Bcc:" field is present in the original message, + addresses in that field MAY appear in the "Bcc:" field of the reply, + but SHOULD NOT appear in the "To:" or "Cc:" fields. + + Note: Some mail applications have automatic reply commands that + include the destination addresses of the original message in the + destination addresses of the reply. How those reply commands behave + is implementation dependent and is beyond the scope of this document. + In particular, whether or not to include the original destination + addresses when the original message had a "Reply-To:" field is not + addressed here. + +3.6.4. Identification fields + + Though optional, every message SHOULD have a "Message-ID:" field. + Furthermore, reply messages SHOULD have "In-Reply-To:" and + "References:" fields as appropriate, as described below. + + The "Message-ID:" field contains a single unique message identifier. + The "References:" and "In-Reply-To:" field each contain one or more + unique message identifiers, optionally separated by CFWS. + + The message identifier (msg-id) is similar in syntax to an angle-addr + construct without the internal CFWS. + +message-id = "Message-ID:" msg-id CRLF + +in-reply-to = "In-Reply-To:" 1*msg-id CRLF + +references = "References:" 1*msg-id CRLF + +msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] + +id-left = dot-atom-text / no-fold-quote / obs-id-left + +id-right = dot-atom-text / no-fold-literal / obs-id-right + +no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE + + + +Resnick Standards Track [Page 23] + +RFC 2822 Internet Message Format April 2001 + + +no-fold-literal = "[" *(dtext / quoted-pair) "]" + + The "Message-ID:" field provides a unique message identifier that + refers to a particular version of a particular message. The + uniqueness of the message identifier is guaranteed by the host that + generates it (see below). This message identifier is intended to be + machine readable and not necessarily meaningful to humans. A message + identifier pertains to exactly one instantiation of a particular + message; subsequent revisions to the message each receive new message + identifiers. + + Note: There are many instances when messages are "changed", but those + changes do not constitute a new instantiation of that message, and + therefore the message would not get a new message identifier. For + example, when messages are introduced into the transport system, they + are often prepended with additional header fields such as trace + fields (described in section 3.6.7) and resent fields (described in + section 3.6.6). The addition of such header fields does not change + the identity of the message and therefore the original "Message-ID:" + field is retained. In all cases, it is the meaning that the sender + of the message wishes to convey (i.e., whether this is the same + message or a different message) that determines whether or not the + "Message-ID:" field changes, not any particular syntactic difference + that appears (or does not appear) in the message. + + The "In-Reply-To:" and "References:" fields are used when creating a + reply to a message. They hold the message identifier of the original + message and the message identifiers of other messages (for example, + in the case of a reply to a message which was itself a reply). The + "In-Reply-To:" field may be used to identify the message (or + messages) to which the new message is a reply, while the + "References:" field may be used to identify a "thread" of + conversation. + + When creating a reply to a message, the "In-Reply-To:" and + "References:" fields of the resultant message are constructed as + follows: + + The "In-Reply-To:" field will contain the contents of the "Message- + ID:" field of the message to which this one is a reply (the "parent + message"). If there is more than one parent message, then the "In- + Reply-To:" field will contain the contents of all of the parents' + "Message-ID:" fields. If there is no "Message-ID:" field in any of + the parent messages, then the new message will have no "In-Reply-To:" + field. + + + + + + +Resnick Standards Track [Page 24] + +RFC 2822 Internet Message Format April 2001 + + + The "References:" field will contain the contents of the parent's + "References:" field (if any) followed by the contents of the parent's + "Message-ID:" field (if any). If the parent message does not contain + a "References:" field but does have an "In-Reply-To:" field + containing a single message identifier, then the "References:" field + will contain the contents of the parent's "In-Reply-To:" field + followed by the contents of the parent's "Message-ID:" field (if + any). If the parent has none of the "References:", "In-Reply-To:", + or "Message-ID:" fields, then the new message will have no + "References:" field. + + Note: Some implementations parse the "References:" field to display + the "thread of the discussion". These implementations assume that + each new message is a reply to a single parent and hence that they + can walk backwards through the "References:" field to find the parent + of each message listed there. Therefore, trying to form a + "References:" field for a reply that has multiple parents is + discouraged and how to do so is not defined in this document. + + The message identifier (msg-id) itself MUST be a globally unique + identifier for a message. The generator of the message identifier + MUST guarantee that the msg-id is unique. There are several + algorithms that can be used to accomplish this. Since the msg-id has + a similar syntax to angle-addr (identical except that comments and + folding white space are not allowed), a good method is to put the + domain name (or a domain literal IP address) of the host on which the + message identifier was created on the right hand side of the "@", and + put a combination of the current absolute date and time along with + some other currently unique (perhaps sequential) identifier available + on the system (for example, a process id number) on the left hand + side. Using a date on the left hand side and a domain name or domain + literal on the right hand side makes it possible to guarantee + uniqueness since no two hosts use the same domain name or IP address + at the same time. Though other algorithms will work, it is + RECOMMENDED that the right hand side contain some domain identifier + (either of the host itself or otherwise) such that the generator of + the message identifier can guarantee the uniqueness of the left hand + side within the scope of that domain. + + Semantically, the angle bracket characters are not part of the + msg-id; the msg-id is what is contained between the two angle bracket + characters. + + + + + + + + + +Resnick Standards Track [Page 25] + +RFC 2822 Internet Message Format April 2001 + + +3.6.5. Informational fields + + The informational fields are all optional. The "Keywords:" field + contains a comma-separated list of one or more words or + quoted-strings. The "Subject:" and "Comments:" fields are + unstructured fields as defined in section 2.2.1, and therefore may + contain text or folding white space. + +subject = "Subject:" unstructured CRLF + +comments = "Comments:" unstructured CRLF + +keywords = "Keywords:" phrase *("," phrase) CRLF + + These three fields are intended to have only human-readable content + with information about the message. The "Subject:" field is the most + common and contains a short string identifying the topic of the + message. When used in a reply, the field body MAY start with the + string "Re: " (from the Latin "res", in the matter of) followed by + the contents of the "Subject:" field body of the original message. + If this is done, only one instance of the literal string "Re: " ought + to be used since use of other strings or more than one instance can + lead to undesirable consequences. The "Comments:" field contains any + additional comments on the text of the body of the message. The + "Keywords:" field contains a comma-separated list of important words + and phrases that might be useful for the recipient. + +3.6.6. Resent fields + + Resent fields SHOULD be added to any message that is reintroduced by + a user into the transport system. A separate set of resent fields + SHOULD be added each time this is done. All of the resent fields + corresponding to a particular resending of the message SHOULD be + together. Each new set of resent fields is prepended to the message; + that is, the most recent set of resent fields appear earlier in the + message. No other fields in the message are changed when resent + fields are added. + + Each of the resent fields corresponds to a particular field elsewhere + in the syntax. For instance, the "Resent-Date:" field corresponds to + the "Date:" field and the "Resent-To:" field corresponds to the "To:" + field. In each case, the syntax for the field body is identical to + the syntax given previously for the corresponding field. + + When resent fields are used, the "Resent-From:" and "Resent-Date:" + fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent. + "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be + identical to "Resent-From:". + + + +Resnick Standards Track [Page 26] + +RFC 2822 Internet Message Format April 2001 + + +resent-date = "Resent-Date:" date-time CRLF + +resent-from = "Resent-From:" mailbox-list CRLF + +resent-sender = "Resent-Sender:" mailbox CRLF + +resent-to = "Resent-To:" address-list CRLF + +resent-cc = "Resent-Cc:" address-list CRLF + +resent-bcc = "Resent-Bcc:" (address-list / [CFWS]) CRLF + +resent-msg-id = "Resent-Message-ID:" msg-id CRLF + + Resent fields are used to identify a message as having been + reintroduced into the transport system by a user. The purpose of + using resent fields is to have the message appear to the final + recipient as if it were sent directly by the original sender, with + all of the original fields remaining the same. Each set of resent + fields correspond to a particular resending event. That is, if a + message is resent multiple times, each set of resent fields gives + identifying information for each individual time. Resent fields are + strictly informational. They MUST NOT be used in the normal + processing of replies or other such automatic actions on messages. + + Note: Reintroducing a message into the transport system and using + resent fields is a different operation from "forwarding". + "Forwarding" has two meanings: One sense of forwarding is that a mail + reading program can be told by a user to forward a copy of a message + to another person, making the forwarded message the body of the new + message. A forwarded message in this sense does not appear to have + come from the original sender, but is an entirely new message from + the forwarder of the message. On the other hand, forwarding is also + used to mean when a mail transport program gets a message and + forwards it on to a different destination for final delivery. Resent + header fields are not intended for use with either type of + forwarding. + + The resent originator fields indicate the mailbox of the person(s) or + system(s) that resent the message. As with the regular originator + fields, there are two forms: a simple "Resent-From:" form which + contains the mailbox of the individual doing the resending, and the + more complex form, when one individual (identified in the + "Resent-Sender:" field) resends a message on behalf of one or more + others (identified in the "Resent-From:" field). + + Note: When replying to a resent message, replies behave just as they + would with any other message, using the original "From:", + + + +Resnick Standards Track [Page 27] + +RFC 2822 Internet Message Format April 2001 + + + "Reply-To:", "Message-ID:", and other fields. The resent fields are + only informational and MUST NOT be used in the normal processing of + replies. + + The "Resent-Date:" indicates the date and time at which the resent + message is dispatched by the resender of the message. Like the + "Date:" field, it is not the date and time that the message was + actually transported. + + The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function + identically to the "To:", "Cc:", and "Bcc:" fields respectively, + except that they indicate the recipients of the resent message, not + the recipients of the original message. + + The "Resent-Message-ID:" field provides a unique identifier for the + resent message. + +3.6.7. Trace fields + + The trace fields are a group of header fields consisting of an + optional "Return-Path:" field, and one or more "Received:" fields. + The "Return-Path:" header field contains a pair of angle brackets + that enclose an optional addr-spec. The "Received:" field contains a + (possibly empty) list of name/value pairs followed by a semicolon and + a date-time specification. The first item of the name/value pair is + defined by item-name, and the second item is either an addr-spec, an + atom, a domain, or a msg-id. Further restrictions may be applied to + the syntax of the trace fields by standards that provide for their + use, such as [RFC2821]. + +trace = [return] + 1*received + +return = "Return-Path:" path CRLF + +path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) / + obs-path + +received = "Received:" name-val-list ";" date-time CRLF + +name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)] + +name-val-pair = item-name CFWS item-value + +item-name = ALPHA *(["-"] (ALPHA / DIGIT)) + +item-value = 1*angle-addr / addr-spec / + atom / domain / msg-id + + + +Resnick Standards Track [Page 28] + +RFC 2822 Internet Message Format April 2001 + + + A full discussion of the Internet mail use of trace fields is + contained in [RFC2821]. For the purposes of this standard, the trace + fields are strictly informational, and any formal interpretation of + them is outside of the scope of this document. + +3.6.8. Optional fields + + Fields may appear in messages that are otherwise unspecified in this + standard. They MUST conform to the syntax of an optional-field. + This is a field name, made up of the printable US-ASCII characters + except SP and colon, followed by a colon, followed by any text which + conforms to unstructured. + + The field names of any optional-field MUST NOT be identical to any + field name specified elsewhere in this standard. + +optional-field = field-name ":" unstructured CRLF + +field-name = 1*ftext + +ftext = %d33-57 / ; Any character except + %d59-126 ; controls, SP, and + ; ":". + + For the purposes of this standard, any optional field is + uninterpreted. + +4. Obsolete Syntax + + Earlier versions of this standard allowed for different (usually more + liberal) syntax than is allowed in this version. Also, there have + been syntactic elements used in messages on the Internet whose + interpretation have never been documented. Though some of these + syntactic forms MUST NOT be generated according to the grammar in + section 3, they MUST be accepted and parsed by a conformant receiver. + This section documents many of these syntactic elements. Taking the + grammar in section 3 and adding the definitions presented in this + section will result in the grammar to use for interpretation of + messages. + + Note: This section identifies syntactic forms that any implementation + MUST reasonably interpret. However, there are certainly Internet + messages which do not conform to even the additional syntax given in + this section. The fact that a particular form does not appear in any + section of this document is not justification for computer programs + to crash or for malformed data to be irretrievably lost by any + implementation. To repeat an example, though this document requires + lines in messages to be no longer than 998 characters, silently + + + +Resnick Standards Track [Page 29] + +RFC 2822 Internet Message Format April 2001 + + + discarding the 999th and subsequent characters in a line without + warning would still be bad behavior for an implementation. It is up + to the implementation to deal with messages robustly. + + One important difference between the obsolete (interpreting) and the + current (generating) syntax is that in structured header field bodies + (i.e., between the colon and the CRLF of any structured header + field), white space characters, including folding white space, and + comments can be freely inserted between any syntactic tokens. This + allows many complex forms that have proven difficult for some + implementations to parse. + + Another key difference between the obsolete and the current syntax is + that the rule in section 3.2.3 regarding lines composed entirely of + white space in comments and folding white space does not apply. See + the discussion of folding white space in section 4.2 below. + + Finally, certain characters that were formerly allowed in messages + appear in this section. The NUL character (ASCII value 0) was once + allowed, but is no longer for compatibility reasons. CR and LF were + allowed to appear in messages other than as CRLF; this use is also + shown here. + + Other differences in syntax and semantics are noted in the following + sections. + +4.1. Miscellaneous obsolete tokens + + These syntactic elements are used elsewhere in the obsolete syntax or + in the main syntax. The obs-char and obs-qp elements each add ASCII + value 0. Bare CR and bare LF are added to obs-text and obs-utext. + The period character is added to obs-phrase. The obs-phrase-list + provides for "empty" elements in a comma-separated list of phrases. + + Note: The "period" (or "full stop") character (".") in obs-phrase is + not a form that was allowed in earlier versions of this or any other + standard. Period (nor any other character from specials) was not + allowed in phrase because it introduced a parsing difficulty + distinguishing between phrases and portions of an addr-spec (see + section 4.4). It appears here because the period character is + currently used in many messages in the display-name portion of + addresses, especially for initials in names, and therefore must be + interpreted properly. In the future, period may appear in the + regular syntax of phrase. + +obs-qp = "\" (%d0-127) + +obs-text = *LF *CR *(obs-char *LF *CR) + + + +Resnick Standards Track [Page 30] + +RFC 2822 Internet Message Format April 2001 + + +obs-char = %d0-9 / %d11 / ; %d0-127 except CR and + %d12 / %d14-127 ; LF + +obs-utext = obs-text + +obs-phrase = word *(word / "." / CFWS) + +obs-phrase-list = phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase] + + Bare CR and bare LF appear in messages with two different meanings. + In many cases, bare CR or bare LF are used improperly instead of CRLF + to indicate line separators. In other cases, bare CR and bare LF are + used simply as ASCII control characters with their traditional ASCII + meanings. + +4.2. Obsolete folding white space + + In the obsolete syntax, any amount of folding white space MAY be + inserted where the obs-FWS rule is allowed. This creates the + possibility of having two consecutive "folds" in a line, and + therefore the possibility that a line which makes up a folded header + field could be composed entirely of white space. + + obs-FWS = 1*WSP *(CRLF 1*WSP) + +4.3. Obsolete Date and Time + + The syntax for the obsolete date format allows a 2 digit year in the + date field and allows for a list of alphabetic time zone + specifications that were used in earlier versions of this standard. + It also permits comments and folding white space between many of the + tokens. + +obs-day-of-week = [CFWS] day-name [CFWS] + +obs-year = [CFWS] 2*DIGIT [CFWS] + +obs-month = CFWS month-name CFWS + +obs-day = [CFWS] 1*2DIGIT [CFWS] + +obs-hour = [CFWS] 2DIGIT [CFWS] + +obs-minute = [CFWS] 2DIGIT [CFWS] + +obs-second = [CFWS] 2DIGIT [CFWS] + +obs-zone = "UT" / "GMT" / ; Universal Time + + + +Resnick Standards Track [Page 31] + +RFC 2822 Internet Message Format April 2001 + + + ; North American UT + ; offsets + "EST" / "EDT" / ; Eastern: - 5/ - 4 + "CST" / "CDT" / ; Central: - 6/ - 5 + "MST" / "MDT" / ; Mountain: - 7/ - 6 + "PST" / "PDT" / ; Pacific: - 8/ - 7 + + %d65-73 / ; Military zones - "A" + %d75-90 / ; through "I" and "K" + %d97-105 / ; through "Z", both + %d107-122 ; upper and lower case + + Where a two or three digit year occurs in a date, the year is to be + interpreted as follows: If a two digit year is encountered whose + value is between 00 and 49, the year is interpreted by adding 2000, + ending up with a value between 2000 and 2049. If a two digit year is + encountered with a value between 50 and 99, or any three digit year + is encountered, the year is interpreted by adding 1900. + + In the obsolete time zone, "UT" and "GMT" are indications of + "Universal Time" and "Greenwich Mean Time" respectively and are both + semantically identical to "+0000". + + The remaining three character zones are the US time zones. The first + letter, "E", "C", "M", or "P" stands for "Eastern", "Central", + "Mountain" and "Pacific". The second letter is either "S" for + "Standard" time, or "D" for "Daylight" (or summer) time. Their + interpretations are as follows: + + EDT is semantically equivalent to -0400 + EST is semantically equivalent to -0500 + CDT is semantically equivalent to -0500 + CST is semantically equivalent to -0600 + MDT is semantically equivalent to -0600 + MST is semantically equivalent to -0700 + PDT is semantically equivalent to -0700 + PST is semantically equivalent to -0800 + + The 1 character military time zones were defined in a non-standard + way in [RFC822] and are therefore unpredictable in their meaning. + The original definitions of the military zones "A" through "I" are + equivalent to "+0100" through "+0900" respectively; "K", "L", and "M" + are equivalent to "+1000", "+1100", and "+1200" respectively; "N" + through "Y" are equivalent to "-0100" through "-1200" respectively; + and "Z" is equivalent to "+0000". However, because of the error in + [RFC822], they SHOULD all be considered equivalent to "-0000" unless + there is out-of-band information confirming their meaning. + + + + +Resnick Standards Track [Page 32] + +RFC 2822 Internet Message Format April 2001 + + + Other multi-character (usually between 3 and 5) alphabetic time zones + have been used in Internet messages. Any such time zone whose + meaning is not known SHOULD be considered equivalent to "-0000" + unless there is out-of-band information confirming their meaning. + +4.4. Obsolete Addressing + + There are three primary differences in addressing. First, mailbox + addresses were allowed to have a route portion before the addr-spec + when enclosed in "<" and ">". The route is simply a comma-separated + list of domain names, each preceded by "@", and the list terminated + by a colon. Second, CFWS were allowed between the period-separated + elements of local-part and domain (i.e., dot-atom was not used). In + addition, local-part is allowed to contain quoted-string in addition + to just atom. Finally, mailbox-list and address-list were allowed to + have "null" members. That is, there could be two or more commas in + such a list with nothing in between them. + +obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS] + +obs-route = [CFWS] obs-domain-list ":" [CFWS] + +obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain) + +obs-local-part = word *("." word) + +obs-domain = atom *("." atom) + +obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox] + +obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address] + + When interpreting addresses, the route portion SHOULD be ignored. + +4.5. Obsolete header fields + + Syntactically, the primary difference in the obsolete field syntax is + that it allows multiple occurrences of any of the fields and they may + occur in any order. Also, any amount of white space is allowed + before the ":" at the end of the field name. + +obs-fields = *(obs-return / + obs-received / + obs-orig-date / + obs-from / + obs-sender / + obs-reply-to / + obs-to / + + + +Resnick Standards Track [Page 33] + +RFC 2822 Internet Message Format April 2001 + + + obs-cc / + obs-bcc / + obs-message-id / + obs-in-reply-to / + obs-references / + obs-subject / + obs-comments / + obs-keywords / + obs-resent-date / + obs-resent-from / + obs-resent-send / + obs-resent-rply / + obs-resent-to / + obs-resent-cc / + obs-resent-bcc / + obs-resent-mid / + obs-optional) + + Except for destination address fields (described in section 4.5.3), + the interpretation of multiple occurrences of fields is unspecified. + Also, the interpretation of trace fields and resent fields which do + not occur in blocks prepended to the message is unspecified as well. + Unless otherwise noted in the following sections, interpretation of + other fields is identical to the interpretation of their non-obsolete + counterparts in section 3. + +4.5.1. Obsolete origination date field + +obs-orig-date = "Date" *WSP ":" date-time CRLF + +4.5.2. Obsolete originator fields + +obs-from = "From" *WSP ":" mailbox-list CRLF + +obs-sender = "Sender" *WSP ":" mailbox CRLF + +obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF + +4.5.3. Obsolete destination address fields + +obs-to = "To" *WSP ":" address-list CRLF + +obs-cc = "Cc" *WSP ":" address-list CRLF + +obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF + + + + + + +Resnick Standards Track [Page 34] + +RFC 2822 Internet Message Format April 2001 + + + When multiple occurrences of destination address fields occur in a + message, they SHOULD be treated as if the address-list in the first + occurrence of the field is combined with the address lists of the + subsequent occurrences by adding a comma and concatenating. + +4.5.4. Obsolete identification fields + + The obsolete "In-Reply-To:" and "References:" fields differ from the + current syntax in that they allow phrase (words or quoted strings) to + appear. The obsolete forms of the left and right sides of msg-id + allow interspersed CFWS, making them syntactically identical to + local-part and domain respectively. + +obs-message-id = "Message-ID" *WSP ":" msg-id CRLF + +obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF + +obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF + +obs-id-left = local-part + +obs-id-right = domain + + For purposes of interpretation, the phrases in the "In-Reply-To:" and + "References:" fields are ignored. + + Semantically, none of the optional CFWS surrounding the local-part + and the domain are part of the obs-id-left and obs-id-right + respectively. + +4.5.5. Obsolete informational fields + +obs-subject = "Subject" *WSP ":" unstructured CRLF + +obs-comments = "Comments" *WSP ":" unstructured CRLF + +obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF + +4.5.6. Obsolete resent fields + + The obsolete syntax adds a "Resent-Reply-To:" field, which consists + of the field name, the optional comments and folding white space, the + colon, and a comma separated list of addresses. + +obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF + +obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF + + + + +Resnick Standards Track [Page 35] + +RFC 2822 Internet Message Format April 2001 + + +obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF + +obs-resent-to = "Resent-To" *WSP ":" address-list CRLF + +obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF + +obs-resent-bcc = "Resent-Bcc" *WSP ":" + (address-list / [CFWS]) CRLF + +obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF + +obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF + + As with other resent fields, the "Resent-Reply-To:" field is to be + treated as trace information only. + +4.5.7. Obsolete trace fields + + The obs-return and obs-received are again given here as template + definitions, just as return and received are in section 3. Their + full syntax is given in [RFC2821]. + +obs-return = "Return-Path" *WSP ":" path CRLF + +obs-received = "Received" *WSP ":" name-val-list CRLF + +obs-path = obs-angle-addr + +4.5.8. Obsolete optional fields + +obs-optional = field-name *WSP ":" unstructured CRLF + +5. Security Considerations + + Care needs to be taken when displaying messages on a terminal or + terminal emulator. Powerful terminals may act on escape sequences + and other combinations of ASCII control characters with a variety of + consequences. They can remap the keyboard or permit other + modifications to the terminal which could lead to denial of service + or even damaged data. They can trigger (sometimes programmable) + answerback messages which can allow a message to cause commands to be + issued on the recipient's behalf. They can also effect the operation + of terminal attached devices such as printers. Message viewers may + wish to strip potentially dangerous terminal escape sequences from + the message prior to display. However, other escape sequences appear + in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047, + RFC2048, RFC2049, ISO2022]) and therefore should not be stripped + indiscriminately. + + + +Resnick Standards Track [Page 36] + +RFC 2822 Internet Message Format April 2001 + + + Transmission of non-text objects in messages raises additional + security issues. These issues are discussed in [RFC2045, RFC2046, + RFC2047, RFC2048, RFC2049]. + + Many implementations use the "Bcc:" (blind carbon copy) field + described in section 3.6.3 to facilitate sending messages to + recipients without revealing the addresses of one or more of the + addressees to the other recipients. Mishandling this use of "Bcc:" + has implications for confidential information that might be revealed, + which could eventually lead to security problems through knowledge of + even the existence of a particular mail address. For example, if + using the first method described in section 3.6.3, where the "Bcc:" + line is removed from the message, blind recipients have no explicit + indication that they have been sent a blind copy, except insofar as + their address does not appear in the message header. Because of + this, one of the blind addressees could potentially send a reply to + all of the shown recipients and accidentally reveal that the message + went to the blind recipient. When the second method from section + 3.6.3 is used, the blind recipient's address appears in the "Bcc:" + field of a separate copy of the message. If the "Bcc:" field sent + contains all of the blind addressees, all of the "Bcc:" recipients + will be seen by each "Bcc:" recipient. Even if a separate message is + sent to each "Bcc:" recipient with only the individual's address, + implementations still need to be careful to process replies to the + message as per section 3.6.3 so as not to accidentally reveal the + blind recipient to other recipients. + +6. Bibliography + + [ASCII] American National Standards Institute (ANSI), Coded + Character Set - 7-Bit American National Standard Code for + Information Interchange, ANSI X3.4, 1986. + + [ISO2022] International Organization for Standardization (ISO), + Information processing - ISO 7-bit and 8-bit coded + character sets - Code extension techniques, Third edition + - 1986-05-01, ISO 2022, 1986. + + [RFC822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", RFC 822, August 1982. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + + +Resnick Standards Track [Page 37] + +RFC 2822 Internet Message Format April 2001 + + + [RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) + Part Three: Message Header Extensions for Non-ASCII Text", + RFC 2047, November 1996. + + [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: Format of + Internet Message Bodies", RFC 2048, November 1996. + + [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and + Examples", RFC 2049, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 2234, November 1997. + + [RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC + 2821, March 2001. + + [STD3] Braden, R., "Host Requirements", STD 3, RFC 1122 and RFC + 1123, October 1989. + + [STD12] Mills, D., "Network Time Protocol", STD 12, RFC 1119, + September 1989. + + [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 + and RFC 1035, November 1987. + + [STD14] Partridge, C., "Mail Routing and the Domain System", STD + 14, RFC 974, January 1986. + +7. Editor's Address + + Peter W. Resnick + QUALCOMM Incorporated + 5775 Morehouse Drive + San Diego, CA 92121-1714 + USA + + Phone: +1 858 651 4478 + Fax: +1 858 651 1102 + EMail: presnick@qualcomm.com + + + + + + + +Resnick Standards Track [Page 38] + +RFC 2822 Internet Message Format April 2001 + + +8. Acknowledgements + + Many people contributed to this document. They included folks who + participated in the Detailed Revision and Update of Messaging + Standards (DRUMS) Working Group of the Internet Engineering Task + Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and + people who simply sent their comments in via e-mail. The editor is + deeply indebted to them all and thanks them sincerely. The below + list includes everyone who sent e-mail concerning this document. + Hopefully, everyone who contributed is named here: + + Matti Aarnio Barry Finkel Larry Masinter + Tanaka Akira Erik Forsberg Denis McKeon + Russ Allbery Chuck Foster William P McQuillan + Eric Allman Paul Fox Alexey Melnikov + Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger + Ran Atkinson Ned Freed Steven Miller + Jos Backus Jochen Friedrich Keith Moore + Bruce Balden Randall C. Gellens John Gardiner Myers + Dave Barr Sukvinder Singh Gill Chris Newman + Alan Barrett Tim Goodwin John W. Noerenberg + John Beck Philip Guenther Eric Norman + J. Robert von Behren Tony Hansen Mike O'Dell + Jos den Bekker John Hawkinson Larry Osterman + D. J. Bernstein Philip Hazel Paul Overell + James Berriman Kai Henningsen Jacob Palme + Norbert Bollow Robert Herriot Michael A. Patton + Raj Bose Paul Hethmon Uzi Paz + Antony Bowesman Jim Hill Michael A. Quinlan + Scott Bradner Paul E. Hoffman Eric S. Raymond + Randy Bush Steve Hole Sam Roberts + Tom Byrer Kari Hurtta Hugh Sasse + Bruce Campbell Marco S. Hyman Bart Schaefer + Larry Campbell Ofer Inbar Tom Scola + W. J. Carpenter Olle Jarnefors Wolfgang Segmuller + Michael Chapman Kevin Johnson Nick Shelness + Richard Clayton Sudish Joseph John Stanley + Maurizio Codogno Maynard Kang Einar Stefferud + Jim Conklin Prabhat Keni Jeff Stephenson + R. Kelley Cook John C. Klensin Bernard Stern + Steve Coya Graham Klyne Peter Sylvester + Mark Crispin Brad Knowles Mark Symons + Dave Crocker Shuhei Kobayashi Eric Thomas + Matt Curtin Peter Koch Lee Thompson + Michael D'Errico Dan Kohn Karel De Vriendt + Cyrus Daboo Christian Kuhtz Matthew Wall + Jutta Degener Anand Kumria Rolf Weber + Mark Delany Steen Larsen Brent B. Welch + + + +Resnick Standards Track [Page 39] + +RFC 2822 Internet Message Format April 2001 + + + Steve Dorner Eliot Lear Dan Wing + Harold A. Driscoll Barry Leiba Jack De Winter + Michael Elkins Jay Levitt Gregory J. Woodhouse + Robert Elz Lars-Johan Liman Greg A. Woods + Johnny Eriksson Charles Lindsey Kazu Yamamoto + Erik E. Fair Pete Loshin Alain Zahm + Roger Fajman Simon Lyall Jamie Zawinski + Patrik Faltstrom Bill Manning Timothy S. Zurcher + Claus Andre Farber John Martin + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 40] + +RFC 2822 Internet Message Format April 2001 + + +Appendix A. Example messages + + This section presents a selection of messages. These are intended to + assist in the implementation of this standard, but should not be + taken as normative; that is to say, although the examples in this + section were carefully reviewed, if there happens to be a conflict + between these examples and the syntax described in sections 3 and 4 + of this document, the syntax in those sections is to be taken as + correct. + + Messages are delimited in this section between lines of "----". The + "----" lines are not part of the message itself. + +A.1. Addressing examples + + The following are examples of messages that might be sent between two + individuals. + +A.1.1. A message from one person to another with simple addressing + + This could be called a canonical message. It has a single author, + John Doe, a single recipient, Mary Smith, a subject, the date, a + message identifier, and a textual message in the body. + +---- +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 41] + +RFC 2822 Internet Message Format April 2001 + + + If John's secretary Michael actually sent the message, though John + was the author and replies to this message should go back to him, the + sender field would be used: + +---- +From: John Doe +Sender: Michael Jones +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + +A.1.2. Different types of mailboxes + + This message includes multiple addresses in the destination fields + and also uses several different forms of addresses. + +---- +From: "Joe Q. Public" +To: Mary Smith , jdoe@example.org, Who? +Cc: , "Giant; \"Big\" Box" +Date: Tue, 1 Jul 2003 10:52:37 +0200 +Message-ID: <5678.21-Nov-1997@example.com> + +Hi everyone. +---- + + Note that the display names for Joe Q. Public and Giant; "Big" Box + needed to be enclosed in double-quotes because the former contains + the period and the latter contains both semicolon and double-quote + characters (the double-quote characters appearing as quoted-pair + construct). Conversely, the display name for Who? could appear + without them because the question mark is legal in an atom. Notice + also that jdoe@example.org and boss@nil.test have no display names + associated with them at all, and jdoe@example.org uses the simpler + address form without the angle brackets. + + + + + + + + + + + +Resnick Standards Track [Page 42] + +RFC 2822 Internet Message Format April 2001 + + +A.1.3. Group addresses + +---- +From: Pete +To: A Group:Chris Jones ,joe@where.test,John ; +Cc: Undisclosed recipients:; +Date: Thu, 13 Feb 1969 23:32:54 -0330 +Message-ID: + +Testing. +---- + + In this message, the "To:" field has a single group recipient named A + Group which contains 3 addresses, and a "Cc:" field with an empty + group recipient named Undisclosed recipients. + +A.2. Reply messages + + The following is a series of three messages that make up a + conversation thread between John and Mary. John firsts sends a + message to Mary, Mary then replies to John's message, and then John + replies to Mary's reply message. + + Note especially the "Message-ID:", "References:", and "In-Reply-To:" + fields in each message. + +---- +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + + + + + + + + -date-time = [ day-of-week "," ] date FWS time [CFWS] -day-of-week = ([FWS] day-name) / obs-day-of-week -day-name = "Mon" / "Tue" / "Wed" / "Thu" / - "Fri" / "Sat" / "Sun" -date = day month year -year = 4*DIGIT / obs-year -month = (FWS month-name FWS) / obs-month -month-name = "Jan" / "Feb" / "Mar" / "Apr" / - "May" / "Jun" / "Jul" / "Aug" / - "Sep" / "Oct" / "Nov" / "Dec" +Resnick Standards Track [Page 43] -day = ([FWS] 1*2DIGIT) / obs-day +RFC 2822 Internet Message Format April 2001 -time = time-of-day FWS zone -time-of-day = hour ":" minute [ ":" second ] + When sending replies, the Subject field is often retained, though + prepended with "Re: " as described in section 3.6.5. -hour = 2DIGIT / obs-hour +---- +From: Mary Smith +To: John Doe +Reply-To: "Mary Smith: Personal Account" +Subject: Re: Saying Hello +Date: Fri, 21 Nov 1997 10:01:10 -0600 +Message-ID: <3456@example.net> +In-Reply-To: <1234@local.machine.example> +References: <1234@local.machine.example> -minute = 2DIGIT / obs-minute +This is a reply to your hello. +---- -second = 2DIGIT / obs-second + Note the "Reply-To:" field in the above message. When John replies + to Mary's message above, the reply should go to the address in the + "Reply-To:" field instead of the address in the "From:" field. -zone = (( "+" / "-" ) 4DIGIT) / obs-zone +---- +To: "Mary Smith: Personal Account" +From: John Doe +Subject: Re: Saying Hello +Date: Fri, 21 Nov 1997 11:00:00 -0600 +Message-ID: +In-Reply-To: <3456@example.net> +References: <1234@local.machine.example> <3456@example.net> - The day is the numeric day of the month. The year is any numeric - year 1900 or later. +This is a reply to your reply. +---- - The time-of-day specifies the number of hours, minutes, and - optionally seconds since midnight of the date indicated. +A.3. Resent messages - The date and time-of-day SHOULD express local time. + Start with the message that has been used as an example several + times: - The zone specifies the offset from Coordinated Universal Time (UTC, - formerly referred to as "Greenwich Mean Time") that the date and - time-of-day represent. The "+" or "-" indicates whether the - time-of-day is ahead of (i.e., east of) or behind (i.e., west of) - Universal Time. The first two digits indicate the number of hours - difference from Universal Time, and the last two digits indicate the - number of minutes difference from Universal Time. (Hence, +hhmm - means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) - minutes). The form "+0000" SHOULD be used to indicate a time zone at - Universal Time. Though "-0000" also indicates Universal Time, it is - used to indicate that the time was generated on a system that may be - in a local time zone other than Universal Time and therefore - indicates that the date-time contains no information about the local - time zone. +---- +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> - A date-time specification MUST be semantically valid. That is, the - day-of-the-week (if included) MUST be the day implied by the date, - the numeric day-of-month MUST be between 1 and the number of days - allowed for the specified month (in the specified year), the - time-of-day MUST be in the range 00:00:00 through 23:59:60 (the - number of seconds allowing for a leap second; see [STD12]), and the - zone MUST be within the range -9959 through +9959. +This is a message just to say hello. +So, "Hello". +---- -[...] -4.3. Obsolete Date and Time - The syntax for the obsolete date format allows a 2 digit year in the - date field and allows for a list of alphabetic time zone - specifications that were used in earlier versions of this standard. - It also permits comments and folding white space between many of the - tokens. -obs-day-of-week = [CFWS] day-name [CFWS] +Resnick Standards Track [Page 44] -obs-year = [CFWS] 2*DIGIT [CFWS] +RFC 2822 Internet Message Format April 2001 -obs-month = CFWS month-name CFWS -obs-day = [CFWS] 1*2DIGIT [CFWS] + Say that Mary, upon receiving this message, wishes to send a copy of + the message to Jane such that (a) the message would appear to have + come straight from John; (b) if Jane replies to the message, the + reply should go back to John; and (c) all of the original + information, like the date the message was originally sent to Mary, + the message identifier, and the original addressee, is preserved. In + this case, resent fields are prepended to the message: -obs-hour = [CFWS] 2DIGIT [CFWS] +---- +Resent-From: Mary Smith +Resent-To: Jane Brown +Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 +Resent-Message-ID: <78910@example.net> +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> -obs-minute = [CFWS] 2DIGIT [CFWS] +This is a message just to say hello. +So, "Hello". +---- -obs-second = [CFWS] 2DIGIT [CFWS] + If Jane, in turn, wished to resend this message to another person, + she would prepend her own set of resent header fields to the above + and send that. -obs-zone = "UT" / "GMT" / ; Universal Time - ; North American UT - ; offsets - "EST" / "EDT" / ; Eastern: - 5/ - 4 - "CST" / "CDT" / ; Central: - 6/ - 5 - "MST" / "MDT" / ; Mountain: - 7/ - 6 - "PST" / "PDT" / ; Pacific: - 8/ - 7 - %d65-73 / ; Military zones - "A" - %d75-90 / ; through "I" and "K" - %d97-105 / ; through "Z", both - %d107-122 ; upper and lower case - Where a two or three digit year occurs in a date, the year is to be - interpreted as follows: If a two digit year is encountered whose - value is between 00 and 49, the year is interpreted by adding 2000, - ending up with a value between 2000 and 2049. If a two digit year is - encountered with a value between 50 and 99, or any three digit year - is encountered, the year is interpreted by adding 1900. - In the obsolete time zone, "UT" and "GMT" are indications of - "Universal Time" and "Greenwich Mean Time" respectively and are both - semantically identical to "+0000". - The remaining three character zones are the US time zones. The first - letter, "E", "C", "M", or "P" stands for "Eastern", "Central", - "Mountain" and "Pacific". The second letter is either "S" for - "Standard" time, or "D" for "Daylight" (or summer) time. Their - interpretations are as follows: - EDT is semantically equivalent to -0400 - EST is semantically equivalent to -0500 - CDT is semantically equivalent to -0500 - CST is semantically equivalent to -0600 - MDT is semantically equivalent to -0600 - MST is semantically equivalent to -0700 - PDT is semantically equivalent to -0700 - PST is semantically equivalent to -0800 - The 1 character military time zones were defined in a non-standard - way in [RFC822] and are therefore unpredictable in their meaning. - The original definitions of the military zones "A" through "I" are - equivalent to "+0100" through "+0900" respectively; "K", "L", and "M" - are equivalent to "+1000", "+1100", and "+1200" respectively; "N" - through "Y" are equivalent to "-0100" through "-1200" respectively; - and "Z" is equivalent to "+0000". However, because of the error in - [RFC822], they SHOULD all be considered equivalent to "-0000" unless - there is out-of-band information confirming their meaning. - Other multi-character (usually between 3 and 5) alphabetic time zones - have been used in Internet messages. Any such time zone whose - meaning is not known SHOULD be considered equivalent to "-0000" - unless there is out-of-band information confirming their meaning. -[...] + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 45] + +RFC 2822 Internet Message Format April 2001 + + +A.4. Messages with trace fields + + As messages are sent through the transport system as described in + [RFC2821], trace fields are prepended to the message. The following + is an example of what those trace fields might look like. Note that + there is some folding white space in the first one since these lines + can be long. + +---- +Received: from x.y.test + by example.net + via TCP + with ESMTP + id ABC12345 + for ; 21 Nov 1997 10:05:43 -0600 +Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600 +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + + + + + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 46] + +RFC 2822 Internet Message Format April 2001 + + +A.5. White space, comments, and other oddities + + White space, including folding white space, and comments can be + inserted between many of the tokens of fields. Taking the example + from A.1.3, white space and comments can be inserted into all of the + fields. + +---- +From: Pete(A wonderful \) chap) +To:A Group(Some people) + :Chris Jones , + joe@example.org, + John (my dear friend); (the end of the group) +Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ; +Date: Thu, + 13 + Feb + 1969 + 23:32 + -0330 (Newfoundland Time) +Message-ID: + +Testing. +---- + + The above example is aesthetically displeasing, but perfectly legal. + Note particularly (1) the comments in the "From:" field (including + one that has a ")" character appearing as part of a quoted-pair); (2) + the white space absent after the ":" in the "To:" field as well as + the comment and folding white space after the group name, the special + character (".") in the comment in Chris Jones's address, and the + folding white space before and after "joe@example.org,"; (3) the + multiple and nested comments in the "Cc:" field as well as the + comment immediately following the ":" after "Cc"; (4) the folding + white space (but no comments except at the end) and the missing + seconds in the time of the date field; and (5) the white space before + (but not within) the identifier in the "Message-ID:" field. + +A.6. Obsoleted forms + + The following are examples of obsolete (that is, the "MUST NOT + generate") syntactic elements described in section 4 of this + document. + + + + + + + + +Resnick Standards Track [Page 47] + +RFC 2822 Internet Message Format April 2001 + + +A.6.1. Obsolete addressing + + Note in the below example the lack of quotes around Joe Q. Public, + the route that appears in the address for Mary Smith, the two commas + that appear in the "To:" field, and the spaces that appear around the + "." in the jdoe address. + +---- +From: Joe Q. Public +To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test . example +Date: Tue, 1 Jul 2003 10:52:37 +0200 +Message-ID: <5678.21-Nov-1997@example.com> + +Hi everyone. +---- + +A.6.2. Obsolete dates + + The following message uses an obsolete date format, including a non- + numeric time zone and a two digit year. Note that although the + day-of-week is missing, that is not specific to the obsolete syntax; + it is optional in the current syntax as well. + +---- +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: 21 Nov 97 09:55:06 GMT +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + +A.6.3. Obsolete white space and comments + + White space and comments can appear between many more elements than + in the current syntax. Also, folding lines that are made up entirely + of white space are legal. + + + + + + + + + + + + +Resnick Standards Track [Page 48] + +RFC 2822 Internet Message Format April 2001 + + +---- +From : John Doe +To : Mary Smith +__ + +Subject : Saying Hello +Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600 +Message-ID : <1234 @ local(blah) .machine .example> + +This is a message just to say hello. +So, "Hello". +---- + + Note especially the second line of the "To:" field. It starts with + two space characters. (Note that "__" represent blank spaces.) + Therefore, it is considered part of the folding as described in + section 4.2. Also, the comments and white space throughout + addresses, dates, and message identifiers are all part of the + obsolete syntax. Appendix B. Differences from earlier standards @@ -183,6 +2740,14 @@ 18. Routes in addresses not allowed.* 19. CFWS within local-parts and domains not allowed.* 20. Empty members of address lists not allowed.* + + + +Resnick Standards Track [Page 49] + +RFC 2822 Internet Message Format April 2001 + + 21. Folding white space between field name and colon not allowed.* 22. Comments between field name and colon not allowed. 23. Tightened syntax of in-reply-to and references.* @@ -195,7 +2760,49 @@ 30. Line length limits specified. 31. Bcc more clearly specified. -[...] +Appendix C. Notices + + Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 50] + +RFC 2822 Internet Message Format April 2001 + Full Copyright Statement @@ -225,4 +2832,28 @@ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. -[...] +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 51] + DateTime-Format-Mail-0.2901/notes/rfc2822.txt /home/jas/rfc/rfc2822.txt differ: byte 2, line 2 pkg libdigest-hmac-perl ver 1.01-4 lastfile libdigest-hmac-perl_1.01.orig.tar.gz files libdigest-hmac-perl-1.01.orig/rfc2104.txt tar xfz /data/debian/pool/main/libd/libdigest-hmac-perl/libdigest-hmac-perl_1.01.orig.tar.gz libdigest-hmac-perl-1.01.orig/rfc2104.txt d108e0788d01554ad3d1cd49558b2d20 - libdigest-hmac-perl-1.01.orig/rfc2104.txt d108e0788d01554ad3d1cd49558b2d20 - /home/jas/rfc/rfc2104.txt MATCH rfc2104.txt pkg libdigest-md2-perl ver 2.03-2 lastfile libdigest-md2-perl_2.03.orig.tar.gz files Digest-MD2-2.03/rfc1319.txt tar xfz /data/debian/pool/main/libd/libdigest-md2-perl/libdigest-md2-perl_2.03.orig.tar.gz Digest-MD2-2.03/rfc1319.txt 58a8b17755caf312d74c30ae125a926a - Digest-MD2-2.03/rfc1319.txt f279ca7914e9d43537c6dab12b90663d - /home/jas/rfc/rfc1319.txt MISMATCH rfc1319.txt cmp: EOF on /home/jas/rfc/rfc1319.txt pkg libdigest-md4-perl ver 1.5-1 lastfile libdigest-md4-perl_1.5.orig.tar.gz files Digest-MD4-1.5/rfc1320.txt tar xfz /data/debian/pool/main/libd/libdigest-md4-perl/libdigest-md4-perl_1.5.orig.tar.gz Digest-MD4-1.5/rfc1320.txt dc9e5947d25da0c2acae02b7f7a125d5 - Digest-MD4-1.5/rfc1320.txt dc9e5947d25da0c2acae02b7f7a125d5 - /home/jas/rfc/rfc1320.txt MATCH rfc1320.txt pkg libemail-find-perl ver 0.09-4 lastfile libemail-find-perl_0.09.orig.tar.gz files Email-Find-0.09/t/rfc822.txt tar xfz /data/debian/pool/main/libe/libemail-find-perl/libemail-find-perl_0.09.orig.tar.gz Email-Find-0.09/t/rfc822.txt 84dc452402e1628c2fc233d0f963f6d0 - Email-Find-0.09/t/rfc822.txt 59975cc77db34020d4f62e69c6f53dcf - /home/jas/rfc/rfc822.txt MISMATCH rfc822.txt --- Email-Find-0.09/t/rfc822.txt 2001-06-05 23:00:56.000000000 +0200 +++ /home/jas/rfc/rfc822.txt 1991-10-17 18:47:17.000000000 +0100 @@ -1,34 +1,69 @@ - Internet RFC/STD/FYI/BCP Archives - RFC822 - [ Index | Search | What's New | Comments | Help ] - ---------------------------------------------------------------------- + RFC # 822 Obsoletes: RFC #733 (NIC #41952) + + + + + + + + + + + STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES + + + + + August 13, 1982 + + + + + Revised by David H. Crocker + Dept. of Electrical Engineering University of Delaware, Newark, DE 19711 Network: DCrocker @ UDel-Relay + + + + + + + + + + + + + + Standard for ARPA Internet Text Messages + TABLE OF CONTENTS + PREFACE .................................................... ii 1. INTRODUCTION ........................................... 1 @@ -68,6 +103,7 @@ 7. BIBLIOGRAPHY ........................................... 34 + APPENDIX A. EXAMPLES ............................................... 36 @@ -75,12 +111,18 @@ C. DIFFERENCES FROM RFC #733 .............................. 41 D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 + August 13, 1982 - i - RFC #822 + + + Standard for ARPA Internet Text Messages + PREFACE + By 1977, the Arpanet employed several informal standards for the text messages (mail) sent among its host computers. It was felt necessary to codify these practices and provide for those @@ -118,10 +160,24 @@ the BNF into an augmented BNF that makes the representation smaller and easier to understand. + + + + + + + + + + + August 13, 1982 - ii - RFC #822 + + Standard for ARPA Internet Text Messages + 1. INTRODUCTION 1.1. SCOPE @@ -171,10 +227,15 @@ messages; it permits distinguishing individual fields. Finally, there is definition of the contents of several structured fields. + + August 13, 1982 - 1 - RFC #822 + + Standard for ARPA Internet Text Messages + 1.2. COMMUNICATION FRAMEWORK Messages consist of lines of text. No special provisions @@ -222,10 +283,17 @@ message receivers is contingent upon the capabilities of their individual message systems. + + + + August 13, 1982 - 2 - RFC #822 + + Standard for ARPA Internet Text Messages + 2. NOTATIONAL CONVENTIONS This specification uses an augmented Backus-Naur Form (BNF) @@ -276,10 +344,14 @@ exactly occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters. + August 13, 1982 - 3 - RFC #822 + + Standard for ARPA Internet Text Messages + 2.7. #RULE: LISTS A construct "#" is defined, similar to "*", as follows: @@ -305,10 +377,39 @@ is a simple way of including useful notes in parallel with the specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 4 - RFC #822 + + Standard for ARPA Internet Text Messages + 3. LEXICAL ANALYSIS OF MESSAGES 3.1. GENERAL DESCRIPTION @@ -359,10 +460,14 @@ folding to higher-level syntactic breaks. For address fields, it is recommended that such folding occur + August 13, 1982 - 5 - RFC #822 + + Standard for ARPA Internet Text Messages + between addresses, after the separating comma. 3.1.2. STRUCTURE OF HEADER FIELDS @@ -413,10 +518,14 @@ that are simply strings of text, as described above. The analyzer provides an interpretation of the unfolded text + August 13, 1982 - 6 - RFC #822 + + Standard for ARPA Internet Text Messages + composing the body of the field as a sequence of lexical sym- bols. @@ -441,10 +550,40 @@ ":sysmail"@ Some-Group. Some-Org, Muhammed.(I am the greatest) Ali @(the)Vegas.WBA + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 7 - RFC #822 + + Standard for ARPA Internet Text Messages + is analyzed into the following lexical symbols and types: :sysmail quoted string @@ -479,10 +618,30 @@ at-sign ("@") and exactly one SPACE between all other s. Also, headers should be in a folded form. + + + + + + + + + + + + + + + + + August 13, 1982 - 8 - RFC #822 + + Standard for ARPA Internet Text Messages + 3.2. HEADER FIELD DEFINITIONS These rules show a field meta-syntax, without regard for the @@ -503,10 +662,44 @@ of combinations of atom, quoted-string, and specials tokens, or else consisting of texts> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 9 - RFC #822 + + Standard for ARPA Internet Text Messages + 3.3. LEXICAL TOKENS The following rules are used to define an underlying lexical @@ -555,10 +748,16 @@ domain-literal = "[" *(dtext / quoted-pair) "]" + + + August 13, 1982 - 10 - RFC #822 + + Standard for ARPA Internet Text Messages + dtext = may be folded "]", "\" & CR, & including linear-white-space> @@ -575,6 +774,7 @@ word = atom / quoted-string + 3.4. CLARIFICATIONS 3.4.1. QUOTING @@ -608,10 +808,14 @@ "Full Name"@Domain + August 13, 1982 - 11 - RFC #822 + + Standard for ARPA Internet Text Messages + 3.4.2. WHITE SPACE Note: In structured field bodies, multiple linear space ASCII @@ -662,10 +866,14 @@ If a comment is to be "folded" onto multiple lines, then the syntax for folding must be adhered to. (See the "Lexical + August 13, 1982 - 12 - RFC #822 + + Standard for ARPA Internet Text Messages + Analysis of Messages" section on "Folding Long Header Fields" above, and the section on "Case Independence" below.) Note that the official semantics therefore do not "see" any @@ -716,10 +924,14 @@ string is to be "folded" onto multiple lines, then the syntax for folding must be adhered to. (See the "Lexical Analysis of + August 13, 1982 - 13 - RFC #822 + + Standard for ARPA Internet Text Messages + Messages" section on "Folding Long Header Fields" above, and the section on "Case Independence" below.) Therefore, the official semantics do not "see" any bare CRLFs that are in @@ -764,10 +976,20 @@ Except as noted, alphabetic strings may be represented in any combination of upper and lower case. The only syntactic units + + + + + + + August 13, 1982 - 14 - RFC #822 + + Standard for ARPA Internet Text Messages + which requires preservation of case information are: - text @@ -815,10 +1037,17 @@ use of backspaces which effects an overstrike to the left of the beginning of the text or quoted-string is prohibited. + + + + August 13, 1982 - 15 - RFC #822 + + Standard for ARPA Internet Text Messages + 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS During transmission through heterogeneous networks, it may be @@ -860,10 +1089,23 @@ | idiosyncracies | Net-B ------------------ + + + + + + + + + + August 13, 1982 - 16 - RFC #822 + + Standard for ARPA Internet Text Messages + 4. MESSAGE SPECIFICATION 4.1. SYNTAX @@ -914,10 +1156,14 @@ ["id" msg-id] ; receiver msg id ["for" addr-spec] ; initial form + August 13, 1982 - 17 - RFC #822 + + Standard for ARPA Internet Text Messages + ";" date-time ; time received originator = authentic ; authenticated addr @@ -964,10 +1210,18 @@ msg-id = "<" addr-spec ">" ; Unique message id + + + + + August 13, 1982 - 18 - RFC #822 + + Standard for ARPA Internet Text Messages + extension-field = portion of a route-addr is provided for such occa- sions. It specifies the sequence of hosts and/or transmission + August 13, 1982 - 32 - RFC #822 + + Standard for ARPA Internet Text Messages + services that are to be traversed. Both domain-refs and domain-literals may be used. @@ -1729,12 +2063,38 @@ tivity to alphabetic case, so that "POSTMASTER", "postmas- ter", and even "poStmASteR" is to be accepted. + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 33 - RFC #822 + + Standard for ARPA Internet Text Messages + 7. BIBLIOGRAPHY + ANSI. "USA Standard Code for Information Interchange," X3.4. American National Standards Institute: New York (1968). Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- @@ -1782,10 +2142,14 @@ ARPANET Request for Comments, No. 680, Network Information Center No. 32116. SRI International: Menlo Park (1975). + August 13, 1982 - 34 - RFC #822 + + Standard for ARPA Internet Text Messages + NBS. "Specification of Message Format for Computer Based Message Systems, Recommended Federal Information Processing Standard." National Bureau of Standards: Gaithersburg, Maryland @@ -1815,12 +2179,38 @@ User Applications," ARPANET Request for Comments, No. 819. SRI International: Menlo Park (August 1982). + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 35 - RFC #822 + + Standard for ARPA Internet Text Messages + APPENDIX + A. EXAMPLES A.1. ADDRESSES @@ -1868,10 +2258,14 @@ Cruisers: Port@Portugal, Jones@SEA;, Another@Somewhere.SomeOrg + August 13, 1982 - 36 - RFC #822 + + Standard for ARPA Internet Text Messages + This group list example points out the use of comments and the mixing of addresses and groups. @@ -1922,10 +2316,14 @@ Note that if George had not included himself in the + August 13, 1982 - 37 - RFC #822 + + Standard for ARPA Internet Text Messages + enumeration of The Committee, he would not have gotten an implicit reply; the presence of the "Reply-to" field SUPER- SEDES the sending of a reply to the person named in the "From" @@ -1964,10 +2362,26 @@ Doe@Somewhere-Else Sender: Secy@SHost + + + + + + + + + + + + + August 13, 1982 - 38 - RFC #822 + + Standard for ARPA Internet Text Messages + A.3. COMPLETE HEADERS A.3.1. Minimum required @@ -2014,10 +2428,18 @@ preempted Message-ID: <4231.629.XYzi-What@Other-Host> + + + + + August 13, 1982 - 39 - RFC #822 + + Standard for ARPA Internet Text Messages + B. SIMPLE FIELD PARSING Some mail-reading software systems may wish to perform only @@ -2039,6 +2461,7 @@ B.1. SYNTAX + message = *field *(CRLF *text) field = field-name ":" [field-body] CRLF @@ -2047,6 +2470,7 @@ field-body = *text [CRLF LWSP-char field-body] + B.2. SEMANTICS Headers occur before the message body and are terminated by @@ -2061,10 +2485,19 @@ MUST be contained on one line. Upper and lower case are not dis- tinguished when comparing field-names. + + + + + + August 13, 1982 - 40 - RFC #822 + + Standard for ARPA Internet Text Messages + C. DIFFERENCES FROM RFC #733 The following summarizes the differences between this stan- @@ -2112,10 +2545,17 @@ The "Return-path:" and "Received:" fields have been specified. + + + + August 13, 1982 - 41 - RFC #822 + + Standard for ARPA Internet Text Messages + C.3.2. FROM The "From" field must contain machine-usable addresses (addr- @@ -2162,10 +2602,18 @@ C.5. ADDRESS SPECIFICATION + + + + + August 13, 1982 - 42 - RFC #822 + + Standard for ARPA Internet Text Messages + C.5.1. ADDRESS The use of quoted-string, and the ":"-atom-":" construct, have @@ -2208,10 +2656,22 @@ The local-part "Postmaster" has been reserved, so that users can be guaranteed at least one valid address at a site. + + + + + + + + + August 13, 1982 - 43 - RFC #822 + + Standard for ARPA Internet Text Messages + D. ALPHABETICAL LISTING OF SYNTAX RULES address = mailbox ; one addressee @@ -2262,10 +2722,14 @@ specification; none will have names beginning with the string "X-"> + August 13, 1982 - 44 - RFC #822 + + Standard for ARPA Internet Text Messages + field = field-name ":" [ field-body ] CRLF fields = dates ; Creation time, source ; author id & one @@ -2314,10 +2778,16 @@ [ "Reply-To" ":" 1#address] ) phrase = 1*word ; Sequence of words + + + August 13, 1982 - 45 - RFC #822 + + Standard for ARPA Internet Text Messages + qtext = , ; => may be folded "\" & CR, and including linear-white-space> @@ -2366,10 +2836,16 @@ pre-empted by published extensions> word = atom / quoted-string + + + August 13, 1982 - 46 - RFC #822 + + Standard for ARPA Internet Text Messages + zone = "UT" / "GMT" ; Universal Time ; North American : UT / "EST" / "EDT" ; Eastern: - 5/ - 4 @@ -2379,11 +2855,47 @@ / 1ALPHA ; Military: Z = UT; <"> = ; ( 42, 34.) - August 13, 1982 - 47 - RFC #822 - ---------------------------------------------------------------------- - [ Index | Search | What's New | Comments | Help ] - Comments/Questions about this archive ? Send mail to rfc-admin@faqs.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 47 - RFC #822 + Email-Find-0.09/t/rfc822.txt /home/jas/rfc/rfc822.txt differ: byte 1, line 1 pkg libgcgi ver 0.9.5-1.1 lastfile libgcgi_0.9.5.orig.tar.gz files libgcgi-0.9.5.orig/doc/rfc1806.txt libgcgi-0.9.5.orig/doc/rfc2046.txt libgcgi-0.9.5.orig/doc/rfc2388.txt libgcgi-0.9.5.orig/doc/rfc2396.txt libgcgi-0.9.5.orig/doc/rfc2616.txt tar xfz /data/debian/pool/main/libg/libgcgi/libgcgi_0.9.5.orig.tar.gz libgcgi-0.9.5.orig/doc/rfc1806.txt d38a481215e97747d48239adde5b9978 - libgcgi-0.9.5.orig/doc/rfc1806.txt d38a481215e97747d48239adde5b9978 - /home/jas/rfc/rfc1806.txt MATCH rfc1806.txt tar xfz /data/debian/pool/main/libg/libgcgi/libgcgi_0.9.5.orig.tar.gz libgcgi-0.9.5.orig/doc/rfc2046.txt 6225c196e3c5a20155f3a2082aea2801 - libgcgi-0.9.5.orig/doc/rfc2046.txt 6225c196e3c5a20155f3a2082aea2801 - /home/jas/rfc/rfc2046.txt MATCH rfc2046.txt tar xfz /data/debian/pool/main/libg/libgcgi/libgcgi_0.9.5.orig.tar.gz libgcgi-0.9.5.orig/doc/rfc2388.txt b06ea28cbd76c7a15fcdf06e25ed3d75 - libgcgi-0.9.5.orig/doc/rfc2388.txt b06ea28cbd76c7a15fcdf06e25ed3d75 - /home/jas/rfc/rfc2388.txt MATCH rfc2388.txt tar xfz /data/debian/pool/main/libg/libgcgi/libgcgi_0.9.5.orig.tar.gz libgcgi-0.9.5.orig/doc/rfc2396.txt f220ecfce7f18e502c117d3006597725 - libgcgi-0.9.5.orig/doc/rfc2396.txt f220ecfce7f18e502c117d3006597725 - /home/jas/rfc/rfc2396.txt MATCH rfc2396.txt tar xfz /data/debian/pool/main/libg/libgcgi/libgcgi_0.9.5.orig.tar.gz libgcgi-0.9.5.orig/doc/rfc2616.txt 9fa63f5083e4d2112d2e71b008e387e8 - libgcgi-0.9.5.orig/doc/rfc2616.txt 9fa63f5083e4d2112d2e71b008e387e8 - /home/jas/rfc/rfc2616.txt MATCH rfc2616.txt pkg libidn ver 0.6.5-1 lastfile libidn_0.6.5.orig.tar.gz files libidn-0.6.5/doc/specifications/rfc3454.txt tar xfz /data/debian/pool/main/libi/libidn/libidn_0.6.5.orig.tar.gz libidn-0.6.5/doc/specifications/rfc3454.txt ecfec18da3c0ed1de138a766a0c7e35d - libidn-0.6.5/doc/specifications/rfc3454.txt ecfec18da3c0ed1de138a766a0c7e35d - /home/jas/rfc/rfc3454.txt MATCH rfc3454.txt pkg libsmi ver 0.4.5-1 lastfile libsmi_0.4.5.orig.tar.gz files libsmi-0.4.5/doc/draft-irtf-nmrg-sming-02.txt libsmi-0.4.5/doc/draft-irtf-nmrg-smi-xml-00.txt libsmi-0.4.5/doc/draft-irtf-nmrg-smi-xml-01.txt tar xfz /data/debian/pool/main/libs/libsmi/libsmi_0.4.5.orig.tar.gz libsmi-0.4.5/doc/draft-irtf-nmrg-sming-02.txt 593471d6b662c0753bd52dadcbd36047 - libsmi-0.4.5/doc/draft-irtf-nmrg-sming-02.txt 72729f64cbf9e521a3dc7001c18313e6 - /home/jas/rfc/draft-irtf-nmrg-sming-02.txt MISMATCH draft-irtf-nmrg-sming-02.txt --- libsmi-0.4.5/doc/draft-irtf-nmrg-sming-02.txt 2005-11-25 10:14:01.000000000 +0100 +++ /home/jas/rfc/draft-irtf-nmrg-sming-02.txt 2000-11-11 14:00:00.000000000 +0100 @@ -1,12 +1,11 @@ - Network Working Group F. Strauss Internet-Draft TU Braunschweig Expires: August 15, 2000 February 15, 2000 SMIng - A new Structure of Management Information - draft-irtf-nmrg-sming-02 + draft-irtf-nmrg-sming-02.txt Status of this Memo @@ -23,7 +22,11 @@ at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - To view the entire list of Internet-Draft Shadow Directories, see + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + + The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2000. @@ -54,6 +57,7 @@ Strauss Expires August 15, 2000 [Page 1] + Internet-Draft SMIng February 2000 @@ -110,6 +114,7 @@ Strauss Expires August 15, 2000 [Page 2] + Internet-Draft SMIng February 2000 @@ -166,6 +171,7 @@ Strauss Expires August 15, 2000 [Page 3] + Internet-Draft SMIng February 2000 @@ -222,6 +228,7 @@ Strauss Expires August 15, 2000 [Page 4] + Internet-Draft SMIng February 2000 @@ -278,6 +285,7 @@ Strauss Expires August 15, 2000 [Page 5] + Internet-Draft SMIng February 2000 @@ -334,6 +342,7 @@ Strauss Expires August 15, 2000 [Page 6] + Internet-Draft SMIng February 2000 @@ -390,6 +399,7 @@ Strauss Expires August 15, 2000 [Page 7] + Internet-Draft SMIng February 2000 @@ -446,6 +456,7 @@ Strauss Expires August 15, 2000 [Page 8] + Internet-Draft SMIng February 2000 @@ -502,6 +513,7 @@ Strauss Expires August 15, 2000 [Page 9] + Internet-Draft SMIng February 2000 @@ -558,6 +570,7 @@ Strauss Expires August 15, 2000 [Page 10] + Internet-Draft SMIng February 2000 @@ -614,6 +627,7 @@ Strauss Expires August 15, 2000 [Page 11] + Internet-Draft SMIng February 2000 @@ -670,6 +684,7 @@ Strauss Expires August 15, 2000 [Page 12] + Internet-Draft SMIng February 2000 @@ -726,6 +741,7 @@ Strauss Expires August 15, 2000 [Page 13] + Internet-Draft SMIng February 2000 @@ -782,6 +798,7 @@ Strauss Expires August 15, 2000 [Page 14] + Internet-Draft SMIng February 2000 @@ -838,6 +855,7 @@ Strauss Expires August 15, 2000 [Page 15] + Internet-Draft SMIng February 2000 @@ -894,6 +912,7 @@ Strauss Expires August 15, 2000 [Page 16] + Internet-Draft SMIng February 2000 @@ -950,6 +969,7 @@ Strauss Expires August 15, 2000 [Page 17] + Internet-Draft SMIng February 2000 @@ -1006,6 +1026,7 @@ Strauss Expires August 15, 2000 [Page 18] + Internet-Draft SMIng February 2000 @@ -1062,6 +1083,7 @@ Strauss Expires August 15, 2000 [Page 19] + Internet-Draft SMIng February 2000 @@ -1118,6 +1140,7 @@ Strauss Expires August 15, 2000 [Page 20] + Internet-Draft SMIng February 2000 @@ -1174,6 +1197,7 @@ Strauss Expires August 15, 2000 [Page 21] + Internet-Draft SMIng February 2000 @@ -1230,6 +1254,7 @@ Strauss Expires August 15, 2000 [Page 22] + Internet-Draft SMIng February 2000 @@ -1286,6 +1311,7 @@ Strauss Expires August 15, 2000 [Page 23] + Internet-Draft SMIng February 2000 @@ -1342,6 +1368,7 @@ Strauss Expires August 15, 2000 [Page 24] + Internet-Draft SMIng February 2000 @@ -1398,6 +1425,7 @@ Strauss Expires August 15, 2000 [Page 25] + Internet-Draft SMIng February 2000 @@ -1454,6 +1482,7 @@ Strauss Expires August 15, 2000 [Page 26] + Internet-Draft SMIng February 2000 @@ -1510,6 +1539,7 @@ Strauss Expires August 15, 2000 [Page 27] + Internet-Draft SMIng February 2000 @@ -1566,6 +1596,7 @@ Strauss Expires August 15, 2000 [Page 28] + Internet-Draft SMIng February 2000 @@ -1622,6 +1653,7 @@ Strauss Expires August 15, 2000 [Page 29] + Internet-Draft SMIng February 2000 @@ -1678,6 +1710,7 @@ Strauss Expires August 15, 2000 [Page 30] + Internet-Draft SMIng February 2000 @@ -1734,6 +1767,7 @@ Strauss Expires August 15, 2000 [Page 31] + Internet-Draft SMIng February 2000 @@ -1790,6 +1824,7 @@ Strauss Expires August 15, 2000 [Page 32] + Internet-Draft SMIng February 2000 @@ -1846,6 +1881,7 @@ Strauss Expires August 15, 2000 [Page 33] + Internet-Draft SMIng February 2000 @@ -1902,6 +1938,7 @@ Strauss Expires August 15, 2000 [Page 34] + Internet-Draft SMIng February 2000 @@ -1958,6 +1995,7 @@ Strauss Expires August 15, 2000 [Page 35] + Internet-Draft SMIng February 2000 @@ -2014,6 +2052,7 @@ Strauss Expires August 15, 2000 [Page 36] + Internet-Draft SMIng February 2000 @@ -2070,6 +2109,7 @@ Strauss Expires August 15, 2000 [Page 37] + Internet-Draft SMIng February 2000 @@ -2126,6 +2166,7 @@ Strauss Expires August 15, 2000 [Page 38] + Internet-Draft SMIng February 2000 @@ -2182,6 +2223,7 @@ Strauss Expires August 15, 2000 [Page 39] + Internet-Draft SMIng February 2000 @@ -2238,6 +2280,7 @@ Strauss Expires August 15, 2000 [Page 40] + Internet-Draft SMIng February 2000 @@ -2294,6 +2337,7 @@ Strauss Expires August 15, 2000 [Page 41] + Internet-Draft SMIng February 2000 @@ -2350,6 +2394,7 @@ Strauss Expires August 15, 2000 [Page 42] + Internet-Draft SMIng February 2000 @@ -2406,6 +2451,7 @@ Strauss Expires August 15, 2000 [Page 43] + Internet-Draft SMIng February 2000 @@ -2462,6 +2508,7 @@ Strauss Expires August 15, 2000 [Page 44] + Internet-Draft SMIng February 2000 @@ -2518,6 +2565,7 @@ Strauss Expires August 15, 2000 [Page 45] + Internet-Draft SMIng February 2000 @@ -2574,6 +2622,7 @@ Strauss Expires August 15, 2000 [Page 46] + Internet-Draft SMIng February 2000 @@ -2630,6 +2679,7 @@ Strauss Expires August 15, 2000 [Page 47] + Internet-Draft SMIng February 2000 @@ -2686,6 +2736,7 @@ Strauss Expires August 15, 2000 [Page 48] + Internet-Draft SMIng February 2000 @@ -2742,6 +2793,7 @@ Strauss Expires August 15, 2000 [Page 49] + Internet-Draft SMIng February 2000 @@ -2798,6 +2850,7 @@ Strauss Expires August 15, 2000 [Page 50] + Internet-Draft SMIng February 2000 @@ -2854,6 +2907,7 @@ Strauss Expires August 15, 2000 [Page 51] + Internet-Draft SMIng February 2000 @@ -2910,6 +2964,7 @@ Strauss Expires August 15, 2000 [Page 52] + Internet-Draft SMIng February 2000 @@ -2966,6 +3021,7 @@ Strauss Expires August 15, 2000 [Page 53] + Internet-Draft SMIng February 2000 @@ -3022,6 +3078,7 @@ Strauss Expires August 15, 2000 [Page 54] + Internet-Draft SMIng February 2000 @@ -3078,6 +3135,7 @@ Strauss Expires August 15, 2000 [Page 55] + Internet-Draft SMIng February 2000 @@ -3134,6 +3192,7 @@ Strauss Expires August 15, 2000 [Page 56] + Internet-Draft SMIng February 2000 @@ -3190,6 +3249,7 @@ Strauss Expires August 15, 2000 [Page 57] + Internet-Draft SMIng February 2000 @@ -3246,6 +3306,7 @@ Strauss Expires August 15, 2000 [Page 58] + Internet-Draft SMIng February 2000 @@ -3281,9 +3342,9 @@ // // $RCSfile: IRTF-NMRG-SMING,v $ - // $Revision: 817 $ + // $Revision: 1.2 $ // $Author: strauss $ - // $Date: 2000-02-15 11:41:02 +0100 (Tue, 15 Feb 2000) $ + // $Date: 2000/02/13 22:11:43 $ // organization "IRTF Network Management Research Group (NMRG), @@ -3302,6 +3363,7 @@ Strauss Expires August 15, 2000 [Page 59] + Internet-Draft SMIng February 2000 @@ -3351,13 +3413,14 @@ // // $RCSfile: IRTF-NMRG-SMING-TYPES,v $ - // $Revision: 817 $ + // $Revision: 1.3 $ // $Author: strauss $ - // $Date: 2000-02-15 11:41:02 +0100 (Tue, 15 Feb 2000) $ + // $Date: 2000/02/13 22:11:43 $ Strauss Expires August 15, 2000 [Page 60] + Internet-Draft SMIng February 2000 @@ -3414,6 +3477,7 @@ Strauss Expires August 15, 2000 [Page 61] + Internet-Draft SMIng February 2000 @@ -3470,6 +3534,7 @@ Strauss Expires August 15, 2000 [Page 62] + Internet-Draft SMIng February 2000 @@ -3526,6 +3591,7 @@ Strauss Expires August 15, 2000 [Page 63] + Internet-Draft SMIng February 2000 @@ -3582,6 +3648,7 @@ Strauss Expires August 15, 2000 [Page 64] + Internet-Draft SMIng February 2000 @@ -3638,6 +3705,7 @@ Strauss Expires August 15, 2000 [Page 65] + Internet-Draft SMIng February 2000 @@ -3694,6 +3762,7 @@ Strauss Expires August 15, 2000 [Page 66] + Internet-Draft SMIng February 2000 @@ -3750,6 +3819,7 @@ Strauss Expires August 15, 2000 [Page 67] + Internet-Draft SMIng February 2000 @@ -3806,6 +3876,7 @@ Strauss Expires August 15, 2000 [Page 68] + Internet-Draft SMIng February 2000 @@ -3862,6 +3933,7 @@ Strauss Expires August 15, 2000 [Page 69] + Internet-Draft SMIng February 2000 @@ -3918,6 +3990,7 @@ Strauss Expires August 15, 2000 [Page 70] + Internet-Draft SMIng February 2000 @@ -3974,6 +4047,7 @@ Strauss Expires August 15, 2000 [Page 71] + Internet-Draft SMIng February 2000 @@ -4030,6 +4104,7 @@ Strauss Expires August 15, 2000 [Page 72] + Internet-Draft SMIng February 2000 @@ -4086,6 +4161,7 @@ Strauss Expires August 15, 2000 [Page 73] + Internet-Draft SMIng February 2000 @@ -4142,6 +4218,7 @@ Strauss Expires August 15, 2000 [Page 74] + Internet-Draft SMIng February 2000 @@ -4198,6 +4275,7 @@ Strauss Expires August 15, 2000 [Page 75] + Internet-Draft SMIng February 2000 @@ -4254,6 +4332,7 @@ Strauss Expires August 15, 2000 [Page 76] + Internet-Draft SMIng February 2000 @@ -4310,6 +4389,7 @@ Strauss Expires August 15, 2000 [Page 77] + Internet-Draft SMIng February 2000 @@ -4366,6 +4446,7 @@ Strauss Expires August 15, 2000 [Page 78] + Internet-Draft SMIng February 2000 @@ -4407,9 +4488,9 @@ // // $RCSfile: IRTF-NMRG-SMING-EXTENSIONS,v $ - // $Revision: 817 $ + // $Revision: 1.3 $ // $Author: strauss $ - // $Date: 2000-02-15 11:41:02 +0100 (Tue, 15 Feb 2000) $ + // $Date: 2000/02/13 22:11:43 $ // organization "IRTF Network Management Research Group (NMRG), @@ -4422,6 +4503,7 @@ Strauss Expires August 15, 2000 [Page 79] + Internet-Draft SMIng February 2000 @@ -4478,6 +4560,7 @@ Strauss Expires August 15, 2000 [Page 80] + Internet-Draft SMIng February 2000 @@ -4534,6 +4617,7 @@ Strauss Expires August 15, 2000 [Page 81] + Internet-Draft SMIng February 2000 @@ -4590,6 +4674,7 @@ Strauss Expires August 15, 2000 [Page 82] + Internet-Draft SMIng February 2000 @@ -4646,6 +4731,7 @@ Strauss Expires August 15, 2000 [Page 83] + Internet-Draft SMIng February 2000 @@ -4702,6 +4788,7 @@ Strauss Expires August 15, 2000 [Page 84] + Internet-Draft SMIng February 2000 @@ -4758,6 +4845,7 @@ Strauss Expires August 15, 2000 [Page 85] + Internet-Draft SMIng February 2000 @@ -4814,6 +4902,7 @@ Strauss Expires August 15, 2000 [Page 86] + Internet-Draft SMIng February 2000 @@ -4870,6 +4959,7 @@ Strauss Expires August 15, 2000 [Page 87] + Internet-Draft SMIng February 2000 @@ -4926,6 +5016,7 @@ Strauss Expires August 15, 2000 [Page 88] + Internet-Draft SMIng February 2000 @@ -4982,6 +5073,7 @@ Strauss Expires August 15, 2000 [Page 89] + Internet-Draft SMIng February 2000 @@ -5038,6 +5130,7 @@ Strauss Expires August 15, 2000 [Page 90] + Internet-Draft SMIng February 2000 @@ -5052,7 +5145,7 @@ ;; ;; sming.abnf -- SMIng grammar in ABNF notation (RFC 2234). ;; - ;; @(#) $Id: draft-irtf-nmrg-sming-02.txt 817 2000-02-15 10:41:02Z strauss $ + ;; @(#) $Id: sming.abnf,v 1.5 2000/02/13 22:17:56 strauss Exp $ ;; ;; Copyright (C) The Internet Society (1999). All Rights Reserved. ;; @@ -5094,6 +5187,7 @@ Strauss Expires August 15, 2000 [Page 91] + Internet-Draft SMIng February 2000 @@ -5150,6 +5244,7 @@ Strauss Expires August 15, 2000 [Page 92] + Internet-Draft SMIng February 2000 @@ -5206,6 +5301,7 @@ Strauss Expires August 15, 2000 [Page 93] + Internet-Draft SMIng February 2000 @@ -5262,6 +5358,7 @@ Strauss Expires August 15, 2000 [Page 94] + Internet-Draft SMIng February 2000 @@ -5318,6 +5415,7 @@ Strauss Expires August 15, 2000 [Page 95] + Internet-Draft SMIng February 2000 @@ -5374,6 +5472,7 @@ Strauss Expires August 15, 2000 [Page 96] + Internet-Draft SMIng February 2000 @@ -5430,6 +5529,7 @@ Strauss Expires August 15, 2000 [Page 97] + Internet-Draft SMIng February 2000 @@ -5486,6 +5586,7 @@ Strauss Expires August 15, 2000 [Page 98] + Internet-Draft SMIng February 2000 @@ -5542,6 +5643,7 @@ Strauss Expires August 15, 2000 [Page 99] + Internet-Draft SMIng February 2000 @@ -5598,6 +5700,7 @@ Strauss Expires August 15, 2000 [Page 100] + Internet-Draft SMIng February 2000 @@ -5654,6 +5757,7 @@ Strauss Expires August 15, 2000 [Page 101] + Internet-Draft SMIng February 2000 @@ -5710,6 +5814,7 @@ Strauss Expires August 15, 2000 [Page 102] + Internet-Draft SMIng February 2000 @@ -5766,6 +5871,7 @@ Strauss Expires August 15, 2000 [Page 103] + Internet-Draft SMIng February 2000 @@ -5822,6 +5928,7 @@ Strauss Expires August 15, 2000 [Page 104] + Internet-Draft SMIng February 2000 @@ -5878,3 +5985,4 @@ Strauss Expires August 15, 2000 [Page 105] + libsmi-0.4.5/doc/draft-irtf-nmrg-sming-02.txt /home/jas/rfc/draft-irtf-nmrg-sming-02.txt differ: byte 2, line 2 tar xfz /data/debian/pool/main/libs/libsmi/libsmi_0.4.5.orig.tar.gz libsmi-0.4.5/doc/draft-irtf-nmrg-smi-xml-00.txt 446ce0d22c255ebcd6a7454031464e45 - libsmi-0.4.5/doc/draft-irtf-nmrg-smi-xml-00.txt 8d854b082a591e8e2eb7fbeba4c485e0 - /home/jas/rfc/draft-irtf-nmrg-smi-xml-00.txt MISMATCH draft-irtf-nmrg-smi-xml-00.txt --- libsmi-0.4.5/doc/draft-irtf-nmrg-smi-xml-00.txt 2005-11-25 10:14:01.000000000 +0100 +++ /home/jas/rfc/draft-irtf-nmrg-smi-xml-00.txt 2001-06-23 16:00:00.000000000 +0200 @@ -1,5 +1,3 @@ - - Network Working Group J. Schoenwaelder Internet-Draft F. Strauss Expires: December 20, 2000 TU Braunschweig @@ -670,3 +668,5 @@ Schoenwaelder & Strauss Expires December 20, 2000 [Page 12] + + libsmi-0.4.5/doc/draft-irtf-nmrg-smi-xml-00.txt /home/jas/rfc/draft-irtf-nmrg-smi-xml-00.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/libs/libsmi/libsmi_0.4.5.orig.tar.gz libsmi-0.4.5/doc/draft-irtf-nmrg-smi-xml-01.txt a851ae8d3abe1b20753ed8c7364dfe97 - libsmi-0.4.5/doc/draft-irtf-nmrg-smi-xml-01.txt e217a0483df75c364a433266150bb87b - /home/jas/rfc/draft-irtf-nmrg-smi-xml-01.txt MISMATCH draft-irtf-nmrg-smi-xml-01.txt --- libsmi-0.4.5/doc/draft-irtf-nmrg-smi-xml-01.txt 2005-11-25 10:14:01.000000000 +0100 +++ /home/jas/rfc/draft-irtf-nmrg-smi-xml-01.txt 2005-02-11 16:02:16.000000000 +0100 @@ -1,1008 +1,19 @@ - -Network Working Group J. Schoenwaelder -Internet-Draft F. Strauss -Expires: July 10, 2002 TU Braunschweig - January 9, 2002 - - - Using XML to Exchange SMI Definitions - draft-irtf-nmrg-smi-xml-01 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 10, 2002. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This memo describes how the Extensible Markup Language (XML) can be - used to exchange SMIv1 and SMIv2 definitions between XML enabled - applications. - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 1] - -Internet-Draft XML SMI Exchange Format January 2002 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. SMI XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 - References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 2] - -Internet-Draft XML SMI Exchange Format January 2002 - - -1. Introduction - - This memo describes how the Extensible Markup Language (XML) [1] can - be used to exchange SMIv1 [2][3][4] and SMIv2 [5][6][7] definitions - between XML enabled applications. The acronym SMI is used throughout - this document as a version neutral name for SMIv1 or SMIv2. - - The XML Schema defined in this memo allows applications with embedded - generic XML parsers to read (or edit) the original SMI definitions. - The XML Schema is optimized for this purpose. Terseness of the XML - output was of minimal importance since humans are expected to read - the originial SMI definitions. - - In fact, the XML format of an SMI module is significantly longer - compared to the original SMI definition. This is in line with the - design goals for XML, which favours computer readability over - terseness. - - There are several scenarios where an XML representation of SMI - definitions is useful: - - o The XML format may be used as an intermediate format between a - validating SMI compiler/parser and post processing tools such as - code or schema generators. (The undocumented mosy format has been - used in the past for this purpose. The mosy format does not - preserve all information present in a SMI module and is therefore - problematic.) - - o The XML format can be used with XSLT post processors to generate - documentation in various formats. - - o The XML format makes it possible to access SMI definitions from a - variety of programming languages. E.g., XML parsers are available - in Java, C, C++, Tcl, Perl, Python, and GNU Emacs Lisp in both - commercial and open source forms. - - o There are generic tools for maintaining large sets of XML - definitions. This includes tools to search for definitions with a - specific property. Such generic XML tools can be very useful in - organizations that must maintain large amounts of SMI definitions. - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 3] - -Internet-Draft XML SMI Exchange Format January 2002 - - -2. SMI XML Schema - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 4] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 5] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 6] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 7] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 8] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 9] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 10] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 11] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 12] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 13] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 14] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 15] - -Internet-Draft XML SMI Exchange Format January 2002 - - - - - - - - - - - - - -3. Examples - -4. Open Issues - - Shall we get rid of the identity element by making it an optional - attribute of the module element? - - -5. Acknowledgments - - This document is the result of discussions within the Network - Management Research Group (NMRG) of the Internet Research Task - Force[8] (IRTF). - - Special thanks to Bert Helthuis, Atin Banerjee and Debnarayan Kar for - providing useful feedback and access to their private SMI XML DTDs. - - A prototype implementation of an SMIv1/v2 converter to XML is freely - available as part of the libsmi[9] SMI parser library distribution. - -References - - [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 - (Second Edition)", W3C REC-xml-20001006, October 2000. - - [2] Rose, M. and K. McCloghrie, "Structure and identification of - management information for TCP/IP-based internets", STD 16, RFC - 1155, May 1990. - - [3] Rose, M. and K. McCloghrie, "Concise MIB definitions", STD 16, - RFC 1212, March 1991. - - [4] Rose, M., "Convention for defining traps for use with the SNMP", - RFC 1215, March 1991. - - [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., - McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 16] - -Internet-Draft XML SMI Exchange Format January 2002 - - - Management Information Version 2 (SMIv2)", STD 58, RFC 2578, - April 1999. - - [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., - McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions - for SMIv2", STD 58, RFC 2579, April 1999. - - [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance - Statements for SMIv2", STD 58, RFC 2580, April 1999. - - [8] - - [9] - - -Authors' Addresses - - Juergen Schoenwaelder - TU Braunschweig - Muehlenpfordtstrasse 23 - 38106 Braunschweig - Germany - - Phone: +49 531 391-3289 - EMail: schoenw@ibr.cs.tu-bs.de - - - Frank Strauss - TU Braunschweig - Muehlenpfordtstrasse 23 - 38106 Braunschweig - Germany - - Phone: +49 531 391-3266 - EMail: strauss@ibr.cs.tu-bs.de - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 17] - -Internet-Draft XML SMI Exchange Format January 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Schoenwaelder & Strauss Expires July 10, 2002 [Page 18] - +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +The name of the internet-draft was draft-irtf-nmrg-smi-xml-00.txt + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): +Juergen Schoenwaelder , +Frank Strauss libsmi-0.4.5/doc/draft-irtf-nmrg-smi-xml-01.txt /home/jas/rfc/draft-irtf-nmrg-smi-xml-01.txt differ: byte 2, line 2 pkg libspf ver 0.999-1.0.0-p3-3 lastfile libspf_0.999-1.0.0-p3.orig.tar.gz files libspf-1.0.0-p3/docs/RFC/spf-draft-200405.txt tar xfz /data/debian/pool/main/libs/libspf/libspf_0.999-1.0.0-p3.orig.tar.gz libspf-1.0.0-p3/docs/RFC/spf-draft-200405.txt 62c7b65f3e9474ae8430925a67453052 - libspf-1.0.0-p3/docs/RFC/spf-draft-200405.txt ~/rfc /data/debian/bad/libspf-0.999-1.0.0-p3-3 --15:18:41-- http://bgp.potaroo.net/ietf/all-ids//spf-draft-200405.txt => `spf-draft-200405.txt' Resolving bgp.potaroo.net... 203.50.0.159 Connecting to bgp.potaroo.net|203.50.0.159|:80... connected. HTTP request sent, awaiting response... 404 Not Found 15:18:42 ERROR 404: Not Found. FETCH-FAIL spf-draft-200405.txt /data/debian/bad/libspf-0.999-1.0.0-p3-3 d41d8cd98f00b204e9800998ecf8427e - /home/jas/rfc/spf-draft-200405.txt MISMATCH spf-draft-200405.txt diff: /home/jas/rfc/spf-draft-200405.txt: No such file or directory cmp: /home/jas/rfc/spf-draft-200405.txt: No such file or directory pkg libspf2 ver 1.2.5-3 lastfile libspf2_1.2.5.orig.tar.gz files libspf2-1.2.5.orig/docs/draft-mengwong-spf-00.txt tar xfz /data/debian/pool/main/libs/libspf2/libspf2_1.2.5.orig.tar.gz libspf2-1.2.5.orig/docs/draft-mengwong-spf-00.txt 2aa924f1db7e1be978f5c5e0b11c2570 - libspf2-1.2.5.orig/docs/draft-mengwong-spf-00.txt 2aa924f1db7e1be978f5c5e0b11c2570 - /home/jas/rfc/draft-mengwong-spf-00.txt MATCH draft-mengwong-spf-00.txt pkg libtheora ver 0.0.0.alpha7-1 lastfile libtheora_0.0.0.alpha7.orig.tar.gz files libtheora-1.0alpha7/doc/draft-barbato-avt-rtp-theora-01.txt tar xfz /data/debian/pool/main/libt/libtheora/libtheora_0.0.0.alpha7.orig.tar.gz libtheora-1.0alpha7/doc/draft-barbato-avt-rtp-theora-01.txt c5281f381e0399613af3623370e9eae6 - libtheora-1.0alpha7/doc/draft-barbato-avt-rtp-theora-01.txt 75f216cf3d16ad4f6370bd2251977db0 - /home/jas/rfc/draft-barbato-avt-rtp-theora-01.txt MISMATCH draft-barbato-avt-rtp-theora-01.txt --- libtheora-1.0alpha7/doc/draft-barbato-avt-rtp-theora-01.txt 2006-06-20 21:09:20.000000000 +0200 +++ /home/jas/rfc/draft-barbato-avt-rtp-theora-01.txt 2006-06-28 18:01:53.000000000 +0200 @@ -4,7 +4,7 @@ AVT Working Group L. Barbato Internet-Draft Xiph.Org -Expires: December 18, 2006 June 16, 2006 +Expires: December 28, 2006 June 26, 2006 draft-barbato-avt-rtp-theora-01 @@ -33,7 +33,7 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 18, 2006. + This Internet-Draft will expire on December 28, 2006. Copyright Notice @@ -53,7 +53,7 @@ -Barbato Expires December 18, 2006 [Page 1] +Barbato Expires December 28, 2006 [Page 1] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -109,7 +109,7 @@ -Barbato Expires December 18, 2006 [Page 2] +Barbato Expires December 28, 2006 [Page 2] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -165,7 +165,7 @@ -Barbato Expires December 18, 2006 [Page 3] +Barbato Expires December 28, 2006 [Page 3] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -221,7 +221,7 @@ -Barbato Expires December 18, 2006 [Page 4] +Barbato Expires December 28, 2006 [Page 4] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -277,7 +277,7 @@ -Barbato Expires December 18, 2006 [Page 5] +Barbato Expires December 28, 2006 [Page 5] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -333,7 +333,7 @@ -Barbato Expires December 18, 2006 [Page 6] +Barbato Expires December 28, 2006 [Page 6] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -389,7 +389,7 @@ -Barbato Expires December 18, 2006 [Page 7] +Barbato Expires December 28, 2006 [Page 7] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -445,7 +445,7 @@ -Barbato Expires December 18, 2006 [Page 8] +Barbato Expires December 28, 2006 [Page 8] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -501,7 +501,7 @@ -Barbato Expires December 18, 2006 [Page 9] +Barbato Expires December 28, 2006 [Page 9] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -557,7 +557,7 @@ -Barbato Expires December 18, 2006 [Page 10] +Barbato Expires December 28, 2006 [Page 10] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -613,7 +613,7 @@ -Barbato Expires December 18, 2006 [Page 11] +Barbato Expires December 28, 2006 [Page 11] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -669,7 +669,7 @@ -Barbato Expires December 18, 2006 [Page 12] +Barbato Expires December 28, 2006 [Page 12] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -725,7 +725,7 @@ -Barbato Expires December 18, 2006 [Page 13] +Barbato Expires December 28, 2006 [Page 13] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -781,7 +781,7 @@ -Barbato Expires December 18, 2006 [Page 14] +Barbato Expires December 28, 2006 [Page 14] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -837,7 +837,7 @@ -Barbato Expires December 18, 2006 [Page 15] +Barbato Expires December 28, 2006 [Page 15] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -893,7 +893,7 @@ -Barbato Expires December 18, 2006 [Page 16] +Barbato Expires December 28, 2006 [Page 16] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -949,7 +949,7 @@ -Barbato Expires December 18, 2006 [Page 17] +Barbato Expires December 28, 2006 [Page 17] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -1005,7 +1005,7 @@ -Barbato Expires December 18, 2006 [Page 18] +Barbato Expires December 28, 2006 [Page 18] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -1061,7 +1061,7 @@ -Barbato Expires December 18, 2006 [Page 19] +Barbato Expires December 28, 2006 [Page 19] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -1117,7 +1117,7 @@ -Barbato Expires December 18, 2006 [Page 20] +Barbato Expires December 28, 2006 [Page 20] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -1173,7 +1173,7 @@ -Barbato Expires December 18, 2006 [Page 21] +Barbato Expires December 28, 2006 [Page 21] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -1229,7 +1229,7 @@ -Barbato Expires December 18, 2006 [Page 22] +Barbato Expires December 28, 2006 [Page 22] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -1285,7 +1285,7 @@ -Barbato Expires December 18, 2006 [Page 23] +Barbato Expires December 28, 2006 [Page 23] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -1341,7 +1341,7 @@ -Barbato Expires December 18, 2006 [Page 24] +Barbato Expires December 28, 2006 [Page 24] Internet-Draft draft-barbato-avt-rtp-theora-01 June 2006 @@ -1397,6 +1397,6 @@ -Barbato Expires December 18, 2006 [Page 25] +Barbato Expires December 28, 2006 [Page 25] libtheora-1.0alpha7/doc/draft-barbato-avt-rtp-theora-01.txt /home/jas/rfc/draft-barbato-avt-rtp-theora-01.txt differ: byte 169, line 7 pkg libunicode-map8-perl ver 0.12-2 lastfile libunicode-map8-perl_0.12.orig.tar.gz files Unicode-Map8-0.12/rfc1345.txt tar xfz /data/debian/pool/main/libu/libunicode-map8-perl/libunicode-map8-perl_0.12.orig.tar.gz Unicode-Map8-0.12/rfc1345.txt b993010eba4beceda855cc99244653ad - Unicode-Map8-0.12/rfc1345.txt f5ba3926d2925d6339bc1e429d9dfe34 - /home/jas/rfc/rfc1345.txt MISMATCH rfc1345.txt cmp: EOF on /home/jas/rfc/rfc1345.txt pkg liburi-perl ver 1.35-2 lastfile liburi-perl_1.35.orig.tar.gz files liburi-perl-1.35.orig/rfc2396.txt tar xfz /data/debian/pool/main/libu/liburi-perl/liburi-perl_1.35.orig.tar.gz liburi-perl-1.35.orig/rfc2396.txt f220ecfce7f18e502c117d3006597725 - liburi-perl-1.35.orig/rfc2396.txt f220ecfce7f18e502c117d3006597725 - /home/jas/rfc/rfc2396.txt MATCH rfc2396.txt pkg libuser ver 1:0.54.6-2.1.dfsg.1-1.1 lastfile libuser_0.54.6-2.1.dfsg.1.orig.tar.gz files libuser-0.54.6/docs/rfc2307.txt tar xfz /data/debian/pool/main/libu/libuser/libuser_0.54.6-2.1.dfsg.1.orig.tar.gz libuser-0.54.6/docs/rfc2307.txt 8794ca54a08d0ca9a66b18f5f2abd59b - libuser-0.54.6/docs/rfc2307.txt 8794ca54a08d0ca9a66b18f5f2abd59b - /home/jas/rfc/rfc2307.txt MATCH rfc2307.txt pkg libvorbis ver 1.1.2-1 lastfile libvorbis_1.1.2.orig.tar.gz files libvorbis-1.1.2/doc/draft-kerr-avt-vorbis-rtp-03.txt tar xfz /data/debian/pool/main/libv/libvorbis/libvorbis_1.1.2.orig.tar.gz libvorbis-1.1.2/doc/draft-kerr-avt-vorbis-rtp-03.txt 32619bd141ba84030007d5ab67f5541d - libvorbis-1.1.2/doc/draft-kerr-avt-vorbis-rtp-03.txt 32619bd141ba84030007d5ab67f5541d - /home/jas/rfc/draft-kerr-avt-vorbis-rtp-03.txt MATCH draft-kerr-avt-vorbis-rtp-03.txt pkg lprng ver 3.8.28-6 lastfile lprng_3.8.28.orig.tar.gz files LPRng-3.8.28/DOCS/rfc1179.txt LPRng-3.8.28/PrintingCookbook/source/rfc1179.txt tar xfz /data/debian/pool/main/l/lprng/lprng_3.8.28.orig.tar.gz LPRng-3.8.28/DOCS/rfc1179.txt 0459096c7711bc507e5ea3c0d01e32a2 - LPRng-3.8.28/DOCS/rfc1179.txt 0459096c7711bc507e5ea3c0d01e32a2 - /home/jas/rfc/rfc1179.txt MATCH rfc1179.txt tar xfz /data/debian/pool/main/l/lprng/lprng_3.8.28.orig.tar.gz LPRng-3.8.28/PrintingCookbook/source/rfc1179.txt 0459096c7711bc507e5ea3c0d01e32a2 - LPRng-3.8.28/PrintingCookbook/source/rfc1179.txt 0459096c7711bc507e5ea3c0d01e32a2 - /home/jas/rfc/rfc1179.txt MATCH rfc1179.txt pkg mailutils ver 1:1.0-1 lastfile mailutils_1.0.orig.tar.gz files mailutils-1.0/doc/rfc/rfc821.txt mailutils-1.0/doc/rfc/rfc822.txt mailutils-1.0/doc/rfc/rfc934.txt mailutils-1.0/doc/rfc/rfc1521.txt mailutils-1.0/doc/rfc/rfc1731.txt mailutils-1.0/doc/rfc/rfc1734.txt mailutils-1.0/doc/rfc/rfc1738.txt mailutils-1.0/doc/rfc/rfc1939.txt mailutils-1.0/doc/rfc/rfc1957.txt mailutils-1.0/doc/rfc/rfc2045.txt mailutils-1.0/doc/rfc/rfc2046.txt mailutils-1.0/doc/rfc/rfc2047.txt mailutils-1.0/doc/rfc/rfc2049.txt mailutils-1.0/doc/rfc/rfc2060.txt mailutils-1.0/doc/rfc/rfc2088.txt mailutils-1.0/doc/rfc/rfc2111.txt mailutils-1.0/doc/rfc/rfc2177.txt mailutils-1.0/doc/rfc/rfc2192.txt mailutils-1.0/doc/rfc/rfc2193.txt mailutils-1.0/doc/rfc/rfc2221.txt mailutils-1.0/doc/rfc/rfc2245.txt mailutils-1.0/doc/rfc/rfc2298.txt mailutils-1.0/doc/rfc/rfc2342.txt mailutils-1.0/doc/rfc/rfc2368.txt mailutils-1.0/doc/rfc/rfc2384.txt mailutils-1.0/doc/rfc/rfc2449.txt mailutils-1.0/doc/rfc/rfc2595.txt mailutils-1.0/doc/rfc/rfc2821.txt mailutils-1.0/doc/rfc/rfc2822.txt mailutils-1.0/doc/rfc/rfc3028.txt mailutils-1.0/doc/rfc/rfc3206.txt mailutils-1.0/doc/rfc/rfc3431.txt mailutils-1.0/doc/rfc/rfc3501.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc821.txt a23c27fac2732113aa8ad6df7dc50d7c - mailutils-1.0/doc/rfc/rfc821.txt a23c27fac2732113aa8ad6df7dc50d7c - /home/jas/rfc/rfc821.txt MATCH rfc821.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc822.txt 59975cc77db34020d4f62e69c6f53dcf - mailutils-1.0/doc/rfc/rfc822.txt 59975cc77db34020d4f62e69c6f53dcf - /home/jas/rfc/rfc822.txt MATCH rfc822.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc934.txt 10ca8e47dc94fa6eb429e36af403ca89 - mailutils-1.0/doc/rfc/rfc934.txt 7fcbfabeed626ea7742b83cd4aa030db - /home/jas/rfc/rfc934.txt MISMATCH rfc934.txt --- mailutils-1.0/doc/rfc/rfc934.txt 2005-11-29 11:33:15.000000000 +0100 +++ /home/jas/rfc/rfc934.txt 1992-09-23 21:43:49.000000000 +0200 @@ -568,4 +568,3 @@ Rose & Stefferud [Page 10] - mailutils-1.0/doc/rfc/rfc934.txt /home/jas/rfc/rfc934.txt differ: byte 2501, line 57 tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc1521.txt 9e113039b9548c75d447c0090e8bbeb2 - mailutils-1.0/doc/rfc/rfc1521.txt f00fc0063894acb505b600c36df12078 - /home/jas/rfc/rfc1521.txt MISMATCH rfc1521.txt mailutils-1.0/doc/rfc/rfc1521.txt /home/jas/rfc/rfc1521.txt differ: byte 2374, line 59 tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc1731.txt 82e7bb0077d0706b495ac512ea400bc1 - mailutils-1.0/doc/rfc/rfc1731.txt 82e7bb0077d0706b495ac512ea400bc1 - /home/jas/rfc/rfc1731.txt MATCH rfc1731.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc1734.txt 07f63d1c1c7dabc0a3c5657c7c4a4722 - mailutils-1.0/doc/rfc/rfc1734.txt 07f63d1c1c7dabc0a3c5657c7c4a4722 - /home/jas/rfc/rfc1734.txt MATCH rfc1734.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc1738.txt 23af7e64bc2add0626a1119028358804 - mailutils-1.0/doc/rfc/rfc1738.txt 23af7e64bc2add0626a1119028358804 - /home/jas/rfc/rfc1738.txt MATCH rfc1738.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc1939.txt 15ff19982bd41e884ce1b5675054ac22 - mailutils-1.0/doc/rfc/rfc1939.txt 15ff19982bd41e884ce1b5675054ac22 - /home/jas/rfc/rfc1939.txt MATCH rfc1939.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc1957.txt 57778adb9f93ed13881fb1b6e6eba5b1 - mailutils-1.0/doc/rfc/rfc1957.txt 57778adb9f93ed13881fb1b6e6eba5b1 - /home/jas/rfc/rfc1957.txt MATCH rfc1957.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2045.txt d61fb11bcd7b60142207209bcfa7f4b1 - mailutils-1.0/doc/rfc/rfc2045.txt d61fb11bcd7b60142207209bcfa7f4b1 - /home/jas/rfc/rfc2045.txt MATCH rfc2045.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2046.txt 6225c196e3c5a20155f3a2082aea2801 - mailutils-1.0/doc/rfc/rfc2046.txt 6225c196e3c5a20155f3a2082aea2801 - /home/jas/rfc/rfc2046.txt MATCH rfc2046.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2047.txt 068ac56e33a41f85b81177873cc0a581 - mailutils-1.0/doc/rfc/rfc2047.txt 068ac56e33a41f85b81177873cc0a581 - /home/jas/rfc/rfc2047.txt MATCH rfc2047.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2049.txt 2508a23f6ebcac9bc41b8a54c5852ae9 - mailutils-1.0/doc/rfc/rfc2049.txt 2508a23f6ebcac9bc41b8a54c5852ae9 - /home/jas/rfc/rfc2049.txt MATCH rfc2049.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2060.txt 77d6fe02acfefa3e9e4b57f4954a13af - mailutils-1.0/doc/rfc/rfc2060.txt 33c14a58e84b863682c318af9f62fc4a - /home/jas/rfc/rfc2060.txt MISMATCH rfc2060.txt --- mailutils-1.0/doc/rfc/rfc2060.txt 2005-05-17 14:22:50.000000000 +0200 +++ /home/jas/rfc/rfc2060.txt 1996-12-02 22:16:11.000000000 +0100 @@ -1646,7 +1646,7 @@ Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime S: A002 OK UNSUBSCRIBE completed -6.3.8. LIST Command +6.3..8. LIST Command Arguments: reference name mailbox name with possible wildcards mailutils-1.0/doc/rfc/rfc2060.txt /home/jas/rfc/rfc2060.txt differ: byte 67906, line 1649 tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2088.txt 396b3b410f45da9b98932fefb1f49da5 - mailutils-1.0/doc/rfc/rfc2088.txt 396b3b410f45da9b98932fefb1f49da5 - /home/jas/rfc/rfc2088.txt MATCH rfc2088.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2111.txt f7d0648d605ae901a48ca730e7cfe6b5 - mailutils-1.0/doc/rfc/rfc2111.txt f7d0648d605ae901a48ca730e7cfe6b5 - /home/jas/rfc/rfc2111.txt MATCH rfc2111.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2177.txt d8c7579e9ff15d2dd61275f1fc79da3e - mailutils-1.0/doc/rfc/rfc2177.txt dd8f2b9b4c2898334f41f8843f0f0efa - /home/jas/rfc/rfc2177.txt MISMATCH rfc2177.txt --- mailutils-1.0/doc/rfc/rfc2177.txt 2005-05-17 14:22:50.000000000 +0200 +++ /home/jas/rfc/rfc2177.txt 1997-07-01 00:44:29.000000000 +0200 @@ -1,103 +1,120 @@ - Network Working Group - Request for Comments: 2177 - Category: Standards Track - B. Leiba - IBM T.J. Watson Research Center - June 1997 - Page 1 + + + + +Network Working Group B. Leiba +Request for Comments: 2177 IBM T.J. Watson Research Center +Category: Standards Track June 1997 + IMAP4 IDLE command Status of this Memo - This document specifies an Internet standards track protocol - for the Internet community, and requests discussion and - suggestions for improvements. Please refer to the current - edition of the "Internet Official Protocol Standards" (STD 1) - for the standardization state and status of this protocol. - Distribution of this memo is unlimited. - - 1 Abstract - The Internet Message Access Protocol [IMAP4] requires a client - to poll the server for changes to the selected mailbox (new - mail, deletions). It's often more desirable to have the server - transmit updates to the client in real time. This allows a user - to see new mail immediately. It also helps some real-time - applications based on IMAP, which might otherwise need to poll - extremely often (such as every few seconds). (While the spec - actually does allow a server to push EXISTS responses - aysynchronously, a client can't expect this behaviour and must - poll.) - - This document specifies the syntax of an IDLE command, which - will allow a client to tell the server that it's ready to - accept such real-time updates. - - 2 Conventions Used in this Document - In examples, "C:" and "S:" indicate lines sent by the client - and server respectively. - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and - "MAY" in this document are to be interpreted as described in - RFC 2060 [IMAP4]. - 3 Specification + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The Internet Message Access Protocol [IMAP4] requires a client to + poll the server for changes to the selected mailbox (new mail, + deletions). It's often more desirable to have the server transmit + updates to the client in real time. This allows a user to see new + mail immediately. It also helps some real-time applications based on + IMAP, which might otherwise need to poll extremely often (such as + every few seconds). (While the spec actually does allow a server to + push EXISTS responses aysynchronously, a client can't expect this + behaviour and must poll.) + + This document specifies the syntax of an IDLE command, which will + allow a client to tell the server that it's ready to accept such + real-time updates. + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as described in RFC 2060 + [IMAP4]. + +3. Specification + IDLE Command Arguments: none - Responses: continuation data will be requested; the client - sends the continuation data "DONE" to end the command - __________________________________________________________ + Responses: continuation data will be requested; the client sends + the continuation data "DONE" to end the command + + + +Leiba Standards Track [Page 1] + +RFC 2177 IMAP4 IDLE command June 1997 + - Page 2 Result: OK - IDLE completed after client sent "DONE" NO - failure: the server will not allow the IDLE command at this time BAD - command unknown or arguments invalid - The IDLE command may be used with any IMAP4 server - implementation that returns "IDLE" as one of the supported - capabilities to the CAPABILITY command. If the server does not - advertise the IDLE capability, the client MUST NOT use the IDLE - command and must poll for mailbox updates. In particular, the - client MUST continue to be able to accept unsolicited untagged - responses to ANY command, as specified in the base IMAP - specification. + The IDLE command may be used with any IMAP4 server implementation + that returns "IDLE" as one of the supported capabilities to the + CAPABILITY command. If the server does not advertise the IDLE + capability, the client MUST NOT use the IDLE command and must poll + for mailbox updates. In particular, the client MUST continue to be + able to accept unsolicited untagged responses to ANY command, as + specified in the base IMAP specification. The IDLE command is sent from the client to the server when the - client is ready to accept unsolicited mailbox update messages. - The server requests a response to the IDLE command using the - continuation ("+") response. The IDLE command remains active - until the client responds to the continuation, and as long as - an IDLE command is active, the server is now free to send - untagged EXISTS, EXPUNGE, and other messages at any time. + client is ready to accept unsolicited mailbox update messages. The + server requests a response to the IDLE command using the continuation + ("+") response. The IDLE command remains active until the client + responds to the continuation, and as long as an IDLE command is + active, the server is now free to send untagged EXISTS, EXPUNGE, and + other messages at any time. The IDLE command is terminated by the receipt of a "DONE" - continuation from the client; such response satisfies the - server's continuation request. At that point, the server MAY - send any remaining queued untagged responses and then MUST - immediately send the tagged response to the IDLE command and - prepare to process other commands. As in the base - specification, the processing of any new command may cause the - sending of unsolicited untagged responses, subject to the - ambiguity limitations. The client MUST NOT send a command while - the server is waiting for the DONE, since the server will not - be able to distinguish a command from a continuation. - - The server MAY consider a client inactive if it has an IDLE - command running, and if such a server has an inactivity timeout - it MAY log the client off implicitly at the end of its timeout - period. Because of that, clients using IDLE are advised to - terminate the IDLE and re-issue it at least every 29 minutes to - avoid being logged off. This still allows a client to receive - immediate mailbox updates even though it need only "poll" at - half hour intervals. - __________________________________________________________ + continuation from the client; such response satisfies the server's + continuation request. At that point, the server MAY send any + remaining queued untagged responses and then MUST immediately send + the tagged response to the IDLE command and prepare to process other + commands. As in the base specification, the processing of any new + command may cause the sending of unsolicited untagged responses, + subject to the ambiguity limitations. The client MUST NOT send a + command while the server is waiting for the DONE, since the server + will not be able to distinguish a command from a continuation. + + The server MAY consider a client inactive if it has an IDLE command + running, and if such a server has an inactivity timeout it MAY log + the client off implicitly at the end of its timeout period. Because + of that, clients using IDLE are advised to terminate the IDLE and + re-issue it at least every 29 minutes to avoid being logged off. + This still allows a client to receive immediate mailbox updates even + though it need only "poll" at half hour intervals. + + + + + + + + + + + +Leiba Standards Track [Page 2] + +RFC 2177 IMAP4 IDLE command June 1997 - Page 3 Example: C: A001 SELECT INBOX S: * FLAGS (Deleted Seen) @@ -131,11 +148,12 @@ S: A005 OK FETCH completed C: A006 IDLE - 4 Formal Syntax - The following syntax specification uses the augmented - Backus-Naur Form (BNF) notation as specified in [RFC-822] as - modified by [IMAP4]. Non-terminals referenced but not defined - below are as defined by [IMAP4]. +4. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. + Non-terminals referenced but not defined below are as defined by + [IMAP4]. command_auth ::= append / create / delete / examine / list / lsub / rename / select / status / subscribe / unsubscribe @@ -143,22 +161,67 @@ ;; Valid only in Authenticated or Selected state idle ::= "IDLE" CRLF "DONE" - __________________________________________________________ - Page 4 - 5 References - [IMAP4] Crispin, M., "Internet Message Access Protocol - - Version 4rev1", RFC 2060, December 1996. - 6 Security Considerations + + + +Leiba Standards Track [Page 3] + +RFC 2177 IMAP4 IDLE command June 1997 + + +5. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + +6. Security Considerations + There are no known security issues with this extension. - 7 Author's Address +7. Author's Address + Barry Leiba IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10532 Email: leiba@watson.ibm.com - __________________________________________________________ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Leiba Standards Track [Page 4] + mailutils-1.0/doc/rfc/rfc2177.txt /home/jas/rfc/rfc2177.txt differ: byte 2, line 2 tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2192.txt 06a4f0eb97f0930b960dd5a42b4832bf - mailutils-1.0/doc/rfc/rfc2192.txt 06a4f0eb97f0930b960dd5a42b4832bf - /home/jas/rfc/rfc2192.txt MATCH rfc2192.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2193.txt 8c92ced2fd1b5bc16f753e303bf79d70 - mailutils-1.0/doc/rfc/rfc2193.txt 8c92ced2fd1b5bc16f753e303bf79d70 - /home/jas/rfc/rfc2193.txt MATCH rfc2193.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2221.txt 5e01beb9ec8c27d91c7c2b29b0cd91e2 - mailutils-1.0/doc/rfc/rfc2221.txt 5e01beb9ec8c27d91c7c2b29b0cd91e2 - /home/jas/rfc/rfc2221.txt MATCH rfc2221.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2245.txt a1ec4f21a9c79e64ccd5770f764d07e4 - mailutils-1.0/doc/rfc/rfc2245.txt a1ec4f21a9c79e64ccd5770f764d07e4 - /home/jas/rfc/rfc2245.txt MATCH rfc2245.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2298.txt 4ac7b91161e56c6068d0977bc5c1d3e0 - mailutils-1.0/doc/rfc/rfc2298.txt 4ac7b91161e56c6068d0977bc5c1d3e0 - /home/jas/rfc/rfc2298.txt MATCH rfc2298.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2342.txt 2f0f339458a114b666cee21fcfdf17e6 - mailutils-1.0/doc/rfc/rfc2342.txt 2f0f339458a114b666cee21fcfdf17e6 - /home/jas/rfc/rfc2342.txt MATCH rfc2342.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2368.txt 4ba1ead6dccda41d4bdb86b3e5de4e95 - mailutils-1.0/doc/rfc/rfc2368.txt 4ba1ead6dccda41d4bdb86b3e5de4e95 - /home/jas/rfc/rfc2368.txt MATCH rfc2368.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2384.txt 4a00a0703dfdea4268c6a37d3583b425 - mailutils-1.0/doc/rfc/rfc2384.txt 4a00a0703dfdea4268c6a37d3583b425 - /home/jas/rfc/rfc2384.txt MATCH rfc2384.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2449.txt 20e27be1834fe8c044ef4eeb77e886ab - mailutils-1.0/doc/rfc/rfc2449.txt 20e27be1834fe8c044ef4eeb77e886ab - /home/jas/rfc/rfc2449.txt MATCH rfc2449.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2595.txt 4ce96161b6a9155f912d043d69197334 - mailutils-1.0/doc/rfc/rfc2595.txt 4ce96161b6a9155f912d043d69197334 - /home/jas/rfc/rfc2595.txt MATCH rfc2595.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2821.txt ed347274feb0a1393f21e4f5bfb3f3ae - mailutils-1.0/doc/rfc/rfc2821.txt ed347274feb0a1393f21e4f5bfb3f3ae - /home/jas/rfc/rfc2821.txt MATCH rfc2821.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc2822.txt 97c538a7a2df52a8470781dcbd2d456c - mailutils-1.0/doc/rfc/rfc2822.txt 97c538a7a2df52a8470781dcbd2d456c - /home/jas/rfc/rfc2822.txt MATCH rfc2822.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc3028.txt fad4e041e4ce6c4e5ecf5cef169d4428 - mailutils-1.0/doc/rfc/rfc3028.txt fad4e041e4ce6c4e5ecf5cef169d4428 - /home/jas/rfc/rfc3028.txt MATCH rfc3028.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc3206.txt 8fbeefa40104ab9209485fb595808fa9 - mailutils-1.0/doc/rfc/rfc3206.txt 8fbeefa40104ab9209485fb595808fa9 - /home/jas/rfc/rfc3206.txt MATCH rfc3206.txt tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc3431.txt cfaf0258841e8733341973114e9832c0 - mailutils-1.0/doc/rfc/rfc3431.txt 430e81439bf8063fa37aab5736fd561c - /home/jas/rfc/rfc3431.txt MISMATCH rfc3431.txt --- mailutils-1.0/doc/rfc/rfc3431.txt 2005-05-17 14:22:50.000000000 +0200 +++ /home/jas/rfc/rfc3431.txt 2002-12-04 21:57:35.000000000 +0100 @@ -449,4 +449,3 @@ Segmuller Standards Track [Page 8] - mailutils-1.0/doc/rfc/rfc3431.txt /home/jas/rfc/rfc3431.txt differ: byte 2360, line 59 tar xfz /data/debian/pool/main/m/mailutils/mailutils_1.0.orig.tar.gz mailutils-1.0/doc/rfc/rfc3501.txt 65357196c9e7bd4e4a29e21a8b83e619 - mailutils-1.0/doc/rfc/rfc3501.txt f49bfc28b5980e6db512acc32febd7a3 - /home/jas/rfc/rfc3501.txt MISMATCH rfc3501.txt --- mailutils-1.0/doc/rfc/rfc3501.txt 2005-08-10 10:13:49.000000000 +0200 +++ /home/jas/rfc/rfc3501.txt 2003-03-17 22:10:09.000000000 +0100 @@ -6049,4 +6049,3 @@ Crispin Standards Track [Page 108] - mailutils-1.0/doc/rfc/rfc3501.txt /home/jas/rfc/rfc3501.txt differ: byte 1983, line 59 pkg maradns ver 1.2.12.02-1 lastfile maradns_1.2.12.02.orig.tar.gz files maradns-1.2.12.02/doc/en/misc/rfc/rfc1035.txt tar xfz /data/debian/pool/main/m/maradns/maradns_1.2.12.02.orig.tar.gz maradns-1.2.12.02/doc/en/misc/rfc/rfc1035.txt 85600131ad1cdecc84c31fbb0dffd6cf - maradns-1.2.12.02/doc/en/misc/rfc/rfc1035.txt 85600131ad1cdecc84c31fbb0dffd6cf - /home/jas/rfc/rfc1035.txt MATCH rfc1035.txt pkg mhash ver 0.9.7-1 lastfile mhash_0.9.7.orig.tar.gz files mhash-0.9.7.orig/doc/md5-rfc1321.txt tar xfz /data/debian/pool/main/m/mhash/mhash_0.9.7.orig.tar.gz mhash-0.9.7.orig/doc/md5-rfc1321.txt c6beb4140671d319f6433a3399cf6df2 - mhash-0.9.7.orig/doc/md5-rfc1321.txt c6beb4140671d319f6433a3399cf6df2 - /home/jas/rfc/md5-rfc1321.txt MATCH md5-rfc1321.txt pkg mobilemesh ver 1.0-6.1 lastfile mobilemesh_1.0.orig.tar.gz files mobilemesh-1.0.orig/InternetDrafts/draft-grace-manet-mmbdp-00.txt mobilemesh-1.0.orig/InternetDrafts/draft-grace-manet-mmldp-00.txt mobilemesh-1.0.orig/InternetDrafts/draft-grace-manet-mmrp-00.txt tar xfz /data/debian/pool/main/m/mobilemesh/mobilemesh_1.0.orig.tar.gz mobilemesh-1.0.orig/InternetDrafts/draft-grace-manet-mmbdp-00.txt f765cf07679ba24aab15a40aad5906f0 - mobilemesh-1.0.orig/InternetDrafts/draft-grace-manet-mmbdp-00.txt f765cf07679ba24aab15a40aad5906f0 - /home/jas/rfc/draft-grace-manet-mmbdp-00.txt MATCH draft-grace-manet-mmbdp-00.txt tar xfz /data/debian/pool/main/m/mobilemesh/mobilemesh_1.0.orig.tar.gz mobilemesh-1.0.orig/InternetDrafts/draft-grace-manet-mmldp-00.txt 206f9f169e0a7c7810fb2cdc9f94c7c7 - mobilemesh-1.0.orig/InternetDrafts/draft-grace-manet-mmldp-00.txt 206f9f169e0a7c7810fb2cdc9f94c7c7 - /home/jas/rfc/draft-grace-manet-mmldp-00.txt MATCH draft-grace-manet-mmldp-00.txt tar xfz /data/debian/pool/main/m/mobilemesh/mobilemesh_1.0.orig.tar.gz mobilemesh-1.0.orig/InternetDrafts/draft-grace-manet-mmrp-00.txt c1c95a6635d3984cdd2016e4fd1de9fd - mobilemesh-1.0.orig/InternetDrafts/draft-grace-manet-mmrp-00.txt c1c95a6635d3984cdd2016e4fd1de9fd - /home/jas/rfc/draft-grace-manet-mmrp-00.txt MATCH draft-grace-manet-mmrp-00.txt pkg mozart ver 1.3.2.20060615-2 lastfile mozart_1.3.2.20060615.orig.tar.gz files mozart-1.3.2.20060615/mozart/share/demo/DictClient/rfc2229.txt tar xfz /data/debian/pool/main/m/mozart/mozart_1.3.2.20060615.orig.tar.gz mozart-1.3.2.20060615/mozart/share/demo/DictClient/rfc2229.txt b6f6fe69fcc9b1c587f98886ab9640da - mozart-1.3.2.20060615/mozart/share/demo/DictClient/rfc2229.txt b6f6fe69fcc9b1c587f98886ab9640da - /home/jas/rfc/rfc2229.txt MATCH rfc2229.txt pkg namazu2 ver 2.0.16-8 lastfile namazu2_2.0.16.orig.tar.gz files namazu-2.0.16/tests/data/en/rfc0000.txt namazu-2.0.16/tests/data/ja/rfc0000.txt tar xfz /data/debian/pool/main/n/namazu2/namazu2_2.0.16.orig.tar.gz namazu-2.0.16/tests/data/en/rfc0000.txt b7cf648eced69a308f54afa99fb184aa - namazu-2.0.16/tests/data/en/rfc0000.txt ~/rfc /data/debian/bad/namazu2-2.0.16-8 --15:19:10-- http://bgp.potaroo.net/ietf/all-ids//rfc.txt => `rfc.txt' Resolving bgp.potaroo.net... 203.50.0.159 Connecting to bgp.potaroo.net|203.50.0.159|:80... connected. HTTP request sent, awaiting response... 404 Not Found 15:19:11 ERROR 404: Not Found. FETCH-FAIL rfc.txt /data/debian/bad/namazu2-2.0.16-8 d41d8cd98f00b204e9800998ecf8427e - /home/jas/rfc/rfc.txt MISMATCH rfc.txt diff: /home/jas/rfc/rfc.txt: No such file or directory cmp: /home/jas/rfc/rfc.txt: No such file or directory tar xfz /data/debian/pool/main/n/namazu2/namazu2_2.0.16.orig.tar.gz namazu-2.0.16/tests/data/ja/rfc0000.txt 902b612c21b068d1650aede02774b137 - namazu-2.0.16/tests/data/ja/rfc0000.txt ~/rfc /data/debian/bad/namazu2-2.0.16-8 --15:19:11-- http://bgp.potaroo.net/ietf/all-ids//rfc.txt => `rfc.txt' Resolving bgp.potaroo.net... 203.50.0.159 Connecting to bgp.potaroo.net|203.50.0.159|:80... connected. HTTP request sent, awaiting response... 404 Not Found 15:19:12 ERROR 404: Not Found. FETCH-FAIL rfc.txt /data/debian/bad/namazu2-2.0.16-8 d41d8cd98f00b204e9800998ecf8427e - /home/jas/rfc/rfc.txt MISMATCH rfc.txt diff: /home/jas/rfc/rfc.txt: No such file or directory cmp: /home/jas/rfc/rfc.txt: No such file or directory pkg nettle ver 1.14-1 lastfile nettle_1.14.orig.tar.gz files nettle-1.14.orig/testsuite/rfc1750.txt tar xfz /data/debian/pool/main/n/nettle/nettle_1.14.orig.tar.gz nettle-1.14.orig/testsuite/rfc1750.txt b7b57294f70ad60acc936f606365558c - nettle-1.14.orig/testsuite/rfc1750.txt b7b57294f70ad60acc936f606365558c - /home/jas/rfc/rfc1750.txt MATCH rfc1750.txt pkg openh323 ver 1.18.0-2 lastfile openh323_1.18.0.orig.tar.gz files openh323_Atlas_release/plugins/audio/iLBC/iLBC/draft-ietf-avt-ilbc-codec-05.txt tar xfz /data/debian/pool/main/o/openh323/openh323_1.18.0.orig.tar.gz openh323_Atlas_release/plugins/audio/iLBC/iLBC/draft-ietf-avt-ilbc-codec-05.txt 95d3934c25b2fdc545495ad9acc7be36 - openh323_Atlas_release/plugins/audio/iLBC/iLBC/draft-ietf-avt-ilbc-codec-05.txt 95d3934c25b2fdc545495ad9acc7be36 - /home/jas/rfc/draft-ietf-avt-ilbc-codec-05.txt MATCH draft-ietf-avt-ilbc-codec-05.txt pkg openldap2 ver 2.1.30-13 lastfile openldap2_2.1.30.orig.tar.gz files openldap-2.1.30/doc/rfc/rfc1274.txt openldap-2.1.30/doc/rfc/rfc2079.txt openldap-2.1.30/doc/rfc/rfc2247.txt openldap-2.1.30/doc/rfc/rfc2251.txt openldap-2.1.30/doc/rfc/rfc2252.txt openldap-2.1.30/doc/rfc/rfc2253.txt openldap-2.1.30/doc/rfc/rfc2254.txt openldap-2.1.30/doc/rfc/rfc2255.txt openldap-2.1.30/doc/rfc/rfc2256.txt openldap-2.1.30/doc/rfc/rfc2293.txt openldap-2.1.30/doc/rfc/rfc2294.txt openldap-2.1.30/doc/rfc/rfc2307.txt openldap-2.1.30/doc/rfc/rfc2377.txt openldap-2.1.30/doc/rfc/rfc2587.txt openldap-2.1.30/doc/rfc/rfc2589.txt openldap-2.1.30/doc/rfc/rfc2596.txt openldap-2.1.30/doc/rfc/rfc2649.txt openldap-2.1.30/doc/rfc/rfc2696.txt openldap-2.1.30/doc/rfc/rfc2713.txt openldap-2.1.30/doc/rfc/rfc2714.txt openldap-2.1.30/doc/rfc/rfc2798.txt openldap-2.1.30/doc/rfc/rfc2829.txt openldap-2.1.30/doc/rfc/rfc2830.txt openldap-2.1.30/doc/rfc/rfc2849.txt openldap-2.1.30/doc/rfc/rfc2891.txt openldap-2.1.30/doc/rfc/rfc3045.txt openldap-2.1.30/doc/rfc/rfc3062.txt openldap-2.1.30/doc/rfc/rfc3088.txt openldap-2.1.30/doc/rfc/rfc3112.txt openldap-2.1.30/doc/rfc/rfc3296.txt openldap-2.1.30/doc/rfc/rfc3377.txt openldap-2.1.30/doc/rfc/rfc3383.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc1274.txt 79a8a518d9b06cff5f67150e1fe7d572 - openldap-2.1.30/doc/rfc/rfc1274.txt 79a8a518d9b06cff5f67150e1fe7d572 - /home/jas/rfc/rfc1274.txt MATCH rfc1274.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2079.txt d788ffb0f8c21198086019a976d94bf4 - openldap-2.1.30/doc/rfc/rfc2079.txt d788ffb0f8c21198086019a976d94bf4 - /home/jas/rfc/rfc2079.txt MATCH rfc2079.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2247.txt a65282977549384d565dbc74b0b4b078 - openldap-2.1.30/doc/rfc/rfc2247.txt a65282977549384d565dbc74b0b4b078 - /home/jas/rfc/rfc2247.txt MATCH rfc2247.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2251.txt f03ec15d34a19e003d647e075719fa9d - openldap-2.1.30/doc/rfc/rfc2251.txt f03ec15d34a19e003d647e075719fa9d - /home/jas/rfc/rfc2251.txt MATCH rfc2251.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2252.txt c4421449d1c45201590939dce1e1fff2 - openldap-2.1.30/doc/rfc/rfc2252.txt b8a149468901d5cdac0e8191d868e37c - /home/jas/rfc/rfc2252.txt MISMATCH rfc2252.txt --- openldap-2.1.30/doc/rfc/rfc2252.txt 1998-10-28 02:02:11.000000000 +0100 +++ /home/jas/rfc/rfc2252.txt 1998-02-19 18:02:06.000000000 +0100 @@ -1027,12 +1027,12 @@ 6.11. DIT Content Rule Description + ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' ) - ues in this syntax are encoded according to the following BNF. - lementors should note that future versions of this document + Values in this syntax are encoded according to the following BNF. + Implementors should note that future versions of this document may have expanded this BNF to include additional terms. - 0 DITContentRuleDescription = "(" numericoid ; Structural ObjectClass identifier @@ -1045,9 +1045,8 @@ [ "NOT" oids ] ; AttributeType identifiers ")" - 0 2. Facsimile Telephone Number +6.12. Facsimile Telephone Number - 3 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' ) @@ -1063,6 +1062,7 @@ + Wahl, et. al. Standards Track [Page 19] RFC 2252 LADPv3 Attributes December 1997 openldap-2.1.30/doc/rfc/rfc2252.txt /home/jas/rfc/rfc2252.txt differ: byte 38740, line 1030 tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2253.txt a8e910b09b6b1b9056c92ff5430e517a - openldap-2.1.30/doc/rfc/rfc2253.txt a8e910b09b6b1b9056c92ff5430e517a - /home/jas/rfc/rfc2253.txt MATCH rfc2253.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2254.txt a2e1cab26eed6c987664138c472a17e8 - openldap-2.1.30/doc/rfc/rfc2254.txt a2e1cab26eed6c987664138c472a17e8 - /home/jas/rfc/rfc2254.txt MATCH rfc2254.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2255.txt 0d34310da8e8a3320cb6905d4d6b54d9 - openldap-2.1.30/doc/rfc/rfc2255.txt 0d34310da8e8a3320cb6905d4d6b54d9 - /home/jas/rfc/rfc2255.txt MATCH rfc2255.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2256.txt ecbd3d5cb5f28581a7b61ff4cd071672 - openldap-2.1.30/doc/rfc/rfc2256.txt ecbd3d5cb5f28581a7b61ff4cd071672 - /home/jas/rfc/rfc2256.txt MATCH rfc2256.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2293.txt 6e09ac4d40b62b0875dbf4e1a96eabc6 - openldap-2.1.30/doc/rfc/rfc2293.txt 6e09ac4d40b62b0875dbf4e1a96eabc6 - /home/jas/rfc/rfc2293.txt MATCH rfc2293.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2294.txt 287cf4d40c015dbe7a6cfd15bc6f3a2c - openldap-2.1.30/doc/rfc/rfc2294.txt 287cf4d40c015dbe7a6cfd15bc6f3a2c - /home/jas/rfc/rfc2294.txt MATCH rfc2294.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2307.txt 8794ca54a08d0ca9a66b18f5f2abd59b - openldap-2.1.30/doc/rfc/rfc2307.txt 8794ca54a08d0ca9a66b18f5f2abd59b - /home/jas/rfc/rfc2307.txt MATCH rfc2307.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2377.txt 12aef23bbac5eacdcd473614abf9a1d1 - openldap-2.1.30/doc/rfc/rfc2377.txt 12aef23bbac5eacdcd473614abf9a1d1 - /home/jas/rfc/rfc2377.txt MATCH rfc2377.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2587.txt 130f38d19b5113a9d4f9c7f5325737af - openldap-2.1.30/doc/rfc/rfc2587.txt 130f38d19b5113a9d4f9c7f5325737af - /home/jas/rfc/rfc2587.txt MATCH rfc2587.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2589.txt ad9bba4778de05583782711605166e63 - openldap-2.1.30/doc/rfc/rfc2589.txt ad9bba4778de05583782711605166e63 - /home/jas/rfc/rfc2589.txt MATCH rfc2589.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2596.txt b3a91fb7cbc3626aa569af8392cd0362 - openldap-2.1.30/doc/rfc/rfc2596.txt b3a91fb7cbc3626aa569af8392cd0362 - /home/jas/rfc/rfc2596.txt MATCH rfc2596.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2649.txt 69d6037fda5b431a4c7b927daa7d34e3 - openldap-2.1.30/doc/rfc/rfc2649.txt 69d6037fda5b431a4c7b927daa7d34e3 - /home/jas/rfc/rfc2649.txt MATCH rfc2649.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2696.txt 9b48d53198e061bbcc77c7eca020e79e - openldap-2.1.30/doc/rfc/rfc2696.txt 9b48d53198e061bbcc77c7eca020e79e - /home/jas/rfc/rfc2696.txt MATCH rfc2696.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2713.txt 47cd84c83121d7e86c08d2cb1c74fd28 - openldap-2.1.30/doc/rfc/rfc2713.txt 47cd84c83121d7e86c08d2cb1c74fd28 - /home/jas/rfc/rfc2713.txt MATCH rfc2713.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2714.txt 0ba21b33d106d600a98dd1195e07a64f - openldap-2.1.30/doc/rfc/rfc2714.txt 0ba21b33d106d600a98dd1195e07a64f - /home/jas/rfc/rfc2714.txt MATCH rfc2714.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2798.txt 3dbfd3b0b1e9b59f27d511745ead0aae - openldap-2.1.30/doc/rfc/rfc2798.txt 3dbfd3b0b1e9b59f27d511745ead0aae - /home/jas/rfc/rfc2798.txt MATCH rfc2798.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2829.txt 362f5c67bbcfe11d43be2f2ab8c39dc2 - openldap-2.1.30/doc/rfc/rfc2829.txt 362f5c67bbcfe11d43be2f2ab8c39dc2 - /home/jas/rfc/rfc2829.txt MATCH rfc2829.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2830.txt e84837930c295630133fa1c02a21028d - openldap-2.1.30/doc/rfc/rfc2830.txt e84837930c295630133fa1c02a21028d - /home/jas/rfc/rfc2830.txt MATCH rfc2830.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2849.txt 060db71dc80184d3506487e1dd4c8e6a - openldap-2.1.30/doc/rfc/rfc2849.txt 060db71dc80184d3506487e1dd4c8e6a - /home/jas/rfc/rfc2849.txt MATCH rfc2849.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc2891.txt 86230a78c7a4e495035c377d2266bd6e - openldap-2.1.30/doc/rfc/rfc2891.txt 86230a78c7a4e495035c377d2266bd6e - /home/jas/rfc/rfc2891.txt MATCH rfc2891.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc3045.txt 8323d10ede94235f9ebb96bc10ffa139 - openldap-2.1.30/doc/rfc/rfc3045.txt 8323d10ede94235f9ebb96bc10ffa139 - /home/jas/rfc/rfc3045.txt MATCH rfc3045.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc3062.txt 1f0ca2797433f6a4410cfe08990ff590 - openldap-2.1.30/doc/rfc/rfc3062.txt 1f0ca2797433f6a4410cfe08990ff590 - /home/jas/rfc/rfc3062.txt MATCH rfc3062.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc3088.txt 1f0d7801b5795eb37f0ddda42f8bf2fd - openldap-2.1.30/doc/rfc/rfc3088.txt 1f0d7801b5795eb37f0ddda42f8bf2fd - /home/jas/rfc/rfc3088.txt MATCH rfc3088.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc3112.txt e8d4884bf7476a0fd0cb2b1a16476d6c - openldap-2.1.30/doc/rfc/rfc3112.txt e8d4884bf7476a0fd0cb2b1a16476d6c - /home/jas/rfc/rfc3112.txt MATCH rfc3112.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc3296.txt aa51336364fcd4712c09aefb8287cb47 - openldap-2.1.30/doc/rfc/rfc3296.txt aa51336364fcd4712c09aefb8287cb47 - /home/jas/rfc/rfc3296.txt MATCH rfc3296.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc3377.txt 903b0b127a36c8dcd3e06ec409a53c54 - openldap-2.1.30/doc/rfc/rfc3377.txt 903b0b127a36c8dcd3e06ec409a53c54 - /home/jas/rfc/rfc3377.txt MATCH rfc3377.txt tar xfz /data/debian/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz openldap-2.1.30/doc/rfc/rfc3383.txt 5a3ee955fb6b27d60b3304ac42e4848f - openldap-2.1.30/doc/rfc/rfc3383.txt 5a3ee955fb6b27d60b3304ac42e4848f - /home/jas/rfc/rfc3383.txt MATCH rfc3383.txt pkg openldap2.3 ver 2.3.25-1 lastfile openldap2.3_2.3.25.orig.tar.gz files openldap-2.3.25/doc/rfc/rfc1274.txt openldap-2.3.25/doc/rfc/rfc2079.txt openldap-2.3.25/doc/rfc/rfc2247.txt openldap-2.3.25/doc/rfc/rfc2251.txt openldap-2.3.25/doc/rfc/rfc2252.txt openldap-2.3.25/doc/rfc/rfc2253.txt openldap-2.3.25/doc/rfc/rfc2254.txt openldap-2.3.25/doc/rfc/rfc2255.txt openldap-2.3.25/doc/rfc/rfc2256.txt openldap-2.3.25/doc/rfc/rfc2293.txt openldap-2.3.25/doc/rfc/rfc2294.txt openldap-2.3.25/doc/rfc/rfc2307.txt openldap-2.3.25/doc/rfc/rfc2377.txt openldap-2.3.25/doc/rfc/rfc2587.txt openldap-2.3.25/doc/rfc/rfc2589.txt openldap-2.3.25/doc/rfc/rfc2649.txt openldap-2.3.25/doc/rfc/rfc2696.txt openldap-2.3.25/doc/rfc/rfc2713.txt openldap-2.3.25/doc/rfc/rfc2714.txt openldap-2.3.25/doc/rfc/rfc2798.txt openldap-2.3.25/doc/rfc/rfc2829.txt openldap-2.3.25/doc/rfc/rfc2830.txt openldap-2.3.25/doc/rfc/rfc2849.txt openldap-2.3.25/doc/rfc/rfc2891.txt openldap-2.3.25/doc/rfc/rfc2926.txt openldap-2.3.25/doc/rfc/rfc3045.txt openldap-2.3.25/doc/rfc/rfc3062.txt openldap-2.3.25/doc/rfc/rfc3088.txt openldap-2.3.25/doc/rfc/rfc3112.txt openldap-2.3.25/doc/rfc/rfc3296.txt openldap-2.3.25/doc/rfc/rfc3377.txt openldap-2.3.25/doc/rfc/rfc3383.txt openldap-2.3.25/doc/rfc/rfc3663.txt openldap-2.3.25/doc/rfc/rfc3671.txt openldap-2.3.25/doc/rfc/rfc3672.txt openldap-2.3.25/doc/rfc/rfc3673.txt openldap-2.3.25/doc/rfc/rfc3674.txt openldap-2.3.25/doc/rfc/rfc3687.txt openldap-2.3.25/doc/rfc/rfc3698.txt openldap-2.3.25/doc/rfc/rfc3703.txt openldap-2.3.25/doc/rfc/rfc3712.txt openldap-2.3.25/doc/rfc/rfc3727.txt openldap-2.3.25/doc/rfc/rfc3771.txt openldap-2.3.25/doc/rfc/rfc3829.txt openldap-2.3.25/doc/rfc/rfc3866.txt openldap-2.3.25/doc/rfc/rfc3876.txt openldap-2.3.25/doc/rfc/rfc3909.txt openldap-2.3.25/doc/rfc/rfc3928.txt openldap-2.3.25/doc/rfc/rfc4013.txt openldap-2.3.25/doc/rfc/rfc4370.txt openldap-2.3.25/doc/rfc/rfc4373.txt openldap-2.3.25/doc/rfc/rfc4403.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc1274.txt 79a8a518d9b06cff5f67150e1fe7d572 - openldap-2.3.25/doc/rfc/rfc1274.txt 79a8a518d9b06cff5f67150e1fe7d572 - /home/jas/rfc/rfc1274.txt MATCH rfc1274.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2079.txt d788ffb0f8c21198086019a976d94bf4 - openldap-2.3.25/doc/rfc/rfc2079.txt d788ffb0f8c21198086019a976d94bf4 - /home/jas/rfc/rfc2079.txt MATCH rfc2079.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2247.txt a65282977549384d565dbc74b0b4b078 - openldap-2.3.25/doc/rfc/rfc2247.txt a65282977549384d565dbc74b0b4b078 - /home/jas/rfc/rfc2247.txt MATCH rfc2247.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2251.txt f03ec15d34a19e003d647e075719fa9d - openldap-2.3.25/doc/rfc/rfc2251.txt f03ec15d34a19e003d647e075719fa9d - /home/jas/rfc/rfc2251.txt MATCH rfc2251.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2252.txt c4421449d1c45201590939dce1e1fff2 - openldap-2.3.25/doc/rfc/rfc2252.txt b8a149468901d5cdac0e8191d868e37c - /home/jas/rfc/rfc2252.txt MISMATCH rfc2252.txt --- openldap-2.3.25/doc/rfc/rfc2252.txt 1998-10-28 02:02:11.000000000 +0100 +++ /home/jas/rfc/rfc2252.txt 1998-02-19 18:02:06.000000000 +0100 @@ -1027,12 +1027,12 @@ 6.11. DIT Content Rule Description + ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' ) - ues in this syntax are encoded according to the following BNF. - lementors should note that future versions of this document + Values in this syntax are encoded according to the following BNF. + Implementors should note that future versions of this document may have expanded this BNF to include additional terms. - 0 DITContentRuleDescription = "(" numericoid ; Structural ObjectClass identifier @@ -1045,9 +1045,8 @@ [ "NOT" oids ] ; AttributeType identifiers ")" - 0 2. Facsimile Telephone Number +6.12. Facsimile Telephone Number - 3 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' ) @@ -1063,6 +1062,7 @@ + Wahl, et. al. Standards Track [Page 19] RFC 2252 LADPv3 Attributes December 1997 openldap-2.3.25/doc/rfc/rfc2252.txt /home/jas/rfc/rfc2252.txt differ: byte 38740, line 1030 tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2253.txt a8e910b09b6b1b9056c92ff5430e517a - openldap-2.3.25/doc/rfc/rfc2253.txt a8e910b09b6b1b9056c92ff5430e517a - /home/jas/rfc/rfc2253.txt MATCH rfc2253.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2254.txt a2e1cab26eed6c987664138c472a17e8 - openldap-2.3.25/doc/rfc/rfc2254.txt a2e1cab26eed6c987664138c472a17e8 - /home/jas/rfc/rfc2254.txt MATCH rfc2254.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2255.txt 0d34310da8e8a3320cb6905d4d6b54d9 - openldap-2.3.25/doc/rfc/rfc2255.txt 0d34310da8e8a3320cb6905d4d6b54d9 - /home/jas/rfc/rfc2255.txt MATCH rfc2255.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2256.txt ecbd3d5cb5f28581a7b61ff4cd071672 - openldap-2.3.25/doc/rfc/rfc2256.txt ecbd3d5cb5f28581a7b61ff4cd071672 - /home/jas/rfc/rfc2256.txt MATCH rfc2256.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2293.txt 6e09ac4d40b62b0875dbf4e1a96eabc6 - openldap-2.3.25/doc/rfc/rfc2293.txt 6e09ac4d40b62b0875dbf4e1a96eabc6 - /home/jas/rfc/rfc2293.txt MATCH rfc2293.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2294.txt 287cf4d40c015dbe7a6cfd15bc6f3a2c - openldap-2.3.25/doc/rfc/rfc2294.txt 287cf4d40c015dbe7a6cfd15bc6f3a2c - /home/jas/rfc/rfc2294.txt MATCH rfc2294.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2307.txt 8794ca54a08d0ca9a66b18f5f2abd59b - openldap-2.3.25/doc/rfc/rfc2307.txt 8794ca54a08d0ca9a66b18f5f2abd59b - /home/jas/rfc/rfc2307.txt MATCH rfc2307.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2377.txt 12aef23bbac5eacdcd473614abf9a1d1 - openldap-2.3.25/doc/rfc/rfc2377.txt 12aef23bbac5eacdcd473614abf9a1d1 - /home/jas/rfc/rfc2377.txt MATCH rfc2377.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2587.txt 130f38d19b5113a9d4f9c7f5325737af - openldap-2.3.25/doc/rfc/rfc2587.txt 130f38d19b5113a9d4f9c7f5325737af - /home/jas/rfc/rfc2587.txt MATCH rfc2587.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2589.txt ad9bba4778de05583782711605166e63 - openldap-2.3.25/doc/rfc/rfc2589.txt ad9bba4778de05583782711605166e63 - /home/jas/rfc/rfc2589.txt MATCH rfc2589.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2649.txt 69d6037fda5b431a4c7b927daa7d34e3 - openldap-2.3.25/doc/rfc/rfc2649.txt 69d6037fda5b431a4c7b927daa7d34e3 - /home/jas/rfc/rfc2649.txt MATCH rfc2649.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2696.txt 9b48d53198e061bbcc77c7eca020e79e - openldap-2.3.25/doc/rfc/rfc2696.txt 9b48d53198e061bbcc77c7eca020e79e - /home/jas/rfc/rfc2696.txt MATCH rfc2696.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2713.txt 47cd84c83121d7e86c08d2cb1c74fd28 - openldap-2.3.25/doc/rfc/rfc2713.txt 47cd84c83121d7e86c08d2cb1c74fd28 - /home/jas/rfc/rfc2713.txt MATCH rfc2713.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2714.txt 0ba21b33d106d600a98dd1195e07a64f - openldap-2.3.25/doc/rfc/rfc2714.txt 0ba21b33d106d600a98dd1195e07a64f - /home/jas/rfc/rfc2714.txt MATCH rfc2714.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2798.txt 3dbfd3b0b1e9b59f27d511745ead0aae - openldap-2.3.25/doc/rfc/rfc2798.txt 3dbfd3b0b1e9b59f27d511745ead0aae - /home/jas/rfc/rfc2798.txt MATCH rfc2798.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2829.txt 362f5c67bbcfe11d43be2f2ab8c39dc2 - openldap-2.3.25/doc/rfc/rfc2829.txt 362f5c67bbcfe11d43be2f2ab8c39dc2 - /home/jas/rfc/rfc2829.txt MATCH rfc2829.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2830.txt e84837930c295630133fa1c02a21028d - openldap-2.3.25/doc/rfc/rfc2830.txt e84837930c295630133fa1c02a21028d - /home/jas/rfc/rfc2830.txt MATCH rfc2830.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2849.txt 060db71dc80184d3506487e1dd4c8e6a - openldap-2.3.25/doc/rfc/rfc2849.txt 060db71dc80184d3506487e1dd4c8e6a - /home/jas/rfc/rfc2849.txt MATCH rfc2849.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2891.txt 86230a78c7a4e495035c377d2266bd6e - openldap-2.3.25/doc/rfc/rfc2891.txt 86230a78c7a4e495035c377d2266bd6e - /home/jas/rfc/rfc2891.txt MATCH rfc2891.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc2926.txt 2749d0b81d697dac58954fac0f948260 - openldap-2.3.25/doc/rfc/rfc2926.txt 2749d0b81d697dac58954fac0f948260 - /home/jas/rfc/rfc2926.txt MATCH rfc2926.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3045.txt 8323d10ede94235f9ebb96bc10ffa139 - openldap-2.3.25/doc/rfc/rfc3045.txt 8323d10ede94235f9ebb96bc10ffa139 - /home/jas/rfc/rfc3045.txt MATCH rfc3045.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3062.txt 1f0ca2797433f6a4410cfe08990ff590 - openldap-2.3.25/doc/rfc/rfc3062.txt 1f0ca2797433f6a4410cfe08990ff590 - /home/jas/rfc/rfc3062.txt MATCH rfc3062.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3088.txt 1f0d7801b5795eb37f0ddda42f8bf2fd - openldap-2.3.25/doc/rfc/rfc3088.txt 1f0d7801b5795eb37f0ddda42f8bf2fd - /home/jas/rfc/rfc3088.txt MATCH rfc3088.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3112.txt e8d4884bf7476a0fd0cb2b1a16476d6c - openldap-2.3.25/doc/rfc/rfc3112.txt e8d4884bf7476a0fd0cb2b1a16476d6c - /home/jas/rfc/rfc3112.txt MATCH rfc3112.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3296.txt aa51336364fcd4712c09aefb8287cb47 - openldap-2.3.25/doc/rfc/rfc3296.txt aa51336364fcd4712c09aefb8287cb47 - /home/jas/rfc/rfc3296.txt MATCH rfc3296.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3377.txt 903b0b127a36c8dcd3e06ec409a53c54 - openldap-2.3.25/doc/rfc/rfc3377.txt 903b0b127a36c8dcd3e06ec409a53c54 - /home/jas/rfc/rfc3377.txt MATCH rfc3377.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3383.txt 5a3ee955fb6b27d60b3304ac42e4848f - openldap-2.3.25/doc/rfc/rfc3383.txt 5a3ee955fb6b27d60b3304ac42e4848f - /home/jas/rfc/rfc3383.txt MATCH rfc3383.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3663.txt b065e27b2c82fec09ca88326ac7438aa - openldap-2.3.25/doc/rfc/rfc3663.txt b065e27b2c82fec09ca88326ac7438aa - /home/jas/rfc/rfc3663.txt MATCH rfc3663.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3671.txt 4b169a809cf38e5e8df50557bffdfc71 - openldap-2.3.25/doc/rfc/rfc3671.txt 4b169a809cf38e5e8df50557bffdfc71 - /home/jas/rfc/rfc3671.txt MATCH rfc3671.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3672.txt 95fb1adf6f565de1cc68c0d798923c42 - openldap-2.3.25/doc/rfc/rfc3672.txt 95fb1adf6f565de1cc68c0d798923c42 - /home/jas/rfc/rfc3672.txt MATCH rfc3672.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3673.txt ba1b18bc4cfd258efd49b5a4a99e2182 - openldap-2.3.25/doc/rfc/rfc3673.txt ba1b18bc4cfd258efd49b5a4a99e2182 - /home/jas/rfc/rfc3673.txt MATCH rfc3673.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3674.txt aaecff9dd7a11885012b92650ef9474a - openldap-2.3.25/doc/rfc/rfc3674.txt aaecff9dd7a11885012b92650ef9474a - /home/jas/rfc/rfc3674.txt MATCH rfc3674.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3687.txt 313103615520168a0281cd3475ecc820 - openldap-2.3.25/doc/rfc/rfc3687.txt 313103615520168a0281cd3475ecc820 - /home/jas/rfc/rfc3687.txt MATCH rfc3687.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3698.txt 66ddc9db48f1f9b9e7d62cb260a7ef0b - openldap-2.3.25/doc/rfc/rfc3698.txt 66ddc9db48f1f9b9e7d62cb260a7ef0b - /home/jas/rfc/rfc3698.txt MATCH rfc3698.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3703.txt 087c62ce03de0e13467f5e20a9cb1306 - openldap-2.3.25/doc/rfc/rfc3703.txt 087c62ce03de0e13467f5e20a9cb1306 - /home/jas/rfc/rfc3703.txt MATCH rfc3703.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3712.txt c43f361c00c268046bfb44d29a80309e - openldap-2.3.25/doc/rfc/rfc3712.txt c43f361c00c268046bfb44d29a80309e - /home/jas/rfc/rfc3712.txt MATCH rfc3712.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3727.txt 5f67b5b37eeb88b40ac092d0fc34622f - openldap-2.3.25/doc/rfc/rfc3727.txt 5f67b5b37eeb88b40ac092d0fc34622f - /home/jas/rfc/rfc3727.txt MATCH rfc3727.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3771.txt 9bc58ff53307d27fe4239aef75749123 - openldap-2.3.25/doc/rfc/rfc3771.txt 9bc58ff53307d27fe4239aef75749123 - /home/jas/rfc/rfc3771.txt MATCH rfc3771.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3829.txt bae79e387833b006b464c721db0a3fd3 - openldap-2.3.25/doc/rfc/rfc3829.txt bae79e387833b006b464c721db0a3fd3 - /home/jas/rfc/rfc3829.txt MATCH rfc3829.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3866.txt 85043b77ecd823e5fc8543d8979641e9 - openldap-2.3.25/doc/rfc/rfc3866.txt 85043b77ecd823e5fc8543d8979641e9 - /home/jas/rfc/rfc3866.txt MATCH rfc3866.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3876.txt 1c30578f758f56dba738ab23b0bdeae5 - openldap-2.3.25/doc/rfc/rfc3876.txt 1c30578f758f56dba738ab23b0bdeae5 - /home/jas/rfc/rfc3876.txt MATCH rfc3876.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3909.txt 2a3e50e149ccf4443801fdeca30c2131 - openldap-2.3.25/doc/rfc/rfc3909.txt 2a3e50e149ccf4443801fdeca30c2131 - /home/jas/rfc/rfc3909.txt MATCH rfc3909.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc3928.txt 59d2c713afa3be37f0d15887bea6f756 - openldap-2.3.25/doc/rfc/rfc3928.txt 59d2c713afa3be37f0d15887bea6f756 - /home/jas/rfc/rfc3928.txt MATCH rfc3928.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc4013.txt e50c34280f97813ff9e51084bea5adc3 - openldap-2.3.25/doc/rfc/rfc4013.txt e50c34280f97813ff9e51084bea5adc3 - /home/jas/rfc/rfc4013.txt MATCH rfc4013.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc4370.txt a3d2403ad91687268b3d54ceb2ece785 - openldap-2.3.25/doc/rfc/rfc4370.txt a3d2403ad91687268b3d54ceb2ece785 - /home/jas/rfc/rfc4370.txt MATCH rfc4370.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc4373.txt 90f1fc786227f820bd79c5fde89ffe29 - openldap-2.3.25/doc/rfc/rfc4373.txt 90f1fc786227f820bd79c5fde89ffe29 - /home/jas/rfc/rfc4373.txt MATCH rfc4373.txt tar xfz /data/debian/pool/main/o/openldap2.3/openldap2.3_2.3.25.orig.tar.gz openldap-2.3.25/doc/rfc/rfc4403.txt 912e6d12f27497aa3df5e33cf4211899 - openldap-2.3.25/doc/rfc/rfc4403.txt 912e6d12f27497aa3df5e33cf4211899 - /home/jas/rfc/rfc4403.txt MATCH rfc4403.txt pkg openslp ver 1.2.1-6 lastfile openslp_1.2.1.orig.tar.gz files openslp-1.2.1/doc/rfc/rfc1766.txt openslp-1.2.1/doc/rfc/rfc2396.txt openslp-1.2.1/doc/rfc/rfc2608.txt openslp-1.2.1/doc/rfc/rfc2609.txt openslp-1.2.1/doc/rfc/rfc2610.txt openslp-1.2.1/doc/rfc/rfc2614.txt openslp-1.2.1/doc/rfc/rfc2165.txt openslp-1.2.1/doc/rfc/rfc2254.txt tar xfz /data/debian/pool/main/o/openslp/openslp_1.2.1.orig.tar.gz openslp-1.2.1/doc/rfc/rfc1766.txt f7f82b7929af859fdadc9f7378cc52e0 - openslp-1.2.1/doc/rfc/rfc1766.txt aee0cd46abfd357368e2719a6451e458 - /home/jas/rfc/rfc1766.txt MISMATCH rfc1766.txt --- openslp-1.2.1/doc/rfc/rfc1766.txt 2000-04-15 00:49:17.000000000 +0200 +++ /home/jas/rfc/rfc1766.txt 1995-03-01 22:27:06.000000000 +0100 @@ -1,3 +1,9 @@ + + + + + + Network Working Group H. Alvestrand Request for Comments: 1766 UNINETT Category: Standards Track March 1995 @@ -51,7 +57,6 @@ Alvestrand [Page 1] - RFC 1766 Language Tag March 1995 @@ -108,7 +113,6 @@ Alvestrand [Page 2] - RFC 1766 Language Tag March 1995 @@ -165,7 +169,6 @@ Alvestrand [Page 3] - RFC 1766 Language Tag March 1995 @@ -222,7 +225,6 @@ Alvestrand [Page 4] - RFC 1766 Language Tag March 1995 @@ -279,7 +281,6 @@ Alvestrand [Page 5] - RFC 1766 Language Tag March 1995 @@ -336,7 +337,6 @@ Alvestrand [Page 6] - RFC 1766 Language Tag March 1995 @@ -393,7 +393,6 @@ Alvestrand [Page 7] - RFC 1766 Language Tag March 1995 @@ -450,7 +449,6 @@ Alvestrand [Page 8] - RFC 1766 Language Tag March 1995 @@ -507,4 +505,3 @@ Alvestrand [Page 9] - openslp-1.2.1/doc/rfc/rfc1766.txt /home/jas/rfc/rfc1766.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/o/openslp/openslp_1.2.1.orig.tar.gz openslp-1.2.1/doc/rfc/rfc2396.txt 7f0675699b50b1c4b823c69a735bc2ff - openslp-1.2.1/doc/rfc/rfc2396.txt f220ecfce7f18e502c117d3006597725 - /home/jas/rfc/rfc2396.txt MISMATCH rfc2396.txt --- openslp-1.2.1/doc/rfc/rfc2396.txt 2000-04-15 00:49:19.000000000 +0200 +++ /home/jas/rfc/rfc2396.txt 1998-08-18 22:19:11.000000000 +0200 @@ -5,7 +5,7 @@ Network Working Group T. Berners-Lee -Request for Comments: 2396 MIT/LC +Request for Comments: 2396 MIT/LCS Updates: 1808, 1738 R. Fielding Category: Standards Track U.C. Irvine L. Masinter @@ -29,13 +29,13 @@ IESG Note - This paper describes some kind of "superset" of all functions and - methods that can be applied to URIs. It consists of both a grammar - and a description of basic functionality for URIs. To understand what - is a valid URI, both the grammar and the apropriate description have - to be studied. Also, some functions and methods described only works - in some URI schemes, and some only with certain content types (i.e. - regardless of scheme used). + This paper describes a "superset" of operations that can be applied + to URI. It consists of both a grammar and a description of basic + functionality for URI. To understand what is a valid URI, both the + grammar and the associated description have to be studied. Some of + the functionality described is not applicable to all URI schemes, and + some operations are only possible when certain media types are + retrieved using the URI, regardless of the scheme used. Abstract @@ -1138,8 +1138,9 @@ the reference is an absolute-path and we skip to step 7. 6) If this step is reached, then we are resolving a relative-path - reference. URI's path. Although there are many ways to do this, - we will describe a simple method using a separate string buffer. + reference. The relative path needs to be merged with the base + URI's path. Although there are many ways to do this, we will + describe a simple method using a separate string buffer. a) All but the last segment of the base URI's path component is copied to the buffer. In other words, any characters after the @@ -1174,7 +1175,6 @@ - Berners-Lee, et. al. Standards Track [Page 21] RFC 2396 URI Generic Syntax August 1998 @@ -1640,6 +1640,7 @@ g:h = g:h g = http://a/b/c/g + ./g = http://a/b/c/g g/ = http://a/b/c/g/ /g = http://a/g //g = http://g @@ -1651,6 +1652,14 @@ ;x = http://a/b/c/;x g;x = http://a/b/c/g;x g;x?y#s = http://a/b/c/g;x?y#s + . = http://a/b/c/ + ./ = http://a/b/c/ + .. = http://a/b/ + ../ = http://a/b/ + ../g = http://a/b/g + ../.. = http://a/ + ../../ = http://a/ + ../../g = http://a/g C.2. Abnormal Examples @@ -1668,6 +1677,16 @@ the authority component of a URI. + + +Berners-Lee, et. al. Standards Track [Page 30] + +RFC 2396 URI Generic Syntax August 1998 + + + ../../../g = http://a/../g + ../../../../g = http://a/../../g + In practice, some implementations strip leading relative symbolic elements (".", "..") after applying a relative URI calculation, based on the theory that compensating for obvious author errors is better @@ -1677,21 +1696,18 @@ Similarly, parsers must avoid treating "." and ".." as special when they are not complete components of a relative path. - - -Berners-Lee, et. al. Standards Track [Page 30] - -RFC 2396 URI Generic Syntax August 1998 - - /./g = http://a/./g /../g = http://a/../g g. = http://a/b/c/g. + .g = http://a/b/c/.g g.. = http://a/b/c/g.. + ..g = http://a/b/c/..g Less likely are cases where the relative URI uses unnecessary or nonsensical forms of the "." and ".." complete path segments. + ./../g = http://a/b/g + ./g/. = http://a/b/c/g/ g/./h = http://a/b/c/g/h g/../h = http://a/b/c/h g;x=1/./y = http://a/b/c/g;x=1/y @@ -1710,6 +1726,20 @@ g#s/./x = http://a/b/c/g#s/./x g#s/../x = http://a/b/c/g#s/../x + + + + + + + + + +Berners-Lee, et. al. Standards Track [Page 31] + +RFC 2396 URI Generic Syntax August 1998 + + Some parsers allow the scheme name to be present in a relative URI if it is the same as the base URI scheme. This is considered to be a loophole in prior specifications of partial URI [RFC1630]. Its use @@ -1735,7 +1765,33 @@ -Berners-Lee, et. al. Standards Track [Page 31] + + + + + + + + + + + + + + + + + + + + + + + + + + +Berners-Lee, et. al. Standards Track [Page 32] RFC 2396 URI Generic Syntax August 1998 @@ -1761,6 +1817,7 @@ An example HTML document + ... a hypertext anchor ... A parser reading the example document should interpret the given @@ -1790,8 +1847,7 @@ - -Berners-Lee, et. al. Standards Track [Page 32] +Berners-Lee, et. al. Standards Track [Page 33] RFC 2396 URI Generic Syntax August 1998 @@ -1841,17 +1897,20 @@ For example, the text: - Yes, Jim, I found it under "http://www.w3.org/Addressing/", but - you can probably pick it up from . - Note the warning in . Note the warning in . contains the URI references @@ -1900,10 +1959,7 @@ - - - -Berners-Lee, et. al. Standards Track [Page 34] +Berners-Lee, et. al. Standards Track [Page 35] RFC 2396 URI Generic Syntax August 1998 @@ -1959,7 +2015,7 @@ -Berners-Lee, et. al. Standards Track [Page 35] +Berners-Lee, et. al. Standards Track [Page 36] RFC 2396 URI Generic Syntax August 1998 @@ -2015,7 +2071,7 @@ -Berners-Lee, et. al. Standards Track [Page 36] +Berners-Lee, et. al. Standards Track [Page 37] RFC 2396 URI Generic Syntax August 1998 @@ -2071,7 +2127,7 @@ -Berners-Lee, et. al. Standards Track [Page 37] +Berners-Lee, et. al. Standards Track [Page 38] RFC 2396 URI Generic Syntax August 1998 @@ -2127,7 +2183,7 @@ -Berners-Lee, et. al. Standards Track [Page 38] +Berners-Lee, et. al. Standards Track [Page 39] RFC 2396 URI Generic Syntax August 1998 @@ -2183,5 +2239,5 @@ -Berners-Lee, et. al. Standards Track [Page 39] +Berners-Lee, et. al. Standards Track [Page 40] openslp-1.2.1/doc/rfc/rfc2396.txt /home/jas/rfc/rfc2396.txt differ: byte 145, line 8 tar xfz /data/debian/pool/main/o/openslp/openslp_1.2.1.orig.tar.gz openslp-1.2.1/doc/rfc/rfc2608.txt a41afa62d462a90dba2b2769659c4266 - openslp-1.2.1/doc/rfc/rfc2608.txt f75a7b120c557b3f50f87ff7b1c8513e - /home/jas/rfc/rfc2608.txt MISMATCH rfc2608.txt openslp-1.2.1/doc/rfc/rfc2608.txt /home/jas/rfc/rfc2608.txt differ: byte 43494, line 975 tar xfz /data/debian/pool/main/o/openslp/openslp_1.2.1.orig.tar.gz openslp-1.2.1/doc/rfc/rfc2609.txt 803d02c2b120e24ae5dcd80123813815 - openslp-1.2.1/doc/rfc/rfc2609.txt 803d02c2b120e24ae5dcd80123813815 - /home/jas/rfc/rfc2609.txt MATCH rfc2609.txt tar xfz /data/debian/pool/main/o/openslp/openslp_1.2.1.orig.tar.gz openslp-1.2.1/doc/rfc/rfc2610.txt 42a5a84285fedc3e3d0761413fe5cd0b - openslp-1.2.1/doc/rfc/rfc2610.txt 42a5a84285fedc3e3d0761413fe5cd0b - /home/jas/rfc/rfc2610.txt MATCH rfc2610.txt tar xfz /data/debian/pool/main/o/openslp/openslp_1.2.1.orig.tar.gz openslp-1.2.1/doc/rfc/rfc2614.txt 92c8d3c1a6267cd606f93dcdf2b07f60 - openslp-1.2.1/doc/rfc/rfc2614.txt 92c8d3c1a6267cd606f93dcdf2b07f60 - /home/jas/rfc/rfc2614.txt MATCH rfc2614.txt tar xfz /data/debian/pool/main/o/openslp/openslp_1.2.1.orig.tar.gz openslp-1.2.1/doc/rfc/rfc2165.txt 76c04265a788c7098bc506c607666839 - openslp-1.2.1/doc/rfc/rfc2165.txt 76c04265a788c7098bc506c607666839 - /home/jas/rfc/rfc2165.txt MATCH rfc2165.txt tar xfz /data/debian/pool/main/o/openslp/openslp_1.2.1.orig.tar.gz openslp-1.2.1/doc/rfc/rfc2254.txt a2e1cab26eed6c987664138c472a17e8 - openslp-1.2.1/doc/rfc/rfc2254.txt a2e1cab26eed6c987664138c472a17e8 - /home/jas/rfc/rfc2254.txt MATCH rfc2254.txt pkg openswan ver 1:2.4.6+dfsg-1 lastfile openswan_2.4.6+dfsg.orig.tar.gz files openswan-2.4.6/doc/std/draft-beaulieu-ike-xauth-02.txt openswan-2.4.6/doc/std/draft-dukes-ike-mode-cfg-02.txt tar xfz /data/debian/pool/main/o/openswan/openswan_2.4.6+dfsg.orig.tar.gz openswan-2.4.6/doc/std/draft-beaulieu-ike-xauth-02.txt 21b4fc0a1115fad1a6ad24be4bb95736 - openswan-2.4.6/doc/std/draft-beaulieu-ike-xauth-02.txt 21b4fc0a1115fad1a6ad24be4bb95736 - /home/jas/rfc/draft-beaulieu-ike-xauth-02.txt MATCH draft-beaulieu-ike-xauth-02.txt tar xfz /data/debian/pool/main/o/openswan/openswan_2.4.6+dfsg.orig.tar.gz openswan-2.4.6/doc/std/draft-dukes-ike-mode-cfg-02.txt c1848a072a13ce52ebba9758e39b7581 - openswan-2.4.6/doc/std/draft-dukes-ike-mode-cfg-02.txt c1848a072a13ce52ebba9758e39b7581 - /home/jas/rfc/draft-dukes-ike-mode-cfg-02.txt MATCH draft-dukes-ike-mode-cfg-02.txt pkg proftpd ver 1.3.0-9.1 lastfile proftpd_1.3.0.orig.tar.gz files proftpd-1.3.0/doc/rfc/draft-bonachea-sftp-00.txt proftpd-1.3.0/doc/rfc/draft-ietf-ftpext-mlst-15.txt proftpd-1.3.0/doc/rfc/draft-ietf-ftpext-sec-consider-02.txt proftpd-1.3.0/doc/rfc/rfc0959.txt proftpd-1.3.0/doc/rfc/rfc2228.txt proftpd-1.3.0/doc/rfc/rfc2389.txt proftpd-1.3.0/doc/rfc/rfc2428.txt proftpd-1.3.0/doc/rfc/rfc4217.txt tar xfz /data/debian/pool/main/p/proftpd/proftpd_1.3.0.orig.tar.gz proftpd-1.3.0/doc/rfc/draft-bonachea-sftp-00.txt 3208a895b237d7670d603781363d674c - proftpd-1.3.0/doc/rfc/draft-bonachea-sftp-00.txt 3d60d91b91d83ee6e3c88dc263a5ca8f - /home/jas/rfc/draft-bonachea-sftp-00.txt MISMATCH draft-bonachea-sftp-00.txt --- proftpd-1.3.0/doc/rfc/draft-bonachea-sftp-00.txt 1999-10-27 03:43:26.000000000 +0200 +++ /home/jas/rfc/draft-bonachea-sftp-00.txt 2002-04-09 16:00:00.000000000 +0200 @@ -1,3 +1,13 @@ +HTTP/1.1 200 OK +Date: Mon, 08 Apr 2002 22:55:00 GMT +Server: Apache/1.3.20 (Unix) +Last-Modified: Fri, 18 Jun 1999 09:03:00 GMT +ETag: "2e7e1b-2b3b-376a0b44" +Accept-Ranges: bytes +Content-Length: 11067 +Connection: close +Content-Type: text/plain + Network Working Group D. Bonachea S. McPeak Updates: RFC 2228 @@ -274,3 +284,4 @@ Bonachea & McPeak [Page 5] + proftpd-1.3.0/doc/rfc/draft-bonachea-sftp-00.txt /home/jas/rfc/draft-bonachea-sftp-00.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/p/proftpd/proftpd_1.3.0.orig.tar.gz proftpd-1.3.0/doc/rfc/draft-ietf-ftpext-mlst-15.txt 535dcac17f7d0a106fcf02f785da7e20 - proftpd-1.3.0/doc/rfc/draft-ietf-ftpext-mlst-15.txt 535dcac17f7d0a106fcf02f785da7e20 - /home/jas/rfc/draft-ietf-ftpext-mlst-15.txt MATCH draft-ietf-ftpext-mlst-15.txt tar xfz /data/debian/pool/main/p/proftpd/proftpd_1.3.0.orig.tar.gz proftpd-1.3.0/doc/rfc/draft-ietf-ftpext-sec-consider-02.txt 17d7832cc901d0788de056a6a7106ce9 - proftpd-1.3.0/doc/rfc/draft-ietf-ftpext-sec-consider-02.txt 17d7832cc901d0788de056a6a7106ce9 - /home/jas/rfc/draft-ietf-ftpext-sec-consider-02.txt MATCH draft-ietf-ftpext-sec-consider-02.txt tar xfz /data/debian/pool/main/p/proftpd/proftpd_1.3.0.orig.tar.gz proftpd-1.3.0/doc/rfc/rfc0959.txt 61fe27e8453911367a6b1efdb218faa7 - proftpd-1.3.0/doc/rfc/rfc0959.txt 61fe27e8453911367a6b1efdb218faa7 - /home/jas/rfc/rfc959.txt MATCH rfc959.txt tar xfz /data/debian/pool/main/p/proftpd/proftpd_1.3.0.orig.tar.gz proftpd-1.3.0/doc/rfc/rfc2228.txt d6d205deff41295b6aa33c32f8261103 - proftpd-1.3.0/doc/rfc/rfc2228.txt 4eb71f3257e3bb163dd8daf96accae11 - /home/jas/rfc/rfc2228.txt MISMATCH rfc2228.txt --- proftpd-1.3.0/doc/rfc/rfc2228.txt 2003-07-29 16:36:28.000000000 +0200 +++ /home/jas/rfc/rfc2228.txt 1997-10-27 19:27:47.000000000 +0100 @@ -1,5 +1,9 @@ + + + + Network Working Group M. Horowitz Request for Comments: 2228 Cygnus Solutions Updates: 959 S. Lunt proftpd-1.3.0/doc/rfc/rfc2228.txt /home/jas/rfc/rfc2228.txt differ: byte 3, line 3 tar xfz /data/debian/pool/main/p/proftpd/proftpd_1.3.0.orig.tar.gz proftpd-1.3.0/doc/rfc/rfc2389.txt 8df99fcf9634565c0b508b109acc4411 - proftpd-1.3.0/doc/rfc/rfc2389.txt 8fd37e5230206d7b252e7ed210489fdb - /home/jas/rfc/rfc2389.txt MISMATCH rfc2389.txt --- proftpd-1.3.0/doc/rfc/rfc2389.txt 2003-07-29 16:36:28.000000000 +0200 +++ /home/jas/rfc/rfc2389.txt 1998-08-18 22:28:32.000000000 +0200 @@ -1,11 +1,16 @@ + + + + Network Working Group P. Hethmon Request for Comments: 2389 Hethmon Brothers See Also: 959 R. Elz Category: Standards Track University of Melbourne August 1998 + Feature negotiation mechanism for the File Transfer Protocol Status of this Memo @@ -25,6 +30,38 @@ protocol can discover which new features are supported by a particular FTP server. + + + + + + + + + + + + + + + + + + + + + + + + + +Hethmon & Elz Standards Track [Page 1] + +RFC 2389 Feature negotiation mechanism August 1998 + + + + Table of Contents Abstract ................................................ 1 @@ -43,6 +80,9 @@ Editors' Addresses ...................................... 8 Full Copyright Statement ................................ 9 + + + 1. Introduction This document amends the File Transfer Protocol (FTP) [1]. Two new @@ -68,6 +108,14 @@ simply recall that these definitions exist here, and skip to the next section. + + + +Hethmon & Elz Standards Track [Page 2] + +RFC 2389 Feature negotiation mechanism August 1998 + + 2.1. Basic Tokens This document imports the definitions given in Appendix A of [3]. @@ -117,6 +165,13 @@ specified commands and features not defined in [1], or this document, must be included in the FEAT command output in the form specified in + + +Hethmon & Elz Standards Track [Page 3] + +RFC 2389 Feature negotiation mechanism August 1998 + + the document that defines the extension. User-FTP PIs must expect to see, in FEAT command responses, unknown @@ -166,6 +221,13 @@ single space. That space is not optional, nor does it indicate general white space. This space guarantees that the feature line can + + +Hethmon & Elz Standards Track [Page 4] + +RFC 2389 Feature negotiation mechanism August 1998 + + never be misinterpreted as the end of the feature-listing, but is required even where there is no possibility of ambiguity. @@ -214,6 +276,14 @@ order, or even to consistently return the same order when the command is repeated. + + + +Hethmon & Elz Standards Track [Page 5] + +RFC 2389 Feature negotiation mechanism August 1998 + + FTP implementations which support FEAT MUST include in the response to the FEAT command all properly documented FTP extensions beyond those commands and mechanisms described in RFC959 [1], including any @@ -259,6 +329,17 @@ command-name = command-options = + + + + + + +Hethmon & Elz Standards Track [Page 6] + +RFC 2389 Feature negotiation mechanism August 1998 + + Response Syntax: opts-response = opts-good / opts-bad opts-good = "200" SP response-message CRLF @@ -304,6 +385,17 @@ FEAT command, and manipulated by the OPTS command, should be addressed where those features are defined. + + + + + + +Hethmon & Elz Standards Track [Page 7] + +RFC 2389 Feature negotiation mechanism August 1998 + + 6. References [1] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", @@ -331,6 +423,7 @@ Phone: +1 423 690 8990 Email: phethmon@hethmon.com + Robert Elz University of Melbourne Department of Computer Science @@ -339,6 +432,26 @@ Email: kre@munnari.OZ.AU + + + + + + + + + + + + + + + +Hethmon & Elz Standards Track [Page 8] + +RFC 2389 Feature negotiation mechanism August 1998 + + Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. @@ -367,3 +480,28 @@ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + +Hethmon & Elz Standards Track [Page 9] + \ No newline at end of file proftpd-1.3.0/doc/rfc/rfc2389.txt /home/jas/rfc/rfc2389.txt differ: byte 3, line 3 tar xfz /data/debian/pool/main/p/proftpd/proftpd_1.3.0.orig.tar.gz proftpd-1.3.0/doc/rfc/rfc2428.txt 383fcad3f2f5ff2248b6bbcbbf5a886d - proftpd-1.3.0/doc/rfc/rfc2428.txt bb833e794246693ee030f4a5dcc10247 - /home/jas/rfc/rfc2428.txt MISMATCH rfc2428.txt --- proftpd-1.3.0/doc/rfc/rfc2428.txt 2003-07-29 16:36:28.000000000 +0200 +++ /home/jas/rfc/rfc2428.txt 1998-09-22 21:47:39.000000000 +0200 @@ -1,5 +1,9 @@ + + + + Network Working Group M. Allman Request for Comments: 2428 NASA Lewis/Sterling Software Category: Standards Track S. Ostermann proftpd-1.3.0/doc/rfc/rfc2428.txt /home/jas/rfc/rfc2428.txt differ: byte 3, line 3 tar xfz /data/debian/pool/main/p/proftpd/proftpd_1.3.0.orig.tar.gz proftpd-1.3.0/doc/rfc/rfc4217.txt c6f7d6fe23d24305b9a598ea015a3af3 - proftpd-1.3.0/doc/rfc/rfc4217.txt c6f7d6fe23d24305b9a598ea015a3af3 - /home/jas/rfc/rfc4217.txt MATCH rfc4217.txt pkg psp ver 0.5.5-3 lastfile psp_0.5.5.orig.tar.gz files psp-0.5.5/cpan/URI/rfc2396.txt tar xfz /data/debian/pool/main/p/psp/psp_0.5.5.orig.tar.gz psp-0.5.5/cpan/URI/rfc2396.txt f220ecfce7f18e502c117d3006597725 - psp-0.5.5/cpan/URI/rfc2396.txt f220ecfce7f18e502c117d3006597725 - /home/jas/rfc/rfc2396.txt MATCH rfc2396.txt pkg qpopper ver 4.0.5-4.1 lastfile qpopper_4.0.5.orig.tar.gz files qpopper4.0.5/doc/rfc1939.txt qpopper4.0.5/doc/rfc2449.txt tar xfz /data/debian/pool/main/q/qpopper/qpopper_4.0.5.orig.tar.gz qpopper4.0.5/doc/rfc1939.txt 15ff19982bd41e884ce1b5675054ac22 - qpopper4.0.5/doc/rfc1939.txt 15ff19982bd41e884ce1b5675054ac22 - /home/jas/rfc/rfc1939.txt MATCH rfc1939.txt tar xfz /data/debian/pool/main/q/qpopper/qpopper_4.0.5.orig.tar.gz qpopper4.0.5/doc/rfc2449.txt 823ca44de449aceee6e85a98a9cc7667 - qpopper4.0.5/doc/rfc2449.txt 20e27be1834fe8c044ef4eeb77e886ab - /home/jas/rfc/rfc2449.txt MISMATCH rfc2449.txt qpopper4.0.5/doc/rfc2449.txt /home/jas/rfc/rfc2449.txt differ: byte 30834, line 885 pkg quagga ver 0.99.5-2 lastfile quagga_0.99.5.orig.tar.gz files quagga-0.99.5/doc/draft-zebra-00.txt tar xfz /data/debian/pool/main/q/quagga/quagga_0.99.5.orig.tar.gz quagga-0.99.5/doc/draft-zebra-00.txt 4d57b75444d2e052d1aa76c321e0801b - quagga-0.99.5/doc/draft-zebra-00.txt ~/rfc /data/debian/bad/quagga-0.99.5-2 --15:19:50-- http://bgp.potaroo.net/ietf/all-ids//draft-zebra-00.txt => `draft-zebra-00.txt' Resolving bgp.potaroo.net... 203.50.0.159 Connecting to bgp.potaroo.net|203.50.0.159|:80... connected. HTTP request sent, awaiting response... 404 Not Found 15:19:50 ERROR 404: Not Found. FETCH-FAIL draft-zebra-00.txt /data/debian/bad/quagga-0.99.5-2 d41d8cd98f00b204e9800998ecf8427e - /home/jas/rfc/draft-zebra-00.txt MISMATCH draft-zebra-00.txt diff: /home/jas/rfc/draft-zebra-00.txt: No such file or directory cmp: /home/jas/rfc/draft-zebra-00.txt: No such file or directory pkg sident ver 3.6-1 lastfile sident_3.6.orig.tar.gz files sident-3.6/doc/draft-morgan-ident-ext-04.txt tar xfz /data/debian/pool/main/s/sident/sident_3.6.orig.tar.gz sident-3.6/doc/draft-morgan-ident-ext-04.txt caad859e57a3b4b85b4e576e8e43a9c7 - sident-3.6/doc/draft-morgan-ident-ext-04.txt 7865cf9d26b7454061c014088b84427a - /home/jas/rfc/draft-morgan-ident-ext-04.txt MISMATCH draft-morgan-ident-ext-04.txt --- sident-3.6/doc/draft-morgan-ident-ext-04.txt 2006-02-08 23:12:43.000000000 +0100 +++ /home/jas/rfc/draft-morgan-ident-ext-04.txt 1999-08-30 16:00:00.000000000 +0200 @@ -2,11 +2,9 @@ - - Network Working Group RL "Bob" Morgan Internet Draft Stanford University -draft-morgan-ident-ext-04.txt October 1997 +draft-morgan-ident-ext-04.txt March 1998 S/Ident: Security Extensions for the Ident Protocol @@ -33,11 +31,7 @@ A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will - expire in April 1998. Distribution of this draft is unlimited. - - [Added 2005-04-14: Distribution of this document, with or without - modification, is permitted under the same license as the rest of the - S/Ident package.] + expire in September 1998. Distribution of this draft is unlimited. Table of Contents @@ -61,7 +55,7 @@ RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 1] -Internet Draft S/Ident October 1997 +Internet Draft S/Ident March 1998 4.4. ERROR responses @@ -88,7 +82,7 @@ with a TCP connection between the two hosts. This memo specifies extensions to Ident to support strong (i.e., cryptographic) authentication methods. The extensions are based on the Simple - Authentication and Security Layer [SASL]. + Authentication and Security Layer [RFC-2222]. 2. Motivation and Background @@ -117,12 +111,12 @@ RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 2] -Internet Draft S/Ident October 1997 +Internet Draft S/Ident March 1998 mechanisms for the IMAP protocol [IMAP]. This framework has been - generalized into the "Simple Authentication and Security Layer" - [SASL]. This proposal adapts that framework to extend the Ident + generalized into the "Simple Authentication and Security Layer", SASL + [RFC-2222]. This proposal adapts that framework to extend the Ident protocol. 3. Terminology @@ -146,45 +140,9 @@ 3.2. Requirements - The following terms are used in this memo to signify the requirements - of this specification. - - 1) MUST, or the adjective REQUIRED, means that the definition is an - absolute requirement of the specification. - - 2) MUST NOT means that the definition is an absolute prohibition of - the specification. - - 3) SHOULD means that there may exist valid reasons in particular - circumstances to ignore a particular item, but the full implications - MUST be understood and carefully weighed before choosing a different - course. - - 4) SHOULD NOT means that there may exist valid reasons in particular - circumstances when the particular behavior is acceptable or even - useful, but the full implications SHOULD be understood and the case - carefully weighed before implementing any behavior described with - this label. - - 5) MAY, or the adjective OPTIONAL, means that an item is truly - optional. One implementor may choose to include the item because a - - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 3] - -Internet Draft S/Ident October 1997 - - - particular application requires it or because the implementor feels - that it enhances the implementation while another implementor may - omit the same item. An implementation which does not include a - particular option MUST be prepared to interoperate with another - implementation which does include the option. - - "Can" is used instead of "MAY" when referring to a possible - circumstance or situation, as opposed to an optional facility of the - protocol. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. 4. S/Ident design @@ -205,6 +163,13 @@ for example + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 3] + +Internet Draft S/Ident March 1998 + + 6193, 23 : USERID : UNIX : stjohns 6195, 23 : ERROR : NO-USER @@ -225,13 +190,6 @@ value ::= kvchar+ - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 4] - -Internet Draft S/Ident October 1997 - - kvchar ::= < A-Z a-z 0-9 - !@#$%^&*()_+.<>/?~{}[] > That is, a keyword value sequence is a keyword followed by "=" @@ -261,6 +219,13 @@ RFC 1413 specifies resp-type values of USERID and ERROR, each with its own format: + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 4] + +Internet Draft S/Ident March 1998 + + 6193, 23 : USERID : : 6195, 23 : ERROR : @@ -280,14 +245,6 @@ AUTHENTICATE [: ]* that is, the token "AUTHENTICATE" followed by zero or more fields - - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 5] - -Internet Draft S/Ident October 1997 - - specifying authentication request information, separated by ":". Each field identifies an authentication mechanism; several auth-req fields MAY be included to allow the responder a choice of methods. @@ -318,6 +275,13 @@ where auth-resp-info is specific to the authentication mechanism. + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 5] + +Internet Draft S/Ident March 1998 + + If the responder is not able to use any of the authentication mechanisms proposed by the requester in its initial request message, it MAY specify a different mechanism in its response. In this case @@ -336,14 +300,6 @@ modification and disclosure in mechanisms that support such protection. It is defined as: - - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 6] - -Internet Draft S/Ident October 1997 - - {resp-flags, resp-port, req-port, authid-len, authid, pad} where @@ -366,7 +322,7 @@ authid-len is the two-octet length in octets, in network byte order, of the following authid field; - authid is the "authorization identity" (as described in SASL) + authid is the "authorization identity" (as described in [RFC-2222]) asserted by the user; and pad is zero to seven zero-valued octets to bring the total pre- @@ -374,6 +330,14 @@ 4.4. ERROR responses + + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 6] + +Internet Draft S/Ident March 1998 + + New values for the field of ERROR responses are defined as appropriate for each mechanism. Note that messages from the requester to the responder indicate errors also, if appropriate; in @@ -392,14 +356,6 @@ AUTH-NOT-SUPPORTED Indicates that none of the authentication mechanisms offered by the - - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 7] - -Internet Draft S/Ident October 1997 - - requester are supported for authentication of the owner of the indicated connection. It MAY also be sent by the requester to indicate that the authentication mechanism specified by the @@ -430,6 +386,14 @@ This section defines keywords and values for use in the resp-ext-data field of extended ERROR response messages. + + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 7] + +Internet Draft S/Ident March 1998 + + Keyword: CAPABILITY. Values following the CAPABILITY keyword indicate optional capabilities that are supported by the responder. A responder SHOULD include the CAPABILITY block listing all of its @@ -448,14 +412,6 @@ separately listed as GSSAPI/. Values defined in this memo are: GSSAPI/KERBEROS_V5, GSSAPI/SPKM, GSSAPI/DCE. A responder SHOULD include the AUTH-MECH block listing all of its supported - - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 8] - -Internet Draft S/Ident October 1997 - - mechanisms in each error response. 4.5. Connection management @@ -486,17 +442,25 @@ 5. Mechanism definitions + + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 8] + +Internet Draft S/Ident March 1998 + + The following sections describe how some SASL-defined security mechanisms are applied to S/Ident. 5.1. Kerberos version 4 mechanism The auth-mech token for the Kerberos 4 authentication mechanism - [KERB-4] is as specified in SASL ("KERBEROS_V4"). + [KERB-4] is as specified in RFC 2222 ("KERBEROS_V4"). The auth-req-info for the first request message in this mechanism is - the challenge as specified in SASL, a random 32-bit number in network - byte order. + the challenge as specified in RFC 2222, a random 32-bit number in + network byte order. In response to the first request message, the responder sends a message whose auth-resp-info field consists of the following parts, @@ -505,20 +469,13 @@ (1) a two-octet integer in network byte order indicating the length of part (2) in octets; - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 9] - -Internet Draft S/Ident October 1997 - - (2) a Kerberos ticket and an authenticator for the service principal "ident.hostname@realm", where "ident" is the service name, "hostname" is the first component of the host name of the server with all letters in lower case, and where "realm" is the Kerberos realm of the server. The client principal is the principal associated with the owner of the connection specified in the request. As specified in - SASL, the encrypted checksum field included within the Kerberos + RFC 2222, the encrypted checksum field included within the Kerberos authenticator contains the server provided 32-bit challenge in network byte order. @@ -542,6 +499,13 @@ it sends the appropriate S/Ident error message to the responder and concludes its processing for the session. + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 9] + +Internet Draft S/Ident March 1998 + + In the no-error case, if the NMA bit in the resp-flags field of the S/Ident authenticator is set, the requester concludes its processing without sending another message. Otherwise, the requester forms a @@ -561,13 +525,6 @@ 5.1.1. USER-INTERACTION modifier - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 10] - -Internet Draft S/Ident October 1997 - - The "USER-INTERACTION" modifier keyword has two possible values: "YES" and "NO". The "NO" value indicates that the responder SHOULD generate a response using whatever credentials are available for the @@ -583,10 +540,10 @@ 5.2. GSSAPI mechanism The auth-mech token for the all mechanisms using the GSSAPI [GSSAPI] - is as specified in SASL ("GSSAPI"). + is as specified in RFC 2222 ("GSSAPI"). - Protocol interactions occur as specified in SASL. The service name - for the requester is "ident". There is no security layer. + Protocol interactions occur as specified in RFC 2222. The service + name for the requester is "ident". There is no security layer. The "authorization identity" field in the final response message contains the complete S/Ident authenticator. The requester verifies @@ -597,6 +554,14 @@ 5.2.1. USER-INTERACTION modifier This is defined identically to the KERBEROS_V4 USER-INTERACTION + + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 10] + +Internet Draft S/Ident March 1998 + + modifier. 6. Compatibility @@ -616,14 +581,6 @@ 7. Security considerations This protocol can provide only authentication information. - - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 11] - -Internet Draft S/Ident October 1997 - - Protection of the integrity or confidentiality of the application data stream can not be provided. @@ -653,6 +610,14 @@ untrusted services should not both run on the same host if they are using the S/Ident scheme for authentication. + + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 11] + +Internet Draft S/Ident March 1998 + + Similarly, any login users on a service host that uses S/Ident can relatively easily generate valid request messages to clients of that host. This suggests restricting login access to hosts that use @@ -672,14 +637,6 @@ always responds with a NO-USER or USER-CANT-AUTH error. Furthermore, note that if the system on which the responder is - - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 12] - -Internet Draft S/Ident October 1997 - - running is running any TCP-based services, a requester can initiate a request to one of these services and then request authentication on that connection (this includes the S/Ident responder itself!). This @@ -698,7 +655,7 @@ 8. Formal syntax - + (to be supplied) 9. Acknowledgements @@ -709,6 +666,14 @@ Andy Hanushevsky of Cornell's Project Mandarin developed a callback authentication scheme called "SideCar" (SideCar is the responder side, FrontCar is the requester side) [SIDECAR]. This proposal + + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 12] + +Internet Draft S/Ident March 1998 + + borrows the basic callback idea from there. The MacLeland team at Stanford [MACLELAND], including Andy Maas and @@ -728,14 +693,6 @@ [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. - - - -RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 13] - -Internet Draft S/Ident October 1997 - - [GSSAPI] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997. @@ -756,8 +713,8 @@ [RFC-1731] J. Myers, "IMAP4 Authentication mechanisms", RFC 1731, 1994. - [SASL] J. Myers, "Simple Authentication and Security Layer", - draft-myers-auth-sasl-11.txt, 1997. + [RFC-2222] J. Myers, "Simple Authentication and Security Layer", + RFC 2222, October 1997. [Sidecar] http://www.mandarin.org/. @@ -765,6 +722,14 @@ RL "Bob" Morgan Computing and Communication Systems + + + +RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 13] + +Internet Draft S/Ident March 1998 + + Pine Hall Stanford University Stanford, CA 94305 @@ -787,5 +752,35 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + RL "Bob" Morgan draft-morgan-ident-ext-04.txt [Page 14] + sident-3.6/doc/draft-morgan-ident-ext-04.txt /home/jas/rfc/draft-morgan-ident-ext-04.txt differ: byte 5, line 5 pkg silc-toolkit ver 0.9.12-5 lastfile silc-toolkit_0.9.12.orig.tar.gz files silc-toolkit-0.9.12/doc/draft-riikonen-presence-attrs-03.txt silc-toolkit-0.9.12/doc/draft-riikonen-silc-commands-06.txt silc-toolkit-0.9.12/doc/draft-riikonen-silc-flags-payloads-04.txt silc-toolkit-0.9.12/doc/draft-riikonen-silc-ke-auth-08.txt silc-toolkit-0.9.12/doc/draft-riikonen-silc-pp-09.txt silc-toolkit-0.9.12/doc/draft-riikonen-silc-spec-08.txt tar xfz /data/debian/pool/main/s/silc-toolkit/silc-toolkit_0.9.12.orig.tar.gz silc-toolkit-0.9.12/doc/draft-riikonen-presence-attrs-03.txt 0e219833d1b794ef91ddf80d7cd9e887 - silc-toolkit-0.9.12/doc/draft-riikonen-presence-attrs-03.txt 728b5140b9613c908ae9b17a9492b38c - /home/jas/rfc/draft-riikonen-presence-attrs-03.txt MISMATCH draft-riikonen-presence-attrs-03.txt --- silc-toolkit-0.9.12/doc/draft-riikonen-presence-attrs-03.txt 2004-02-29 16:11:29.000000000 +0100 +++ /home/jas/rfc/draft-riikonen-presence-attrs-03.txt 2004-03-29 05:51:25.000000000 +0200 @@ -38,7 +38,7 @@ Abstract This document defines set of attributes that can represent the online - user’s presence in a network, and to provide general information about + user's presence in a network, and to provide general information about the user. The purpose is to provide a generic mechanism to share online presence and status, and general information about the user to be used in several kind of network protocols and applications. @@ -72,14 +72,14 @@ 2.5 Attributes ................................................ 5 3 Security Considerations ....................................... 11 4 References .................................................... 12 - 5 Author’s Address .............................................. 13 + 5 Author's Address .............................................. 13 6 Full Copyright Statement ...................................... 13 1. Introduction This document defines set of attributes that can represent the online - user’s presence in a network, and to provide general information about + user's presence in a network, and to provide general information about the user. The purpose is to provide a generic mechanism to share online presence and status, and general information about the user to be used in several kind of network protocols and applications. @@ -130,7 +130,7 @@ a defined mechanism to provide these informations is needed. The attributes are usually requested by an entity in the network - from other entity, usually a user or end user’s device in the network. + from other entity, usually a user or end user's device in the network. The recipient then replies to each of the requested attributes and sends the reply to the requester. @@ -361,7 +361,7 @@ 4 ATTRIBUTE_STATUS_FREETEXT - This attribute includes the user’s online status free text. It + This attribute includes the user's online status free text. It can provide personal status as a text message. The contents of this attribute is a UTF-8 encoded free text string. @@ -371,7 +371,7 @@ 5 ATTRIBUTE_STATUS_MESSAGE - This attribute includes the user’s online status message. It + This attribute includes the user's online status message. It could provide for example a multi media message showing the status of the user. The contents of this attribute is a MIME object, which can be used to provide for example video, audio, image or @@ -465,7 +465,7 @@ 10 ATTRIBUTE_DEVICE_INFO - This attribute includes information about the user’s device. + This attribute includes information about the user's device. The encoding of this attribute is as follows: Length Type Value @@ -497,7 +497,7 @@ 12 ATTRIBUTE_USER_PUBLIC_KEY - This attribute includes the user’s public key or certificate. + This attribute includes the user's public key or certificate. As the public key and certificate format depends on which sort of algorithm or certificate encoding user is using we need to @@ -511,7 +511,7 @@ define a mechanism to differentiate the public key types from each other. This document specifies the most common public keys and certificates. This attribute can be used to deliver the - user’s public key, and it MUST be present if also the + user's public key, and it MUST be present if also the ATTRIBUTE_USER_DIGITAL_SIGNATURE is present. Note that the recipient of this attribute SHOULD verify the public key from a third party, for example from Certification Authority. If @@ -682,7 +682,7 @@ -5 Author’s Address +5 Author's Address Pekka Riikonen Snellmaninkatu 34 A 15 silc-toolkit-0.9.12/doc/draft-riikonen-presence-attrs-03.txt /home/jas/rfc/draft-riikonen-presence-attrs-03.txt differ: byte 1284, line 41 tar xfz /data/debian/pool/main/s/silc-toolkit/silc-toolkit_0.9.12.orig.tar.gz silc-toolkit-0.9.12/doc/draft-riikonen-silc-commands-06.txt 4f9ffc816620500a45c1fb34ef4b173f - silc-toolkit-0.9.12/doc/draft-riikonen-silc-commands-06.txt 8b7e512cb92dc38d9e879b48ccaf5819 - /home/jas/rfc/draft-riikonen-silc-commands-06.txt MISMATCH draft-riikonen-silc-commands-06.txt --- silc-toolkit-0.9.12/doc/draft-riikonen-silc-commands-06.txt 2004-02-29 16:11:28.000000000 +0100 +++ /home/jas/rfc/draft-riikonen-silc-commands-06.txt 2004-03-29 05:54:39.000000000 +0200 @@ -72,7 +72,7 @@ 3 SILC Status Types ............................................. 44 4 Security Considerations ....................................... 51 5 References .................................................... 51 - 6 Author’s Address .............................................. 52 + 6 Author's Address .............................................. 52 Appendix A ...................................................... 52 Full Copyright Statement ........................................ 54 @@ -107,7 +107,7 @@ This section briefly describes the syntax of the command notions in this document. Every field in command is separated from each - other by whitespaces (‘ ’) indicating that each field is independent + other by whitespaces (` ') indicating that each field is independent @@ -208,7 +208,7 @@ All commands that has an ID as argument (for example ) are actually ID Payloads, defined in [SILC2] that includes the type of the ID, length of the ID and the actual ID data. This way variable length - ID’s can be sent as arguments. + ID's can be sent as arguments. All passphrases that may be sent in commands as arguments MUST be UTF-8 [RFC3629] encoded. All strings sent as arguments in command and @@ -262,8 +262,8 @@ It is also possible to search the user by Client ID. If the is provided server MUST use it as the search value instead of the . It is also possible to define multiple - Client ID’s to search multiple users sending only one WHOIS - command. In this case the Client ID’s are appended as normal + Client ID's to search multiple users sending only one WHOIS + command. In this case the Client ID's are appended as normal arguments. The is defined in [ATTRS] and can be used @@ -321,7 +321,7 @@ respectively. The command replies include the Client ID of the nickname, - nickname and server name, user name and host name and user’s real + nickname and server name, user name and host name and user's real name. Client should process these replies only after the last reply has been received with the STATUS_LIST_END status. If the option were defined in the query there will be only @@ -329,7 +329,7 @@ The server returns the list of channels if the client has joined channels. In this case the list is list of Channel - Payloads. The Mode Mask in the Channel Payload is the channel’s + Payloads. The Mode Mask in the Channel Payload is the channel's mode. The list is encoded by adding the Channel Payloads one after the other. Private and secret channels MUST NOT be sent, @@ -344,11 +344,11 @@ the sender is server. The MUST also be sent if client is joined channels. This list includes 32 bit MSB first order values one after the other and each indicate - the user’s mode on a channel. The order of these values MUST + the user's mode on a channel. The order of these values MUST be same as the channel order in the . - The server also returns client’s user mode, idle time, and the - fingerprint of the client’s public key. The is the + The server also returns client's user mode, idle time, and the + fingerprint of the client's public key. The is the binary hash digest of the public key. The fingerprint MUST NOT be sent if the server has not verified the proof of possession of the corresponding private key. Server can do this during the @@ -435,7 +435,7 @@ (5) [] (n) [...] Identify command is used to query information about an entity by - the entity’s name or ID. This command can be used to query + the entity's name or ID. This command can be used to query information about clients, servers and channels. The query may find multiple matching entities. The option @@ -453,7 +453,7 @@ is provided server must use it as the search value - instead of the entity’s name. One of the arguments MUST be given. + instead of the entity's name. One of the arguments MUST be given. It is also possible to define multiple ID Payloads to search multiple entities sending only one IDENTIFY command. In this case the ID Payloads are appended as normal arguments. The type of the @@ -476,7 +476,7 @@ Max Arguments: 4 Arguments: (1) (2) - (3) [] (4) [] + (3) [] (4) [] This command may reply with several command reply messages to form a list of results. In this case the status payload will include @@ -486,16 +486,16 @@ IDs was requested then each found and unfound client must cause successful or error reply, respectively. - When querying clients the must include the client’s + When querying clients the must include the client's nickname in the following format: nickname[@server]. The - must include the client’s username and host in the following + must include the client's username and host in the following format: username@host. - When querying servers the must include the server’s + When querying servers the must include the server's full name. The may be omitted. - When querying channels the must include the - channel’s name. The may be omitted. + When querying channels the must include the + channel's name. The may be omitted. If the option were defined in the query there will be only many replies from the server. @@ -549,7 +549,7 @@ generated by the server every time user changes their nickname. Client receiving this payload MUST start using the received Client ID as its current valid Client ID. The New ID Payload - is described in [SILC2]. The is the user’s new + is described in [SILC2]. The is the user's new nickname. Status messages: @@ -666,8 +666,8 @@ (3) [] (4) [] This command can be used to invite other clients to join to a - channel, and to manage the channel’s invite list. The argument is the target client’s ID that is being invited. + channel, and to manage the channel's invite list. The argument is the target client's ID that is being invited. @@ -995,7 +995,7 @@ The is the username set in the server configurations as operator. The is the data that the client is authenticated against. It may be passphrase prompted - for user on client’s screen or it may be public key authentication + for user on client's screen or it may be public key authentication based on digital signatures. The public key used to verify the signature should be locally saved in the server, and server should not use public key received during the SKE to verify this signature. @@ -1044,7 +1044,7 @@ The second argument is the Client ID of the client which is joining to the client. When client sends this command - to the server the MUST be the client’s own ID. + to the server the MUST be the client's own ID. Cipher to be used to secure the traffic on the channel MAY be requested by sending the name of the requested . This @@ -1080,7 +1080,7 @@ can verify does not exist on the channel public key list the client MUST NOT be allowed to join the channel. Because more than one public key may be set on channel the - Authentication Payload’s Public Data field + Authentication Payload's Public Data field MUST include an indication of the public key to be used. The first 20 bytes of the Public Data field MUST be SHA-1 digest of the public key that must be used in verification. Rest of the @@ -1461,7 +1461,7 @@ client on private channel will no be detected to be on - the channel as the channel is not shown in the client’s + the channel as the channel is not shown in the client's currently joined channel list. Channel founder and channel operator MAY set/unset this mode. @@ -1583,7 +1583,7 @@ The public key used to verify the payload is the if present, or the public key of the client sending this command. If is present also that - public key MUST be saved as founder’s public key. This + public key MUST be saved as founder's public key. This mode may be set only if the was verified successfully. The hash function used with the MUST be sha1. @@ -1684,7 +1684,7 @@ Internet Draft 11 February 2004 - to the server’s primary router. If the was + to the server's primary router. If the was not provided this command returns the mode mask, founder key, channel public key list and the current user limit to the client. @@ -1697,7 +1697,7 @@ This command replies with the changed channel mode mask that client MUST keep locally. It may also return the channel - founder’s public key if it is set. It may also return list of + founder's public key if it is set. It may also return list of channel public keys when the list was altered. The is Argument List Payload and each argument includes one public key. The is the current user limit @@ -1730,7 +1730,7 @@ channel. Users on channel may have some special modes and this command is used by channel operators to set or change these modes. The is the ID of the target channel. The - is OR’ed mask of modes. The is the target client. + is OR'ed mask of modes. The is the target client. The client changing channel user modes MUST be on the same channel @@ -2046,7 +2046,7 @@ This command is used to set up a watch for nickname. When a user in the network appears with the - nickname, or signoffs the network or user’s mode is changed + nickname, or signoffs the network or user's mode is changed the client which set up the watch will be notified about this change. This can be used to watch for certain nicknames in the network and receive notifications when for example a @@ -2060,7 +2060,7 @@ Implementations MAY set limits for how many nicknames client can watch. - OPTIONALLY this command may also be set to watch clients’ actions + OPTIONALLY this command may also be set to watch clients' actions in the network using their public key or certificate. The MAY be present, and it is an Argument List Payload where each argument is a Public Key Payload including public key @@ -2120,7 +2120,7 @@ The is the username set in the server configurations as operator. The is the data that the client is authenticated against. It may be passphrase prompted - for user on client’s screen or it may be public key or certificate + for user on client's screen or it may be public key or certificate authentication data (data signed with private key). The public key that router will use to verify the signature found in the payload should be verified. It is recommended that the public @@ -2229,9 +2229,9 @@ This command replies with the Channel ID of the requested channel Client ID list of the users on the channel and list of their modes. - The Client ID list has Client ID’s of all users in the list. The - is formed by adding Client ID’s one after another. - The is formed by adding client’s user modes on + The Client ID list has Client ID's of all users in the list. The + is formed by adding Client ID's one after another. + The is formed by adding client's user modes on the channel one after another (4 bytes (32 bits) each). The of length of 4 bytes (32 bits), tells the number of entries in the lists. Both lists MUST have equal number of entries. @@ -2271,7 +2271,7 @@ Arguments: (1) (2) (3) [] - This command replies with the client’s or server’s ID and with + This command replies with the client's or server's ID and with the . Status messages: @@ -2497,7 +2497,7 @@ 3 SILC_STATUS_LIST_END End of the list. There were several command replies and this - reply is the last of the list. There won’t be other replies + reply is the last of the list. There won't be other replies belonging to this list after this one. 4 - 9 @@ -2550,7 +2550,7 @@ 16 SILC_STATUS_ERR_WILDCARDS "Wildcards cannot be used". Wildcards were provided but they - weren’t permitted. + weren't permitted. 17 SILC_STATUS_ERR_NO_CLIENT_ID @@ -2695,7 +2695,7 @@ 38 SILC_STATUS_ERR_NOT_YOU "Cannot change mode for other users". User tried to change - someone else’s mode. + someone else's mode. 39 SILC_STATUS_ERR_NO_CHANNEL_PRIV @@ -2795,7 +2795,7 @@ 56 SILC_STATUS_ERR_OPERATION_ALLOWED "Operation is not allowed". A operation, for example a command, - is not allowed or it’s execution is not allowed. + is not allowed or it's execution is not allowed. @@ -2892,7 +2892,7 @@ Attributes", Internet Draft, May 2002. -6 Author’s Address +6 Author's Address Pekka Riikonen Snellmaninkatu 34 A 15 @@ -2957,7 +2957,7 @@ this sort of command reply for WHOIS command. The information received from the client MAY be cached in the - server’s end. The caching may be desired for example if the client + server's end. The caching may be desired for example if the client can be detached from the network. This way the server is then able to provide at least partial information for a requester. The server MAY also process the command reply and verify whether the silc-toolkit-0.9.12/doc/draft-riikonen-silc-commands-06.txt /home/jas/rfc/draft-riikonen-silc-commands-06.txt differ: byte 2559, line 75 tar xfz /data/debian/pool/main/s/silc-toolkit/silc-toolkit_0.9.12.orig.tar.gz silc-toolkit-0.9.12/doc/draft-riikonen-silc-flags-payloads-04.txt 65526b8dac219e8dbd81ee4a25de63bf - silc-toolkit-0.9.12/doc/draft-riikonen-silc-flags-payloads-04.txt 3dc11f8a91508bc795ddc564b313ee74 - /home/jas/rfc/draft-riikonen-silc-flags-payloads-04.txt MISMATCH draft-riikonen-silc-flags-payloads-04.txt --- silc-toolkit-0.9.12/doc/draft-riikonen-silc-flags-payloads-04.txt 2004-02-29 16:11:29.000000000 +0100 +++ /home/jas/rfc/draft-riikonen-silc-flags-payloads-04.txt 2004-06-25 02:20:11.000000000 +0200 @@ -3,7 +3,6 @@ - Network Working Group P. Riikonen Internet-Draft draft-riikonen-flags-payloads-04.txt 2 December 2003 @@ -73,7 +72,7 @@ 3.5 SILC_MESSAGE_FLAG_ACK ..................................... 8 4 Security Considerations ....................................... 9 5 References .................................................... 9 - 6 Author’s Address .............................................. 10 + 6 Author's Address .............................................. 10 7 Full Copyright Statement ...................................... 10 @@ -81,7 +80,7 @@ The Secure Internet Live Conferencing [SILC1] supports sending binary messages between users in the network. To make the data sending, and - processing at the receiver’s end as simple as possible the SILC defines + processing at the receiver's end as simple as possible the SILC defines Message Flags to the Message Payload [SILC2] that is used to send private and channel messages, which can help the receiver to decide how the data is encoded, and how it should be interpreted. Some of the Message Flags @@ -138,7 +137,7 @@ The problem of Message Flags is that the space for flags mask is only 16 bits, so there is a limited number of flags available. For this reason having a flag that defines a generic way of sending any kind of data as - a message, and can be easily interpreted at the receiver’s end is important. + a message, and can be easily interpreted at the receiver's end is important. For this reason the flag SILC_MESSAGE_FLAG_DATA was added to the protocol which can represent any data. This memo describe how this flag is used and how the associated payload is constructed and processed. This memo @@ -194,7 +193,7 @@ non-repudiation. This flag defines a payload which is used to deliver the actual message, - sender’s public key and the digital signature. The payload for + sender's public key and the digital signature. The payload for SILC_MESSAGE_FLAG_SIGNED is as follows: (*) indicates that the field is not encrypted. @@ -263,7 +262,7 @@ o Public Key Payload (variable length) - This includes the Public Key Payload [SILC2] which can be used to deliver the - sender’s public key (or certificate). It also indicates the + sender's public key (or certificate). It also indicates the type of the public key (or certificate) which the recipient use to identify how the signature must be verified. This payload must always be present but it is not required to @@ -434,9 +433,9 @@ ack_mac = mac(key, MAC); - Where the ’key’ is the MAC key used to compute MACs for the Message - Payload, and the ’MAC’ is the MAC taken from the received Message Payload. - The ’ack_mac’ is placed in the Message Data field in a new Message + Where the 'key' is the MAC key used to compute MACs for the Message + Payload, and the 'MAC' is the MAC taken from the received Message Payload. + The 'ack_mac' is placed in the Message Data field in a new Message Payload, and the payload is encrypted in normal manner. After this the message is sent back to the original sender of the message. @@ -460,11 +459,11 @@ In case of SILC_MESSAGE_FLAG_DATA the implementors should pay special attention to the security implications of any media type that can cause - the remote execution of any actions in the receiver’s environment. The + the remote execution of any actions in the receiver's environment. The [RFC2046] and [RFC2048] discusses more MIME specific security considerations. Even though SILC provides secured messages, in case of MIME which can be used to transfer files and documents which are stored in - the receiver’s local environment, securing separately the MIME object may + the receiver's local environment, securing separately the MIME object may be desired. For example, augmenting the MIME support in SILC messages to support S/MIME may be desired in some implementations. @@ -513,7 +512,7 @@ -6 Author’s Address +6 Author's Address Pekka Riikonen Snellmaninkatu 34 A 15 silc-toolkit-0.9.12/doc/draft-riikonen-silc-flags-payloads-04.txt /home/jas/rfc/draft-riikonen-silc-flags-payloads-04.txt differ: byte 6, line 6 tar xfz /data/debian/pool/main/s/silc-toolkit/silc-toolkit_0.9.12.orig.tar.gz silc-toolkit-0.9.12/doc/draft-riikonen-silc-ke-auth-08.txt aa5e4f175770c0607a9efde1c44cffa9 - silc-toolkit-0.9.12/doc/draft-riikonen-silc-ke-auth-08.txt 3cf9cd51b4906f8d53cfe9dc3d5e336b - /home/jas/rfc/draft-riikonen-silc-ke-auth-08.txt MISMATCH draft-riikonen-silc-ke-auth-08.txt --- silc-toolkit-0.9.12/doc/draft-riikonen-silc-ke-auth-08.txt 2004-02-29 16:11:28.000000000 +0100 +++ /home/jas/rfc/draft-riikonen-silc-ke-auth-08.txt 2004-03-29 05:54:30.000000000 +0200 @@ -83,7 +83,7 @@ 3.3 Connection Authentication Status Types .................... 21 4 Security Considerations ....................................... 21 5 References .................................................... 21 - 6 Author’s Address .............................................. 23 + 6 Author's Address .............................................. 23 7 Full Copyright Statement ...................................... 23 @@ -219,7 +219,7 @@ returned to the original sender unmodified by the responder. Following diagram represents the Key Exchange Start Payload. The lists - mentioned below are always comma (‘,’) separated and the list MUST NOT + mentioned below are always comma (`,') separated and the list MUST NOT @@ -228,7 +228,7 @@ Internet-Draft 2 February 2003 - include white spaces (‘ ’). + include white spaces (` '). 1 2 3 @@ -414,7 +414,7 @@ o HMAC Length (2 bytes) - The length of the HMAC list, not including any other field. - o HMACs (variable length) - The list of HMACs. The HMAC’s + o HMACs (variable length) - The list of HMACs. The HMAC's are used to compute the Message Authentication Code (MAC) of the SILC packets. This field MUST be present. @@ -546,7 +546,7 @@ o Signature Data (variable length) - The signature signed by the sender. The receiver of this signature MUST - verify it. The verification is done using the sender’s + verify it. The verification is done using the sender's public key. See section 2.2 Key Exchange Procedure for detailed description how to produce the signature. If the Mutual Authentication flag is not set then initiator @@ -587,16 +587,16 @@ If the Mutual Authentication flag is set then initiator MUST also produce signature data SIGN_i which the responder will verify. The initiator MUST compute a hash value - HASH_i = hash(Initiator’s Key Exchange Start Payload | - public key (or certificate) | e). The ’|’ stands for + HASH_i = hash(Initiator's Key Exchange Start Payload | + public key (or certificate) | e). The '|' stands for concatenation. It then signs the HASH_i value with its private key resulting a signature SIGN_i. 2. Responder generates a random number y, where 1 < y < q, and computes f = g ^ y mod p. It then computes the shared secret KEY = e ^ y mod p, and, a hash value - HASH = hash(Initiator’s Key Exchange Start Payload | - public key (or certificate) | Initiator’s public key + HASH = hash(Initiator's Key Exchange Start Payload | + public key (or certificate) | Initiator's public key (or certificate) | e | f | KEY). It then signs the HASH value with its private key resulting a signature SIGN. @@ -695,8 +695,8 @@ example CBC mode. As many bytes as needed are taken from the start of the hash output for IV. Sending IV is for sending key and receiving IV is for receiving key. For receiving party, the receiving IV is actually - sender’s sending IV, and, the sending IV is actually sender’s receiving - IV. Initiator uses IV’s as they are (sending IV for sending and + sender's sending IV, and, the sending IV is actually sender's receiving + IV. Initiator uses IV's as they are (sending IV for sending and receiving IV for receiving). The Encryption Keys are derived as well from the hash(). If the hash() @@ -722,7 +722,7 @@ For Receiving Encryption Key the procedure is equivalent. Sending key is used only for encrypting data to be sent. The receiving key is used only to decrypt received data. For receiving party, the receive key is - actually sender’s sending key, and, the sending key is actually sender’s + actually sender's sending key, and, the sending key is actually sender's receiving key. Initiator uses generated keys as they are (sending key @@ -1057,9 +1057,9 @@ the other end, for example server. The plaintext passphrase is put to the payload, that is then encrypted. The plaintext passphrase MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the - sender’s system in some other encoding it MUST be UTF-8 encoded + sender's system in some other encoding it MUST be UTF-8 encoded before transmitted. The receiver MAY change the encoding of the - passphrase to its system’s default character encoding before verifying + passphrase to its system's default character encoding before verifying @@ -1070,7 +1070,7 @@ the passphrase. - If the passphrase matches with the one in the server’s end the + If the passphrase matches with the one in the server's end the authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be sent to the sender and the protocol execution fails. @@ -1236,7 +1236,7 @@ Internet-Draft 2 February 2003 -6 Author’s Address +6 Author's Address Pekka Riikonen Snellmaninkatu 34 A 15 silc-toolkit-0.9.12/doc/draft-riikonen-silc-ke-auth-08.txt /home/jas/rfc/draft-riikonen-silc-ke-auth-08.txt differ: byte 3757, line 86 tar xfz /data/debian/pool/main/s/silc-toolkit/silc-toolkit_0.9.12.orig.tar.gz silc-toolkit-0.9.12/doc/draft-riikonen-silc-pp-09.txt ebc418cee06b3993471cd6e2215ccdfe - silc-toolkit-0.9.12/doc/draft-riikonen-silc-pp-09.txt d1a91efc1add057a05a55b3fde672728 - /home/jas/rfc/draft-riikonen-silc-pp-09.txt MISMATCH draft-riikonen-silc-pp-09.txt --- silc-toolkit-0.9.12/doc/draft-riikonen-silc-pp-09.txt 2004-02-29 16:11:28.000000000 +0100 +++ /home/jas/rfc/draft-riikonen-silc-pp-09.txt 2005-12-03 16:01:47.000000000 +0100 @@ -1,3307 +1,15 @@ +This Internet-Draft, draft-riikonen-silc-pp-08.txt, has expired, and has been deleted +from the Internet-Drafts directory. An Internet-Draft expires 185 days from +the date that it is posted unless it is replaced by an updated version or is +under official review by the IESG for publication as an RFC. This Internet-Draft +was not published as an RFC. + +Internet-Drafts are not archival documents, and copies of Internet-Drafts that have +been deleted from the directory are not available. The Secretariat does not have +any information regarding the future plans of the author(s) or working group, if +applicable, with respect to this deleted Internet-Draft. For more information, or +to request a copy of the document, please contact the author(s) directly. - - - - -Network Working Group P. Riikonen -Internet-Draft -draft-riikonen-silc-pp-08.txt XXX -Expires: XXX - - - SILC Packet Protocol - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. Internet-Drafts are - working documents of the Internet Engineering Task Force (IETF), its - areas, and its working groups. Note that other groups may also - distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - The distribution of this memo is unlimited. - - -Abstract - - This memo describes a Packet Protocol used in the Secure Internet Live - Conferencing (SILC) protocol, specified in the Secure Internet Live - Conferencing, Protocol Specification [SILC1]. This protocol describes - the packet types and packet payloads which defines the contents of the - packets. The protocol provides secure binary packet protocol that - assures that the contents of the packets are secured and authenticated. - - - - - - - - - - - - -Riikonen [Page 1] - -Internet Draft XXX - - -Table of Contents - - 1 Introduction .................................................. 3 - 1.1 Requirements Terminology .................................. 4 - 2 SILC Packet Protocol .......................................... 4 - 2.1 SILC Packet ............................................... 4 - 2.2 SILC Packet Header ........................................ 5 - 2.3 SILC Packet Types ......................................... 7 - 2.3.1 SILC Packet Payloads ................................ 15 - 2.3.2 Generic payloads .................................... 15 - 2.3.2.1 ID Payload .................................. 15 - 2.3.2.2 Argument Payload ............................ 16 - 2.3.2.3 Argument List Payload ....................... 17 - 2.3.2.4 Channel Payload ............................. 18 - 2.3.2.5 Public Key Payload .......................... 19 - 2.3.2.6 Message Payload ............................. 19 - 2.3.3 Disconnect Payload .................................. 23 - 2.3.4 Success Payload ..................................... 23 - 2.3.5 Failure Payload ..................................... 24 - 2.3.6 Reject Payload ...................................... 25 - 2.3.7 Notify Payload ...................................... 25 - 2.3.8 Error Payload ....................................... 34 - 2.3.9 Channel Message Payload ............................. 35 - 2.3.10 Channel Key Payload ................................ 35 - 2.3.11 Private Message Payload ............................ 37 - 2.3.12 Private Message Key Payload ........................ 37 - 2.3.13 Command Payload .................................... 39 - 2.3.14 Command Reply Payload .............................. 40 - 2.3.15 Connection Auth Request Payload .................... 40 - 2.3.16 New ID Payload ..................................... 42 - 2.3.17 New Client Payload ................................. 42 - 2.3.18 New Server Payload ................................. 43 - 2.3.19 New Channel Payload ................................ 44 - 2.3.20 Key Agreement Payload .............................. 45 - 2.3.21 Resume Router Payload .............................. 46 - 2.3.22 File Transfer Payload .............................. 47 - 2.3.23 Resume Client Payload .............................. 48 - 2.4 SILC ID Types ............................................. 49 - 2.5 Packet Encryption And Decryption .......................... 49 - 2.5.1 Normal Packet Encryption And Decryption ............. 50 - 2.5.2 Channel Message Encryption And Decryption ........... 50 - 2.5.3 Private Message Encryption And Decryption ........... 51 - 2.6 Packet MAC Generation ..................................... 52 - 2.7 Packet Padding Generation ................................. 53 - 2.8 Packet Compression ........................................ 53 - 2.9 Packet Sending ............................................ 54 - 2.10 Packet Reception ......................................... 54 - 2.11 Packet Routing ........................................... 54 - - - -Riikonen [Page 2] - -Internet Draft XXX - - - 2.12 Packet Broadcasting ...................................... 56 - 3 Security Considerations ....................................... 56 - 4 References .................................................... 56 - 5 Author’s Address .............................................. 58 - 6 Full Copyright Statement ...................................... 58 - -List of Figures - - Figure 1: Typical SILC Packet - Figure 2: SILC Packet Header - Figure 3: ID Payload - Figure 4: Argument Payload - Figure 5: Argument List Payload - Figure 6: Channel Payload - Figure 7: Public Key Payload - Figure 8: Message Payload - Figure 9: Disconnect Payload - Figure 10: Success Payload - Figure 11: Failure Payload - Figure 12: Reject Payload - Figure 13: Notify Payload - Figure 14: Error Payload - Figure 15: Channel Key Payload - Figure 16: Private Message Key Payload - Figure 17: Command Payload - Figure 18: Connection Auth Request Payload - Figure 19: New Client Payload - Figure 20: New Server Payload - Figure 21: Key Agreement Payload - Figure 22: Resume Router Payload - Figure 23: File Transfer Payload - Figure 24: Resume Client Payload - - -1. Introduction - - This document describes a Packet Protocol used in the Secure Internet - Live Conferencing (SILC) protocol specified in the Secure Internet Live - Conferencing, Protocol Specification [SILC1]. This protocol describes - the packet types and packet payloads which defines the contents of the - packets. The protocol provides secure binary packet protocol that - assures that the contents of the packets are secured and authenticated. - The packet protocol is designed to be compact to avoid unnecessary - overhead as much as possible. This makes the SILC suitable also in - environment of low bandwidth requirements such as mobile networks. All - packet payloads can also be compressed to further reduce the size of - the packets. - - - - -Riikonen [Page 3] - -Internet Draft XXX - - - All packets in SILC network are always encrypted and their integrity - is assured by computed MACs. The protocol defines several packet types - and packet payloads. Each packet type usually has a specific packet - payload that actually defines the contents of the packet. Each packet - also includes a default SILC Packet Header that provides sufficient - information about the origin and the destination of the packet. - - -1.1 Requirements Terminology - - The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, - MAY, and OPTIONAL, when they appear in this document, are to be - interpreted as described in [RFC2119]. - - -2 SILC Packet Protocol - -2.1 SILC Packet - - SILC packets deliver messages from sender to receiver securely by - encrypting important fields of the packet. The packet consists of - default SILC Packet Header, Padding, Packet Payload data, and, packet - MAC. - - The following diagram illustrates typical SILC packet. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | n bytes | 1 - n bytes | n bytes | n bytes - | SILC Header | Padding | Data Payload | MAC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Figure 1: Typical SILC Packet - - - SILC Header is always the first part of the packet and its purpose - is to provide information about the packet. It provides for example - the packet type, origin of the packet and the destination of the packet. - The header is variable in length. See the following section for - description of SILC Packet header. Packets without SILC header or - with malformed SILC header MUST be dropped. - - Padding follows the packet header. The purpose of the padding is to - make the packet multiple by eight (8) or by the block size of the - cipher used in the encryption, which ever is larger. The maximum - length of padding is currently 128 bytes. The padding is always - encrypted. The padding is applied always, even if the packet is - not encrypted. See the section 2.7 Padding Generation for more - detailed information. - - - -Riikonen [Page 4] - -Internet Draft XXX - - - Data payload area follows padding and it is the actual data of the - packet. The packet data is the packet payloads defined in this - protocol. The data payload area is always encrypted. - - The last part of SILC packet is the packet MAC that assures the - integrity of the packet. See the section 2.6 Packet MAC Generation - for more information. If compression is used the compression is - always applied before encryption. - - All fields in all packet payloads are always in MSB (most significant - byte first) order. - - -2.2 SILC Packet Header - - The SILC packet header is applied to all SILC packets and it is - variable in length. The purpose of SILC Packet header is to provide - detailed information about the packet. The receiver of the packet - uses the packet header to parse the packet and gain other relevant - parameters of the packet. - - The following diagram represents the SILC packet header. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Payload Length | Flags | Packet Type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Pad Length | RESERVED | Source ID Len | Dest ID Len | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Src ID Type | | - +-+-+-+-+-+-+-+-+ + - | | - ~ Source ID ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Dst ID Type | | - +-+-+-+-+-+-+-+-+ + - | | - ~ Destination ID ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 2: SILC Packet Header - - o Payload Length (2 bytes) - Indicates the length of the - packet not including the padding of the packet. - - - - -Riikonen [Page 5] - -Internet Draft XXX - - - o Flags (1 byte) - Indicates flags to be used in packet - processing. Several flags may be set by ORing the flags - together. - - The following flags are reserved for this field: - - - No flags 0x00 - - In this case the field is ignored. - - - Private Message Key 0x01 - - Indicates that the packet data MUST include private - message that is encrypted using private key set by - client. Servers does not know this key and cannot - handle the packet, but passes it along. See section - 2.5.3 Private Message Encryption And Decryption for - more information. - - - List 0x02 - - Indicates that the packet consists of list of - packet payloads indicated by the Packet Type field. - The payloads are added one after the other. Note that - there are packet types that must not be used as - list. Parsing of list packet is done by calculating - the length of each payload and parsing them one by - one. - - - Broadcast 0x04 - - Marks the packet to be broadcasted. Client and normal - server cannot send broadcast packets. Only router server - may send broadcast packet. The router receiving of packet - with this flag set MUST send (broadcast) the packet to - its primary route. If router has several router connections - the packet may be sent only to the primary route. See - section 2.12 Packet Broadcasting for description of - packet broadcasting. - - - Compressed 0x08 - - Marks that the payload of the packet is compressed. - - - -Riikonen [Page 6] - -Internet Draft XXX - - - The sender of the packet marks this flag when it - compresses the payload, and any server or router - en route to the recipient MUST NOT unset this flag. - See section 2.8 Packet Compression for description of - packet compressing. - - - o Packet Type (1 byte) - Indicates the type of the packet. - Receiver uses this field to parse the packet. See section - 2.3 SILC Packets for list of defined packet types. - - o Pad Length (1 byte) - Indicates the length of the padding - applied after the SILC Packet header. Maximum length for - padding is 128 bytes. - - o RESERVED (1 byte) - Reserved field and must include a - zero (0) value. - - o Source ID Length (1 byte) - Indicates the length of the - Source ID field in the header, not including this or any - other fields. - - o Destination ID Length (1 byte) - Indicates the length of the - Destination ID field in the header, not including this or - any other fields. - - o Src ID Type (1 byte) - Indicates the type of ID in the - Source ID field. See section 2.4 SILC ID Types for - defined ID types. - - o Source ID (variable length) - The actual source ID that - indicates which is the original sender of the packet. - - o Dst ID Type (1 byte) - Indicates the type of ID in the - Destination ID field. See section 2.4 SILC ID Types for - defined ID types. - - o Destination ID (variable length) - The actual destination - ID that indicates which is the end receiver of the packet. - - - -2.3 SILC Packet Types - - SILC packet types defines the contents of the packet and it is used by - the receiver to parse the packet. The packet type is 8 bits in length. - The range for the packet types are from 0 - 255, where 0 is never sent and - 255 is currently reserved for future extensions and MUST NOT be defined to - - - -Riikonen [Page 7] - -Internet Draft XXX - - - any other purpose. Every SILC specification compliant implementation - SHOULD support all the following packet types. - - The below list of the SILC Packet types includes reference to the packet - payload as well. Packet payloads are the actual packet data area. Each - packet type defines packet payload which usually may only be sent with - the specific packet type. - - Most of the packets are packets that must be destined directly to entity - that is connected to the sender. It is not allowed, for example, for a - router to send SILC_PACKET_DISCONNECT packet to client that is not - directly connected to the router. However, there are some special packet - types that may be destined to some entity that the sender does not have - direct connection with. These packets are for example private message - packets, channel message packets, command packets and some other packets - that may be broadcasted in the SILC network. The following packet - desription list will define it separately if a packet is allowed to be - sent to indirectly connected entity. Other packets MUST NOT be sent or - accepted, if sent, to indirectly connected entities. - - Some packets MAY be sent as lists by adding the List flag to the Packet - Header and constructing multiple packet payloads one after the other. - When this is allowed it is separately defined in the following list. - Other packets MUST NOT be sent as list and the List flag MUST NOT be set. - - - List of SILC Packet types are defined as follows. - - 0 SILC_PACKET_NONE - - This type is reserved and it is never sent. - - - 1 SILC_PACKET_DISCONNECT - - This packet is sent to disconnect the remote end. Reason of - the disconnection is sent inside the packet payload. - - Payload of the packet: See section 2.3.3 Disconnect Payload - - - 2 SILC_PACKET_SUCCESS - - This packet is sent upon successful execution of a protocol. - The status of the success is sent in the packet payload. - - Payload of the packet: See section 2.3.4 Success Payload - - - - -Riikonen [Page 8] - -Internet Draft XXX - - - 3 SILC_PACKET_FAILURE - - This packet is sent upon failure of a protocol. The status - of the failure is sent in the packet payload. - - Payload of the packet: See section 2.3.5 Failure Payload - - - 4 SILC_PACKET_REJECT - - This packet MAY be sent upon rejection of a protocol. The - status of the rejection is sent in the packet payload. - - Payload of the packet: See section 2.3.6 Reject Payload - - - 5 SILC_PACKET_NOTIFY - - This packet is used to send notify message. The packet is - usually sent between server and client, but also between - server and router. Client MUST NOT send this packet. Server - MAY destine this packet to channel as well when the packet is - distributed to all clients on the channel. This packet MAY - be sent as list. - - Payload of the packet: See section 2.3.7 Notify Payload. - - - 6 SILC_PACKET_ERROR - - This packet is sent when an error occurs. Server MAY - send this packet. Client MUST NOT send this packet. The - client MAY entirely ignore the packet, however, server is - most likely to take action anyway. This packet MAY be sent - to entity that is indirectly connected to the sender. - - Payload of the packet: See section 2.3.8 Error Payload. - - - 7 SILC_PACKET_CHANNEL_MESSAGE - - This packet is used to send messages to channels. The packet - includes Channel ID of the channel and the actual message to - the channel. Messages sent to the channel are always protected - by channel specific keys. This packet MAY be sent to entity - that is indirectly connected to the sender. - - Payload of the packet: See section 2.3.9 Channel Message - - - -Riikonen [Page 9] - -Internet Draft XXX - - - Payload - - - 8 SILC_PACKET_CHANNEL_KEY - - This packet is used to distribute new key for particular - channel when server generates it. Each channel has their own - independent keys that is used to protect the traffic on the - channel. It is also possible to use channel private keys that - are not server generated. In this case this packet is not used. - Client MUST NOT send this packet. This packet MAY be sent to - entity that is indirectly connected to the sender. - - Payload of the packet: See section 2.3.10 Channel Key Payload - - - 9 SILC_PACKET_PRIVATE_MESSAGE - - This packet is used to send private messages from client - to another client. By default, private messages are protected - by session keys established by normal key exchange protocol. - However, it is possible to use specific key to protect private - messages. See [SILC1] for private message key generation. - This packet MAY be sent to entity that is indirectly connected - to the sender. - - Payload of the packet: See section 2.3.11 Private Message - Payload - - - 10 SILC_PACKET_PRIVATE_MESSAGE_KEY - - This packet is OPTIONAL and sender of the packet can indicate - that a private message key should be used in private message - communication. The actual key material is not sent in this - packet but must be either static or pre-shared key. The - receiver of the packet is considered to be the responder - when processing the static or pre-shared key material as - defined in [SILC1] and [SILC3] for private message keys. - This packet MAY be sent to entity that is indirectly connected - to the sender. - - Payload of the packet: See section 2.3.12 Private Message - Key Payload - - - 11 SILC_PACKET_COMMAND - - - - -Riikonen [Page 10] - -Internet Draft XXX - - - This packet is used to send commands from client to server. - Server MAY send this packet to other servers as well. All - commands are listed in their own section SILC Command Types - in [SILC4]. The contents of this packet is command specific. - This packet MAY be sent to entity that is indirectly connected - to the sender. - - Payload of the packet: See section 2.3.13 Command Payload - - - 12 SILC_PACKET_COMMAND_REPLY - - This packet is sent as reply to the SILC_PACKET_COMMAND packet. - The contents of this packet is command specific. This packet - MAY be sent to entity that is indirectly connected to the - sender. This packet MAY be sent as list. - - Payload of the packet: See section 2.3.14 Command Reply - Payload and section 2.3.13 Command - Payload - - - 13 SILC_PACKET_KEY_EXCHANGE - - This packet is used to start SILC Key Exchange Protocol, - described in detail in [SILC3]. - - Payload of the packet: Payload of this packet is described - in the section SILC Key Exchange - Protocol and its sub sections in - [SILC3]. - - - 14 SILC_PACKET_KEY_EXCHANGE_1 - - This packet is used as part of the SILC Key Exchange Protocol. - - Payload of the packet: Payload of this packet is described - in the section SILC Key Exchange - Protocol and its sub sections in - [SILC3]. - - - 15 SILC_PACKET_KEY_EXCHANGE_2 - - This packet is used as part of the SILC Key Exchange Protocol. - - Payload of the packet: Payload of this packet is described - - - -Riikonen [Page 11] - -Internet Draft XXX - - - in the section SILC Key Exchange - Protocol and its sub sections in - [SILC3]. - - - 16 SILC_PACKET_CONNECTION_AUTH_REQUEST - - This packet is used to request an authentication method to - be used in the SILC Connection Authentication Protocol. If - initiator of the protocol does not know the mandatory - authentication method this packet MAY be used to determine it. - The party receiving this payload SHOULD respond with the same - packet including the mandatory authentication method. - - Payload of the packet: See section 2.3.15 Connection Auth - Request Payload - - - 17 SILC_PACKET_CONNECTION_AUTH - - This packet is used to start and perform the SILC Connection - Authentication Protocol. This protocol is used to authenticate - the connecting party. The protocol is described in detail in - [SILC3]. - - Payload of the packet: Payload of this packet is described - in the section SILC Authentication - Protocol and it sub sections in [SILC]. - - - 18 SILC_PACKET_NEW_ID - - This packet is used to distribute new IDs from server to - router and from router to all other routers in SILC network. - This is used when for example new client is registered to - SILC network. The newly created IDs of these operations are - distributed by this packet. Only server may send this packet, - however, client MUST be able to receive this packet. This - packet MAY be sent to entity that is indirectly connected - to the sender. This packet MAY be sent as list. - - Payload of the packet: See section 2.3.16 New ID Payload - - - 19 SILC_PACKET_NEW_CLIENT - - This packet is used by client to register itself to the - SILC network. This is sent after key exchange and - - - -Riikonen [Page 12] - -Internet Draft XXX - - - authentication protocols has been completed. Client sends - various information about itself in this packet to the server. - - Payload of the packet: See section 2.3.17 New Client Payload - - - 20 SILC_PACKET_NEW_SERVER - - This packet is used by server to register itself to the - SILC network. This is sent after key exchange and - authentication protocols has been completed. Server sends - this to the router it connected to, or, if router was - connecting, to the connected router. Server sends its - Server ID and other information in this packet. The client - MUST NOT send or receive this packet. - - Payload of the packet: See section 2.3.18 New Server Payload - - - 21 SILC_PACKET_NEW_CHANNEL - - This packet is used to notify routers about newly created - channel. Channels are always created by the router and it MUST - notify other routers about the created channel. Router sends - this packet to its primary route. Client MUST NOT send this - packet. This packet MAY be sent to entity that is indirectly - connected to the sender. This packet MAY be sent as list. - - Payload of the packet: See section 2.3.19 New Channel Payload - - - 22 SILC_PACKET_REKEY - - This packet is used to indicate that re-key must be performed - for session keys. See section Session Key Regeneration in - [SILC1] for more information. This packet does not have - a payload. - - - 23 SILC_PACKET_REKEY_DONE - - This packet is used to indicate that re-key is performed and - new keys must be used hereafter. This packet does not have a - payload. - - - 24 SILC_PACKET_HEARTBEAT - - - - -Riikonen [Page 13] - -Internet Draft XXX - - - This packet is used by clients, servers and routers to keep the - connection alive. It is RECOMMENDED that all servers implement - keepalive actions and perform it to both direction in a link. - This packet does not have a payload. - - - 25 SILC_PACKET_KEY_AGREEMENT - - This packet is used by clients to request key negotiation - between another client in the SILC network. If the negotiation - is started it is performed using the SKE protocol. The result of - the negotiation, the secret key material, can be used for - example as private message key. The server and router MUST NOT - send this packet. - - Payload of the packet: See section 2.3.20 Key Agreement Payload - - - 26 SILC_PACKET_RESUME_ROUTER - - This packet is used during backup router protocol when the - original primary router of the cell comes back online and wishes - to resume the position as being the primary router of the cell. - - Payload of the packet: See section 2.3.21 Resume Router Payload - - - 27 SILC_PACKET_FTP - - This packet is used to perform an file transfer protocol in the - SILC session with some entity in the network. The packet is - multi purpose. The packet is used to tell other entity in the - network that the sender wishes to perform an file transfer - protocol. The packet is also used to actually tunnel the - file transfer protocol stream. The file transfer protocol - stream is always protected with the SILC binary packet protocol. - - Payload of the packet: See section 2.3.22 File Transfer Payload - - - 28 SILC_PACKET_RESUME_CLIENT - - This packet is used to resume a client back to the network - after it has been detached. A client is able to detach from - the network but the client is still valid client in the network. - The client may then later resume its session back by sending - this packet to a server. Routers also use this packet to notify - other routers in the network that the detached client has resumed. - - - -Riikonen [Page 14] - -Internet Draft XXX - - - Payload of the packet: See section 2.3.23 Resume Client Payload - - - 29 - 199 - - Currently undefined commands. - - - 200 - 254 - - These packet types are reserved for private use and they will - not be defined by this document. - - - 255 SILC_PACKET_MAX - - This type is reserved for future extensions and currently it - MUST NOT be sent. - - -2.3.1 SILC Packet Payloads - - All payloads resides in the main data area of the SILC packet. However - all payloads MUST be at the start of the data area after the SILC - packet header and padding. All fields in the packet payload are always - encrypted, as they reside in the data area of the packet which is - always encrypted. Most of the payloads may only be sent with specific - packet type which is defined in the description of the payload. - - There are some other payloads in SILC as well. However, they are not - common in the sense that they could be sent at any time. These payloads - are not described in this section. These are payloads such as SILC - Key Exchange payloads and so on. These are described in [SILC1], - [SILC3] and [SILC4]. - - -2.3.2 Generic payloads - - This section describes generic payloads that are not associated to any - specific packet type. They can be used for example inside some other - packet payload. - - -2.3.2.1 ID Payload - - This payload can be used to send an ID. ID’s are variable in length - thus this payload provides a way to send variable length ID. - - - - -Riikonen [Page 15] - -Internet Draft XXX - - - The following diagram represents the ID Payload. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ID Type | ID Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ ID Data ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 3: ID Payload - - - o ID Type (2 bytes) - Indicates the type of the ID. See - section 2.4 SILC ID Types for list of defined ID types. - - o ID Length (2 bytes) - Length of the ID Data area not - including the length of any other fields in the payload. - - o ID Data (variable length) - The actual ID data. The encoding - of the ID data is defined in section 2.4 SILC ID Types. - - -2.3.2.2 Argument Payload - - Argument Payload is used to set arguments for any packet payload that - need and support arguments, such as commands. Number of arguments - associated with a packet MUST be indicated by the packet payload which - need the arguments. Argument Payloads MUST always reside right after - the packet payload needing the arguments. Incorrect amount of argument - payloads MUST cause rejection of the packet. - - The following diagram represents the Argument Payload. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Data Length | Argument Type | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Argument Data ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 4: Argument Payload - - - - -Riikonen [Page 16] - -Internet Draft XXX - - - o Data Length (2 bytes) - Length of the Argument Data field - not including the length of any other field in the payload. - - o Argument Type (1 byte) - Indicates the type of the argument. - Every argument can have a specific type that are defined - by the packet payload needing the argument. For example - every command specify a number for each argument that may be - associated with the command. By using this number the receiver - of the packet knows what type of argument this is. If there is - no specific argument type this field is set to zero (0) value. - - o Argument Data (variable length) - Argument data. - - -2.3.2.3 Argument List Payload - - Argument List Payload is a list of Argument Payloads appended one - after the other. The number of arguments is indicated in the - payload. - - The following diagram represents the Argument List Payload. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Argument Nums | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Argument Payloads ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 5: Argument List Payload - - - o Argument Nums (2 bytes) - Indicates the number of Argument - Payloads. If zero (0) value is found in this field no - arguments are present. - - o Argument Payloads (variable length) - The Argument Payloads - appended one after the other. The payloads can be decoded - since the length of the payload is indicated in each of - the Argument Payload. - - - - - - - - -Riikonen [Page 17] - -Internet Draft XXX - - -2.3.2.4 Channel Payload - - Generic Channel Payload may be used to send information about a channel, - its name, the Channel ID and a mode. - - The following diagram represents the Channel Payload. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Channel Name Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Channel Name ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Channel ID Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Channel ID ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Mode Mask | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 6: New Channel Payload - - - o Channel Name Length (2 bytes) - Length of the Channel Name - field. - - o Channel Name (variable length) - The name of the channel. - - o Channel ID Length (2 bytes) - Length of the Channel ID field. - - o Channel ID (variable length) - The encoded Channel ID. - - o Mode Mask (4 bytes) - A mode. This can be the mode of the - channel but it can also be the mode of a client on the - channel. The contents of this field is dependent of the - usage of this payload. The usage is defined separately - when this payload is used. This is a 32 bit MSB first value. - - - - - - - - -Riikonen [Page 18] - -Internet Draft XXX - - -2.3.2.5 Public Key Payload - - Generic Public Key Payload may be used to send different type of - public keys and certificates. - - The following diagram represents the Public Key Payload. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Public Key Length | Public Key Type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Public Key (or certificate) ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 7: Public Key Payload - - - o Public Key Length (2 bytes) - The length of the Public Key - (or certificate) field, not including any other field. - - o Public Key Type (2 bytes) - The public key (or certificate) - type. This field indicates the type of the public key in - the packet. See the [SILC3] for defined public key types. - - o Public Key (or certificate) (variable length) - The - encoded public key or certificate data. - - -2.3.2.6 Message Payload - - Generic Message Payload can be used to send messages in SILC. It - is used to send channel messages and private messages. - - The following diagram represents the Message Payload. - - (*) indicates that the field is not encrypted. - - - - - - - - - - - - -Riikonen [Page 19] - -Internet Draft XXX - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Message Flags | Message Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Message Data ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Padding Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Padding ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Initialization Vector * ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ MAC * ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 8: Message Payload - - - o Message Flags (2 bytes) - Includes the Message Flags of the - message. The flags can indicate a reason or a purpose for - the message. The following Message Flags are defined: - - 0x0000 SILC_MESSAGE_FLAG_NONE - - No specific flags set. - - 0x0001 SILC_MESSAGE_FLAG_AUTOREPLY - - This message is an automatic reply to an earlier - received message. - - 0x0002 SILC_MESSAGE_FLAG_NOREPLY - - There should not be reply messages to this - message. - - 0x0004 SILC_MESSAGE_FLAG_ACTION - - The sender is performing an action and the message - - - -Riikonen [Page 20] - -Internet Draft XXX - - - is the indication of the action. - - 0x0008 SILC_MESSAGE_FLAG_NOTICE - - The message is for example an informational notice - type message. - - 0x0010 SILC_MESSAGE_FLAG_REQUEST - - This is a generic request flag to send request - messages. A separate document should define any - payloads associated to this flag. - - 0x0020 SILC_MESSAGE_FLAG_SIGNED - - This flag indicates that the message is signed - with sender’s private key and thus can be verified - by the receiver using the sender’s public key. A - separate document should define the detailed procedure - of the signing process and any associated payloads - for this flag. - - 0x0040 SILC_MESSAGE_FLAG_REPLY - - This is a generic reply flag to send a reply to - previously received request. A separate document - should define any payloads associated to this flag. - - 0x0080 SILC_MESSAGE_FLAG_DATA - - This is a generic data flag, indicating that the - message includes some data which can be interpreted - in a specific way. Using this flag any kind of data - can be delivered inside message payload. A separate - document should define how this flag is interpreted - and define any associated payloads. - - 0x0100 SILC_MESSAGE_FLAG_UTF8 - - This flag indicates that the message is UTF-8 encoded - textual message. When sending text messages in SILC - this flag SHOULD be used. When this flag is used the - text sent as message MUST be UTF-8 encoded. - - 0x0200 SILC_MESSAGE_FLAG_ACK - - This flag indicates the sender requires the recpipient - to acknowledge the received message. This same flag - - - -Riikonen [Page 21] - -Internet Draft XXX - - - is used in the acknowledgement. A separate document - should define how the acknowledgement is performed. - - 0x0400 - 0x1000 RESERVED - - Reserved for future flags. - - 0x2000 - 0x8000 PRIVATE RANGE - - Private range for free use. - - o Message Length (2 bytes) - Indicates the length of the - Message Data field in the payload, not including any - other field. - - o Message Data (variable length) - The actual message data. - - o Padding Length (2 bytes) - Indicates the length of the - Padding field in the payload, not including any other - field. - - o Padding (variable length) - If this payload is used as - channel messages, the padding MUST be applied because - this payload is encrypted separately from other parts - of the packet. If this payload is used as private - messages, the padding is present only when the payload - is encrypted with private message key. If encrypted - with session keys this field MUST NOT be present and the - Padding Length field includes a zero (0) value. The - padding SHOULD be random data. - - o Initialization Vector (variable length) - This field MUST - be present when this payload is used as channel messages. - The IV SHOULD be random data for each channel message. - - When encrypting private messages with session keys this - field MUST NOT be present. For private messages this - field is present only when encrypting with a static - private message key (pre-shared key). If randomly - generated key material is used this field MUST NOT be - present. Also, If Key Agreement (SKE) was used to - negotiate fresh key material for private message key - this field MUST NOT be present. See the section 4.6 - in [SILC1] for more information about IVs when - encrypting private messages. - - This field includes the initialization vector used in message - encryption. It need to be used in the packet decryption - - - -Riikonen [Page 22] - -Internet Draft XXX - - - as well. Contents of this field depends on the encryption - algorithm and encryption mode. This field is not encrypted, - is not included in padding calculation and its length - equals to cipher’s block size. This field is authenticated - by the message MAC. - - o MAC (variable length) - The MAC computed from the - Message Flags, Message Length, Message Data, Padding Length, - Padding and Initialization Vector fields in that order. - The MAC is computed after the payload is encrypted. This - is so called Encrypt-Then-MAC order; first encrypt, then - compute MAC from ciphertext. The MAC protects the integrity - of the Message Payload. Also, when used as channel messages - it is possible to have multiple private channel keys set, - and receiver can use the MAC to verify which of the keys - must be used in decryption. This field is not present - when encrypting private messages with session key. This - field is not encrypted. This field is authenticated by - the SILC packet MAC. - - -2.3.3 Disconnect Payload - - Disconnect payload is sent upon disconnection. Reason of the - disconnection is sent to the disconnected party in the payload. - - The payload may only be sent with SILC_PACKET_DISCONNECT packet. It - MUST NOT be sent in any other packet type. The following diagram - represents the Disconnect Payload. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Status | | - +-+-+-+-+-+-+-+-+ + - | | - ~ Disconnect Message ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 9: Disconnect Payload - - o Status (1 byte) - Indicates the Status Type, defined in [SILC3] - for the reason of disconnection. - - o Disconnect Message (variable length) - Human readable UTF-8 - encoded string indicating reason of the disconnection. This - - - -Riikonen [Page 23] - -Internet Draft XXX - - - field MAY be omitted. - - -2.3.4 Success Payload - - Success payload is sent when some protocol execution is successfully - completed. The payload is simple; indication of the success is sent. - This may be any data, including binary or human readable data, and - it is protocol dependent. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Success Indication ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 10: Success Payload - - - o Success Indication (variable length) - Indication of - the success. This may be for example some flag that - indicates the protocol and the success status or human - readable success message. The true length of this - payload is available by calculating it from the SILC - Packet Header. - - -2.3.5 Failure Payload - - This is opposite of Success Payload. Indication of failure of - some protocol is sent in the payload. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Failure Indication ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 11: Failure Payload - - - o Failure Indication (variable length) - Indication of - the failure. This may be for example some flag that - indicates the protocol and the failure status or human - - - -Riikonen [Page 24] - -Internet Draft XXX - - - readable failure message. The true length of this - payload is available by calculating it from the SILC - Packet Header. - - -2.3.6 Reject Payload - - This payload is sent when some protocol is rejected to be executed. - Other operations MAY send this as well that was rejected. The - indication of the rejection is sent in the payload. The indication - may be binary or human readable data and is protocol dependent. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Reject Indication ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 12: Reject Payload - - - o Reject Indication (variable length) - Indication of - the rejection. This maybe for example some flag that - indicates the protocol and the rejection status or human - readable rejection message. The true length of this - payload is available by calculating it from the SILC - Packet Header. - - - -2.3.7 Notify Payload - - Notify payload is used to send notify messages. The payload is usually - sent from server to client and from server to router. It is also used - by routers to notify other routers in the network. This payload MAY also - be sent to a channel. Client MUST NOT send this payload. When this - packet is received by client it SHOULD process it. Servers and routers - MUST process notify packets. - - The payload may only be sent with SILC_PACKET_NOTIFY packet. It MUST - NOT be sent in any other packet type. The following diagram represents - the Notify Payload. - - - - - - -Riikonen [Page 25] - -Internet Draft XXX - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Notify Type | Payload Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Argument Nums | - +-+-+-+-+-+-+-+-+ - - Figure 13: Notify Payload - - - o Notify Type (2 bytes) - Indicates the type of the notify - message. - - o Payload Length (2 bytes) - Length of the entire Notify Payload - including any associated Argument Payloads. - - o Argument Nums (1 byte) - Indicates the number of Argument - Payloads associated to this payload. Notify types may define - arguments to be sent along the notify message. - - Following the list of currently defined notify types. The format for - notify arguments is same as in SILC commands described in [SILC4]. - Note that all IDs sent in arguments are sent inside ID Payload. Also - note that all strings sent as arguments MUST be UTF-8 [RFC3629] encoded, - unless otherwise defined. Also note that all public keys or - certificates sent inside arguments are actually Public Key Payloads. - - - 0 SILC_NOTIFY_TYPE_NONE - - If no specific notify type apply for the notify message this type - MAY be used. - - Max Arguments: 1 - Arguments: (1) - - The is implementation specific free text string. - Receiver MAY ignore this message. - - - 1 SILC_NOTIFY_TYPE_INVITE - - Sent when an client is invited to a channel. This is also sent - when the invite list of the channel is changed. This notify type - is sent to local servers on the channel, but MUST NOT be sent - to clients on the channel. Router MUST broadcast this to its - primary router and to local servers on the channel. When a client - - - -Riikonen [Page 26] - -Internet Draft XXX - - - was directly invited to the channel this is also sent to that - client. In this case the packet is destined to the client. - - Max Arguments: 5 - Arguments: (1) (2) - (3) [] (4) [] - (5) [] - - The is the channel. The is the name - of the channel and is provided because the client which receives - this notify packet may not have a way to resolve the name of the - channel from the . The is the - Client ID which invited the client to the channel. The - is an argument of size of 1 byte where 0x00 means - adding a client to invite list, and 0x01 means deleting a client - from invite list. The , if present, indicates the - information to be added to or removed from the invite list. - The format is defined in [SILC4] with - SILC_COMMAND_INVITE command. When this notify is destined to - a client the and MUST NOT be sent. - When is used to announce information during server - connecting phase the argument type MUST be 0x03. See section - 4.2.1 in [SILC1] for more information. - - - 2 SILC_NOTIFY_TYPE_JOIN - - Sent when client has joined to a channel. The server MUST - distribute this type to the local clients on the channel and then - send it to its primary router. Note that, when router is joining - the client on behalf of normal server then router MUST send this - notify type locally and globally. The router or server receiving - the packet distributes this type to the local clients on the - channel and broadcast it to the network. This notify is sent - also to the client that joined the channel. - - Max Arguments: 2 - Arguments: (1) [] (2) - - The is the client that joined to the channel - indicated by the . - - - 3 SILC_NOTIFY_TYPE_LEAVE - - Sent when client has left a channel. The server must distribute - this type to the local clients on the channel and then send it - to its primary router. The router or server receiving the - - - -Riikonen [Page 27] - -Internet Draft XXX - - - packet distributes this type to the local clients on the channel - and broadcast it to the network. This notify MUST NOT be sent to - the leaving client. - - Max Arguments: 1 - Arguments: (1) - - The is the client which left the channel. - - - 4 SILC_NOTIFY_TYPE_SIGNOFF - - Sent when client signoff from SILC network. The server MUST - distribute this type to the local clients on the channel and - then send it to its primary router. The router or server - receiving the packet distributes this type to the local clients - on the channel and broadcast it to the network. This notify - MUST NOT be sent to the quitting client. - - Max Arguments: 2 - Arguments: (1) (2) - - The is the client which left SILC network. The - is free text string indicating the reason of the - signoff. - - - 5 SILC_NOTIFY_TYPE_TOPIC_SET - - Sent when topic is set/changed on a channel. This type may be - sent only to the clients which are joined on the channel which - topic was just set or changed. The packet is destined to the - channel. - - Max Arguments: 2 - Arguments: (1) (2) - - The is the ID of the entity who set the topic. - It usually is Client ID but it can be Server ID and Channel ID - as well. - - - 6 SILC_NOTIFY_TYPE_NICK_CHANGE - - Sent when client changes nick on a channel. The server MUST - distribute this type only to the local clients on the channel - and then send it to its primary router. The router or server - receiving the packet distributes this type to the local clients - - - -Riikonen [Page 28] - -Internet Draft XXX - - - on the channel and broadcast it to the network. This packet is - destined directly to the sent entity. This MUST be sent to those - clients that are joined on same channels as the client that - changed the nickname. This notify MUST NOT be sent multiple - times to the same recipient. This notify MUST be sent also to - the client that changed the nickname. - - Max Arguments: 3 - Arguments: (1) (2) - (3) - - The is the old ID of the client which changed - the nickname. The is the new ID generated by - the change of the nickname. The is the new nickname. - Note that it is possible to send this notify even if the - nickname has not changed, but client ID was changed. - - - 7 SILC_NOTIFY_TYPE_CMODE_CHANGE - - Sent when channel mode has changed. This type MUST be sent only - to the clients which are joined on the channel which mode was - changed. This packet is destined to the channel. - - Max Arguments: 8 - Arguments: (1) (2) - (3) [] (4) <[hmac>] - (5) [] (6) [] - (7) [] (8) [] - - The is the ID (usually Client ID but it can be - Server ID as well when the router is enforcing channel mode - change) of the entity which changed the mode. The - is the new mode mask of the channel. The client can safely - ignore the argument since the SILC_PACKET_CHANNEL_KEY - packet will force the new channel key change anyway. The - argument is important since the client is responsible of setting - the new HMAC and the hmac key into use. The is - the passphrase of the channel, if it was now set. The argument is sent when the founder mode on the - channel was set. All routers and servers that receive the packet - MUST save the founder’s public key so that the founder can - reclaim the channel founder rights back for the channel on any - server in the network. The argument is present when - the user limit was set or changed on the channel. - - The is an Argument List Payload and it is used - to add and/or remove channel public keys from the channel. Also, - - - -Riikonen [Page 29] - -Internet Draft XXX - - - when announcing channel information between servers and routers - during connecting phase this argument includes the list of channel - public keys. To add a public key to channel public key list the - SILC_CMODE_CHANNEL_AUTH mode is set and the argument type is 0x00, - and the argument is the public key. To remove a public key from - the channel public key list the argument type is 0x01, and the - argument is the public key to be removed. If the mode - SILC_CMODE_CHANNEL_AUTH is unset (and was set earlier) all public - keys are removed at once. Implementation MAY add and remove - multiple public keys at the same time by including multiple - arguments to the Argument List Payload where each - argument is one Public Key Payload. When is used - to announce information during server connecting phase the - argument type MUST be 0x03. See section 4.2.1 in [SILC1] for - more information. - - - 8 SILC_NOTIFY_TYPE_CUMODE_CHANGE - - Sent when user mode on channel has changed. This type MUST be - sent only to the clients which are joined on the channel where - the target client is on. This packet is destined to the channel. - - Max Arguments: 4 - Arguments: (1) (2) - (3) (4) [] - - The is the ID (usually Client ID but it can be - Server ID as well when the router is enforcing user’s mode - change) of the entity which changed the mode. The - is the new mode mask of the channel. The - is the client which mode was changed. The - is the public key of the channel founder and may be sent only - when first time setting the channel founder mode using the - SILC_COMMAND_CUMODE command, and when sending this notify. - - - 9 SILC_NOTIFY_TYPE_MOTD - - Sent when Message of the Day (motd) is sent to a client. - - Max Arguments: 1 - Arguments: (1) - - The is the Message of the Day. This notify MAY be - ignored and is OPTIONAL. - - - - - -Riikonen [Page 30] - -Internet Draft XXX - - - 10 SILC_NOTIFY_TYPE_CHANNEL_CHANGE - - Sent when channel’s ID has changed for a reason or another. - This is sent by normal server to the client. This can also be - sent by router to other server to force the Channel ID change. - The Channel ID MUST be changed to use the new one. When sent - to clients, this type MUST be sent only to the clients which are - joined on the channel. This packet is destined to the sent - entity. - - Max Arguments: 2 - Arguments: (1) (2) - - The is the channel’s old ID and the is the new one that MUST replace the old one. - Server which receives this from router MUST re-announce the - channel to the router by sending SILC_PACKET_NEW_CHANNEL packet - with the new Channel ID. - - - 11 SILC_NOTIFY_TYPE_SERVER_SIGNOFF - - Sent when server quits SILC network. Those clients from this - server that are on channels must be removed from the channel. - This packet is destined to the sent entity. - - Max Arguments: 256 - Arguments: (1) (n) [] [...] - - The is the server’s ID. The rest of the arguments - are the Client IDs of the clients which are coming from this - server and are thus quitting the SILC network also. If the - maximum number of arguments are reached another - SILC_NOTIFY_TYPE_SERVER_SIGNOFF notify packet MUST be sent. - When this notify packet is sent between routers the Client ID’s - MAY be omitted. Server receiving the Client ID’s in the payload - may use them directly to remove the client. - - - 12 SILC_NOTIFY_TYPE_KICKED - - Sent when a client has been kicked from a channel. This MUST - also be sent to the client which was kicked from the channel. - The client which was kicked from the channel MUST be removed - from the channel. The client MUST also be removed from channel’s - invite list if it is explicitly added in the list. This packet - is destined to the channel. The router or server receiving the - packet distributes this type to the local clients on the channel - - - -Riikonen [Page 31] - -Internet Draft XXX - - - and broadcast it to the network. - - Max Arguments: 3 - Arguments: (1) (2) [] - (3) - - The is the client which was kicked from the channel. - The kicker may have set the string to indicate the - reason for the kicking. The is the kicker. - - - 13 SILC_NOTIFY_TYPE_KILLED - - Sent when a client has been killed from the network. This MUST - also be sent to the client which was killed from the network. - This notify MUST be sent to those clients which are joined on - same channels as the killed client. The client which was killed - MUST be removed from the network. This packet is destined - directly to the sent entity. The router or server receiving - the packet distributes this type to the local clients on the - channel and broadcast it to the network. The client MUST also - be removed from joined channels invite list if it is explicitly - added in the lists. This notify MUST NOT be sent multiple - times to same recipient. - - Max Arguments: 3 - Arguments: (1) (2) [] - (3) - - The is the client which was killed from the network. - The killer may have set the string to indicate the - reason for the killing. The is the killer, which - may be client but also router server. - - - 14 SILC_NOTIFY_TYPE_UMODE_CHANGE - - Sent when user’s mode in the SILC changes. This type is sent - only between routers as broadcast packet. - - Max Arguments: 2 - Arguments: (1) (2) - - The is the client which mode was changed. The - is the new mode mask. - - - 15 SILC_NOTIFY_TYPE_BAN - - - -Riikonen [Page 32] - -Internet Draft XXX - - - Sent when the ban list of the channel is changed. This notify - type is sent to local servers on the channel, but MUST NOT be - sent to clients on the channel. Router MUST broadcast this to - its primary router and to local servers on the channel. - - Max Arguments: 3 - Arguments: (1) (2) [] - (3) [] - - The is the channel which ban list was changed. - The is an argument of size of 1 byte where 0x00 means - adding a client to ban list, and 0x01 means deleting a client - from ban list. The indicates the information to be - added to or removed from the ban list. The format - format is defined in [SILC4] with SILC_COMMAND_BAN command. - When is used to announce information during server - connecting phase the argument type MUST be 0x03. See section - 4.2.1 in [SILC1] for more information. - - - 16 SILC_NOTIFY_TYPE_ERROR - - Sent when an error occurs during processing some SILC procedure. - This is not used when error occurs during command processing, see - [SILC4] for more information about commands and command replies. - This type is sent directly to the sender of the packet whose - packet caused the error. See [SILC1] for definition when this - type can be sent. - - Max Arguments: 256 - Arguments: (1) (n) [...] - - The is the error type defined in [SILC4]. Note - that same types are also used with command replies to indicate - the status of a command. Both commands and this notify type - share same status types. Rest of the arguments are status type - dependent and are specified with those status types that can be - sent currently inside this notify type in [SILC4]. The is size of 1 byte. - - - 17 SILC_NOTIFY_TYPE_WATCH - - Sent to indicate change in a watched user. Client can set - nicknames to be watched with SILC_COMMAND_WATCH command, and - receive notifications when they login to network, signoff from - the network or their user mode is changed. This notify type - is used to deliver these notifications. The notify type is - - - -Riikonen [Page 33] - -Internet Draft XXX - - - sent directly to the watching client. - - Max Arguments: 5 - Arguments: (1) (2) [] - (3) (4) [] - (5) [] - - The is the user’s Client ID which is being watched, - and the is its nickname. If the client just - changed the nickname, then is the new nickname, but - the is the old client ID. The is the - user’s current user mode. The can be same as the - Notify Payload’s Notify Type, and is 16 bit MSB first order - value. If provided it may indicate the notify that occurred - for the client. If client logged in to the network the - MUST NOT be present. The MAY be - present, and it is the public key of the client being watched. - - Notify types starting from 16384 are reserved for private notify - message types. - - Router server which receives SILC_NOTIFY_TYPE_SIGNOFF, - SILC_NOTIFY_TYPE_SERVER_SIGNOFF, SILC_NOTIFY_TYPE_KILLED, - SILC_NOTIFY_TYPE_NICK_CHANGE and SILC_NOTIFY_TYPE_UMODE_CHANGE - MUST check whether someone in the local cell is watching the nickname - the client has, and send the SILC_NOTIFY_TYPE_WATCH notify to the - watcher, unless the watched client in case has the user mode - SILC_UMODE_REJECT_WATCHING set. If the watcher client and the client - that was watched is same the notify SHOULD NOT be sent. - - -2.3.8 Error Payload - - Error payload is sent upon error in protocol. Error may occur in - various conditions when server sends this packet. Client MUST NOT - send this payload but MUST be able to accept it. However, client - MAY ignore the contents of the packet as server is going to take - action on the error anyway. However, it is recommended that the - client takes error packet seriously. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Error Message ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Riikonen [Page 34] - -Internet Draft XXX - - - Figure 14: Error Payload - - - o Error Message (variable length) - Human readable error - message. - - -2.3.9 Channel Message Payload - - Channel Message Payload is used to send message to channels, a group - of users. These messages can only be sent if client has joined to - some channel. Even though this packet is very common in SILC it - is still special packet. Some special handling on sending and - reception of channel message is required. - - Padding MUST be applied into this payload since the payload is - encrypted separately from other parts of the packet with the - channel specific key. Hence the requirement of the padding. - The packet MUST be made multiple by eight (8) or by the block - size of the cipher, which ever is larger. - - The SILC header in this packet is encrypted with the session key - of the next receiver of the packet. Nothing else is encrypted - with that key. Thus, the actual packet and padding to be - encrypted with the session key is SILC Header plus padding to it. - - Receiver of the the channel message packet is able to determine - the channel the message is destined to by checking the Destination - ID from the SILC Packet header which tells the destination channel. - The original sender of the packet is also determined by checking - the source ID from the header which tells the client which sent - the message. The Destination ID MUST be Channel ID in the SILC - Packet header. - - This packet use generic Message Payload as Channel Message Payload. - See section 2.3.2.6 for generic Message Payload. - - -2.3.10 Channel Key Payload - - All traffic in channels are protected by channel specific keys. - Channel Key Payload is used to distribute channel keys to all - clients on the particular channel. Channel keys are sent when - the channel is created, when new user joins to the channel and - whenever a user has left a channel. Server creates the new - channel key and distributes it to the clients by encrypting this - payload with the session key shared between the server and - the client. After that, client MUST start using the key received - - - -Riikonen [Page 35] - -Internet Draft XXX - - - in this payload to protect the traffic on the channel. - - The client which is joining to the channel receives its key in the - SILC_COMMAND_JOIN command reply message thus it is not necessary to - send this payload to the entity which sent the SILC_COMMAND_JOIN - command. - - Channel keys are cell specific thus every router in the cell have - to create a channel key and distribute it if any client in the - cell has joined to a channel. Channel traffic between cell’s - are not encrypted using channel keys, they are encrypted using - normal session keys between two routers. Inside a cell, all - channel traffic is encrypted with the specified channel key. - Channel key SHOULD expire periodically, say, in one hour, in - which case new channel key is created and distributed. - - Note that, this packet is not used if SILC_CMODE_PRIVKEY mode is set - on channel. This means that channel uses channel private keys which - are not server generated. For this reason server cannot send this - packet as it does not know the key. - - The payload may only be sent with SILC_PACKET_CHANNEL_KEY packet. - It MUST NOT be sent in any other packet type. The following diagram - represents the Channel Key Payload. - - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Channel ID Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Channel ID ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Cipher Name Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Cipher Name ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Channel Key Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Channel Key ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Riikonen [Page 36] - -Internet Draft XXX - - - Figure 15: Channel Key Payload - - - - o Channel ID Length (2 bytes) - Indicates the length of the - Channel ID field in the payload, not including any other - field. - - o Channel ID (variable length) - The Channel ID of the - channel. - - o Cipher Name Length (2 bytes) - Indicates the length of the - Cipher name field in the payload, not including any other - field. - - o Cipher Name (variable length) - Name of the cipher used - in the protection of channel traffic. This name is - initially decided by the creator of the channel but it - may change during the life time of the channel as well. - - o Channel Key Length (2 bytes) - Indicates the length of the - Channel Key field in the payload, not including any other - field. - - o Channel Key (variable length) - The actual channel key - material. - - -2.3.11 Private Message Payload - - Private Message Payload is used to send private message between - two clients. The messages are sent only to the specified user - and no other user inside SILC network is able to see the message. - - The message can be protected by the session key established by the - SILC Key Exchange Protocol. However, it is also possible to agree - to use a private key to protect just the private messages. It is - for example possible to perform Key Agreement between two clients. - See section 2.3.20 Key Agreement Payload how to perform key - agreement. It is also possible to use static or pre-shared keys - to protect private messages. See the 2.3.12 Private Message Key - Payload and [SILC1] section 4.6 for detailed description for private - message key generation. - - If normal session key is used to protect the message, every server - between the sender client and the receiving client MUST decrypt the - packet and always re-encrypt it with the session key of the next - receiver of the packet. See section Client To Client in [SILC1]. - - - -Riikonen [Page 37] - -Internet Draft XXX - - - When the private message key is used, and the Private Message Key - flag was set in the SILC Packet header no server or router en route - is able to decrypt or re-encrypt the packet. In this case only the - SILC Packet header is processed by the servers and routers en route. - Section Client To Client in [SILC1] gives example of this scheme. - - This packet use generic Message Payload as Private Message Payload. - See section 2.3.2.6 for generic Message Payload. - - -2.3.12 Private Message Key Payload - - This payload is OPTIONAL and can be used to indicate that a static - or pre-shared key should be used in the private message communication - to protect the messages. The actual key material has to be sent - outside the SILC network, or it has to be a static or pre-shared key. - The sender of this packet is considered to be the initiator and the - receiver the responder when processing the raw key material as - described in the section 4.6 in [SILC1] and in the section 2.3 in - [SILC3]. - - Note that it is also possible to use static or pre-shared keys in - client implementations without sending this packet. Clients may - naturally agree to use a key without sending any kind of indication - to each other. The key may be for example a long-living static key - that the clients has agreed to use at all times. Note that it is - also possible to agree to use private message key by performing - a Key Agreement. See the section 2.3.20 Key Agreement Payload. - - This payload may only be sent by client to another client. Server - MUST NOT send this payload. After sending this payload and setting the - key into use this payload the sender of private messages MUST set the - Private Message Key flag into the SILC Packet Header. - - The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE_KEY - packet. It MUST NOT be sent in any other packet type. The following - diagram represents the Private Message Key Payload. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Cipher Name Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Cipher Name ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Riikonen [Page 38] - -Internet Draft XXX - - - | HMAC Name Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ HMAC Name ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 16: Private Message Key Payload - - - - o Cipher Name Length (2 bytes) - Indicates the length of the - Cipher Name field in the payload, not including any other - field. - - o Cipher Name (variable length) - Name of the cipher to use - in the private message encryption. If this field does not - exist then the default cipher of the SILC protocol is used. - See the [SILC1] for defined ciphers. - - o HMAC Name Length (2 bytes) - Indicates the length of the - HMAC Name field in the payload, not including any other - field. - - o HMAC Name (variable length) - Name of the HMAC to use - in the private message MAC computation. If this field does - not exist then the default HMAC of the SILC protocol is used. - See the [SILC1] for defined HMACs. - - -2.3.13 Command Payload - - Command Payload is used to send SILC commands from client to server. - Also server MAY send commands to other servers. The following diagram - represents the Command Payload. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Payload Length | SILC Command | Arguments Num | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Command Identifier | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 17: Command Payload - - - - - -Riikonen [Page 39] - -Internet Draft XXX - - - o Payload Length (2 bytes) - Length of the entire command - payload including any command argument payloads associated - with this payload. - - o SILC Command (1 byte) - Indicates the SILC command. This MUST - be set to non-zero value. If zero (0) value is found in this - field the packet MUST be discarded. - - o Arguments Num (1 byte) - Indicates the number of arguments - associated with the command. If there are no arguments this - field is set to zero (0). The arguments MUST follow the - Command Payload. See section 2.3.2.2 for definition of the - Argument Payload. - - o Command Identifier (2 bytes) - Identifies this command at the - sender’s end. The entity which replies to this command MUST - set the value found from this field into the Command Payload - used to send the reply to the sender. This way the sender - can identify which command reply belongs to which originally - sent command. What this field includes is implementation - issue but it is RECOMMENDED that wrapping counter value is - used in the field. - - See [SILC4] for detailed description of different SILC commands, - their arguments and their reply messages. - - -2.3.14 Command Reply Payload - - Command Reply Payload is used to send replies to the commands. The - Command Reply Payload is identical to the Command Payload thus see - the 2.3.13 section for the payload specification. - - The entity which sends the reply packet MUST set the Command Identifier - field in the reply packet’s Command Payload to the value it received - in the original command packet. - - See SILC Commands in [SILC4] for detailed description of different - SILC commands, their arguments and their reply messages. - - -2.3.15 Connection Auth Request Payload - - Client MAY send this payload to server to request the authentication - method that must be used in authentication protocol. If client knows - this information beforehand this payload is not necessary to be sent. - Server performing authentication with another server MAY also send - this payload to request the authentication method. If the connecting - - - -Riikonen [Page 40] - -Internet Draft XXX - - - server already knows this information this payload is not necessary - to be sent. - - Server receiving this request SHOULD reply with same payload sending - the mandatory authentication method. Algorithms that may be required - to be used by the authentication method are the ones already - established by the SILC Key Exchange protocol. See section Key - Exchange Start Payload in [SILC3] for detailed information. - - The payload may only be sent with SILC_PACKET_CONNECTION_AUTH_REQUEST - packet. It MUST NOT be sent in any other packet type. The following - diagram represents the Connection Auth Request Payload. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Connection Type | Authentication Method | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 18: Connection Auth Request Payload - - - o Connection Type (2 bytes) - Indicates the type of the - connection. The following connection types are defined: - - - 1 Client connection - 2 Server connection - 3 Router connection - - If any other type is found in this field the packet MUST be - discarded and the authentication MUST be failed. - - o Authentication Method (2 bytes) - Indicates the authentication - method to be used in the authentication protocol. The following - authentication methods are defined: - - 0 NONE (mandatory) - 1 password (mandatory) - 2 public key (mandatory) - - If any other type is found in this field the packet MUST be - discarded and the authentication MUST be failed. If this - payload is sent as request to receive the mandatory - authentication method this field MUST be set to zero (0), - indicating that receiver should send the mandatory - authentication method. The receiver sending this payload - - - -Riikonen [Page 41] - -Internet Draft XXX - - - to the requesting party, MAY also set this field to zero (0) - to indicate that authentication is not required. In this - case authentication protocol still MUST be started but - server is most likely to respond with SILC_PACKET_SUCCESS - immediately. - - -2.3.16 New ID Payload - - New ID Payload is a multipurpose payload. It is used to send newly - created ID’s from clients and servers. When client connects to server - and registers itself to the server by sending SILC_PACKET_NEW_CLIENT - packet, server replies with this packet by sending the created ID for - the client. Server always creates the ID for the client. - - This payload is also used when server tells its router that new client - has registered to the SILC network. In this case the server sends - the Client ID of the client to the router. Similarly when router - distributes information to other routers about the client in the SILC - network this payload is used. - - Also, when server connects to router, router use this payload to inform - other routers about new server in the SILC network. However, every - server (or router) creates their own ID’s thus the ID distributed by - this payload is not created by the distributor in this case. Servers - create their own ID’s. Server registers itself to the network by - sending SILC_PACKET_NEW_SERVER to the router it connected to. The case - is same when router connects to another router. - - This payload MUST NOT be used to send information about new channels. - New channels are always distributed by sending the dedicated - SILC_PACKET_NEW_CHANNEL packet. Client MUST NOT send this payload. - Both client and server (and router) MAY receive this payload. - - The packet use generic ID Payload as New ID Payload. See section - 2.3.2.1 for generic ID Payload. - - -2.3.17 New Client Payload - - When client is connected to the server, keys has been exchanged and - connection has been authenticated, client MUST register itself to the - server. Client’s first packet after key exchange and authentication - protocols MUST be SILC_PACKET_NEW_CLIENT. This payload tells server all - the relevant information about the connected user. Server creates a new - client ID for the client when received this payload and sends it to the - client in New ID Payload. - - - - -Riikonen [Page 42] - -Internet Draft XXX - - - This payload sends username and real name of the user on the remote host - which is connected to the SILC server with SILC client. The server - creates the client ID according the information sent in this payload. - The nickname of the user becomes the nickname sent in this payload. - - The payload may only be sent with SILC_PACKET_NEW_CLIENT packet. It - MUST NOT be sent in any other packet type. The following diagram - represents the New Client Payload. - - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Username Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Username ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Real Name Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Real Name ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 19: New Client Payload - - - o Username Length (2 bytes) - Length of the Username field. - - o Username (variable length) - The username of the user on - the host where connecting to the SILC server. - - o Real Name Length (2 bytes) - Length of the Real Name field. - - o Real Name (variable length) - The real name of the user - on the host where connecting to the SILC server. - - -2.3.18 New Server Payload - - This payload is sent by server when it has completed successfully both - key exchange and connection authentication protocols. The server - MUST register itself to the SILC Network by sending this payload. - The first packet after these key exchange and authentication protocols - is SILC_PACKET_NEW_SERVER packet. The payload includes the Server ID - - - -Riikonen [Page 43] - -Internet Draft XXX - - - of the server that it has created by itself. It also includes a - name of the server that is associated to the Server ID. - - The payload may only be sent with SILC_PACKET_NEW_SERVER packet. It - MUST NOT be sent in any other packet type. The following diagram - represents the New Server Payload. - - - - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Server ID Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Server ID Data ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Server Name Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Server Name ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 20: New Server Payload - - - o Server ID Length (2 bytes) - Length of the Server ID Data - field. - - o Server ID Data (variable length) - The encoded Server ID - data. - - o Server Name Length (2 bytes) - Length of the server name - field. - - o Server Name (variable length) - The server name string. - - -2.3.19 New Channel Payload - - Information about newly created channel is broadcasted to all routers - in the SILC network by sending this packet payload. Channels are - created by router of the cell. Server never creates channels unless - it is a standalone server and it does not have router connection, - - - -Riikonen [Page 44] - -Internet Draft XXX - - - in this case server acts as router. Normal server send JOIN command - to the router (after it has received JOIN command from client) which - then processes the command and creates the channel. Client MUST NOT - send this packet. Server MAY send this packet to a router when it is - announcing its existing channels to the router after it has connected - to the router. - - The packet use generic Channel Payload as New Channel Payload. See - section 2.3.2.3 for generic Channel Payload. The Mode Mask field in the - Channel Payload is the mode of the channel. - - -2.3.20 Key Agreement Payload - - This payload is used by clients to request key negotiation between - another client in the SILC Network. The key agreement protocol used - is the SKE protocol. The result of the protocol, the secret key - material, can be used for example as private message key between the - two clients. This significantly adds security as the clients agree - about the key without any server interaction. The protocol is executed - peer to peer. The server and router MUST NOT send this payload. - - The sender MAY tell the receiver of this payload the hostname and the - port where the SKE protocol is running in the sender’s end. The - receiver MAY then initiate the SKE negotiation with the sender. The - sender MAY also optionally not to include the hostname and the port - of its SKE protocol. In this case the receiver MAY reply to the - request by sending the same payload filled with the receiver’s hostname - and the port where the SKE protocol is running. The sender MAY then - initiate the SKE negotiation with the receiver. - - This payload may be sent with SILC_PACKET_KEY_AGREEMENT and - SILC_PACKET_FTP packet types. It MUST NOT be sent in any other packet - types. The following diagram represents the Key Agreement Payload. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Hostname Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Hostname ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Port | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - -Riikonen [Page 45] - -Internet Draft XXX - - - Figure 21: Key Agreement Payload - - - o Hostname Length (2 bytes) - Indicates the length of the - Hostname field. - - o Hostname (variable length) - The hostname or IP address where - the SKE protocol is running, as UTF-8 encoded string. The sender - MAY fill this field when sending the payload. If the receiver - sends this payload as reply to the request it MUST fill this field. - - o Port (4 bytes) - The port where the SKE protocol is bound. - The sender MAY fill this field when sending the payload. If - the receiver sends this payload as reply to the request it - MUST fill this field. This is a 32 bit MSB first order value. - - - After the key material has been received from the SKE protocol it is - processed as the [SILC3] describes. If the key material is used as - channel private key then the Sending Encryption Key, as defined in - [SILC3] is used as the channel private key. Other key material must - be discarded. The [SILC1] in section 4.6 defines the way to use the - key material if it is intended to be used as private message keys. - Any other use for the key material is undefined. - - -2.3.21 Resume Router Payload - - See the [SILC1] for Resume Router protocol where this payload is - used. The payload may only be sent with SILC_PACKET_RESUME_ROUTER - packet. It MUST NOT be sent in any other packet type. The following - diagram represents the Resume Router Payload. - - - 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Session ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 22: Resume Router Payload - - - o Type (1 byte) - Indicates the type of the backup resume - protocol packet. The type values are defined in [SILC1]. - - o Session ID (1 bytes) - Indicates the session ID for the - backup resume protocol. The sender of the packet sets this - - - -Riikonen [Page 46] - -Internet Draft XXX - - - value and the receiver MUST set the same value in subsequent - reply packet. - - - - -2.3.22 File Transfer Payload - - File Transfer Payload is used to perform file transfer protocol between - two entities in the network. The actual file transfer protocol is always - encapsulated inside the SILC Packet. The actual data stream is also sent - peer to peer outside SILC network. - - When an entity, usually a client wishes to perform file transfer protocol - with another client in the network, they perform Key Agreement protocol - as described in the section 2.3.20 Key Agreement Payload and in [SILC3], - inside File Transfer Payload. After the Key Agreement protocol has been - performed the subsequent packets in the data stream will be protected - using the new key material. The actual file transfer protocol is also - initialized in this stage. All file transfer protocol packets are always - encapsulated in the File Transfer Payload and protected with the - negotiated key material. - - The payload may only be sent with SILC_PACKET_FTP packet. It MUST NOT - be sent in any other packet type. The following diagram represents the - File Transfer Payload. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | | - +-+-+-+-+-+-+-+-+ + - | | - ~ Data ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 23: File Transfer Payload - - - o Type (1 byte) - Indicates the type of the file transfer - protocol. The following file transfer protocols has been - defined: - - 1 Secure File Transfer Protocol (SFTP) (mandatory) - - If zero (0) value or any unsupported file transfer protocol - - - -Riikonen [Page 47] - -Internet Draft XXX - - - type is found in this field the packet MUST be discarded. - The currently mandatory file transfer protocol is SFTP. - The SFTP protocol is defined in [SFTP]. - - o Data (variable length) - Arbitrary file transfer data. The - contents and encoding of this field is dependent of the usage - of this payload and the type of the file transfer protocol. - When this payload is used to perform the Key Agreement - protocol, this field include the Key Agreement Payload, - as defined in the section 2.3.20 Key Agreement Payload. - When this payload is used to send the actual file transfer - protocol data, the encoding is defined in the corresponding - file transfer protocol. - - -2.3.23 Resume Client Payload - - This payload is used by client to resume its detached session in the - SILC Network. A client is able to detach itself from the network by - sending SILC_COMMAND_DETACH command to its server. The network - connection to the client is lost but the client remains as valid - client in the network. The client is able to resume the session back - by sending this packet and including the old Client ID, and an - Authentication Payload [SILC1] which the server use to verify with - the detached client’s public key. This also implies that the - mandatory authentication method is public key authentication. - - Server or router that receives this from the client also sends this, - without the Authentication Payload, to routers in the network so that - they know the detached client has resumed. Refer to the [SILC1] for - detailed description how the detaching and resuming procedure is - performed. - - The payload may only be sent with SILC_PACKET_RESUME CLIENT packet. It - MUST NOT be sent in any other packet type. The following diagram - represents the Resume Client Payload. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Client ID Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Client ID ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Authentication Payload ~ - - - -Riikonen [Page 48] - -Internet Draft XXX - - - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 24: Resume Client Payload - - - o Client ID Length (1 byte) - The length of the Client ID - field not including any other field. - - o Client ID (variable length) - The detached client’s Client - ID. The client that sends this payload must know the Client - ID. - - o Authentication Payload (variable length) - The authentication - payload that the server will verify with the detached client’s - public key. If the server doesn’t know the public key, it must - retrieve it for example with SILC_COMMAND_GETKEY command. - - - -2.4 SILC ID Types - - ID’s are used in the SILC network to associate different entities. - The following ID’s has been defined to be used in the SILC network. - - 0 No ID - - This is used when other ID type is available at the time. - - 1 Server ID - - Server ID to associate servers. See the format of - this ID in [SILC1]. - - 2 Client ID - - Client ID to associate clients. See the format of - this ID in [SILC1]. - - 3 Channel ID - - Channel ID to associate channels. See the format of - this ID in [SILC1]. - - When encoding different IDs into the ID Payload, all fields are always - in MSB first order. The IP address, port, and/or the random number - are encoded in the MSB first order. - - - - -Riikonen [Page 49] - -Internet Draft XXX - - -2.5 Packet Encryption And Decryption - - SILC packets are encrypted almost entirely. Only the MAC at the end - of the packet is never encrypted. The SILC Packet header is the first - part of a packet to be encrypted and it is always encrypted with the - key of the next receiver of the packet. The data payload area of the - packet is always entirely encrypted and it is usually encrypted with - the next receiver’s key. However, there are some special packet types - and packet payloads that require special encryption process. These - special cases are described in the next sections. First is described - the normal packet encryption process. - - - -2.5.1 Normal Packet Encryption And Decryption - - Normal SILC packets are encrypted with the session key of the next - receiver of the packet. The entire SILC Packet header and the packet - data payload is is encrypted with the same key. Padding of the packet - is also encrypted always with the session key, also in special cases. - Computed MAC of the packet MUST NOT be encrypted. - - Decryption process in these cases are straightforward. The receiver - of the packet MUST first decrypt the SILC Packet header, or some parts - of it, usually first 16 bytes of it. Then the receiver checks the - packet type from the decrypted part of the header and can determine - how the rest of the packet must be decrypted. If the packet type is - any of the special cases described in the following sections the packet - decryption is special. If the packet type is not among those special - packet types rest of the packet can be decrypted with the same key. - At this point the receiver is also able to determine the length of the - packet. - - With out a doubt, this sort of decryption processing causes some - overhead to packet decryption, but never the less, is required. - - The MAC of the packet is also verified at this point. The MAC is - computed from the ciphertext of the packet so it can be verified - at this stage. The length of the packet need to be known to be able - to verify the MAC from the ciphertext so the first 16 bytes need to - be decrypted to determine the packet length. However, the MAC MUST - be verified from the entire ciphertext. - - -2.5.2 Channel Message Encryption And Decryption - - Channel Messages (Channel Message Payload) are always encrypted with - the channel specific key. However, the SILC Packet header is not - - - -Riikonen [Page 50] - -Internet Draft XXX - - - encrypted with that key. As in normal case, the header is encrypted - with the key of the next receiver of the packet. Note that, in this - case the encrypted data area is not touched at all; it MUST NOT be - re-encrypted with the session key. - - Receiver of a channel message, who ever that is, is REQUIRED to decrypt - the SILC Packet header to be able to recognize the packet to be as - channel message. This is same procedure as for normal SILC packets. - As the receiver founds the packet to be channel message, rest of the - packet processing is special. Rest of the SILC Packet header is - decrypted with the same session key along with the padding of the - packet. After that the packet is protected with the channel specific - key and thus can be decrypted only if the receiver is the client on - the channel. See section 2.7 Packet Padding Generation for more - information about padding on special packets. - - If the receiver of the channel message is router which is routing the - message to another router then it MUST decrypt the Channel Message - payload too. Between routers (that is, between cells) channel messages - are protected with session keys shared between the routers. This - causes another special packet processing for channel messages. If - the channel message is received from another router then the entire - packet, including Channel Message payload, MUST be encrypted with the - session key shared between the routers. In this case the packet - decryption process is as with normal SILC packets. Hence, if the - router is sending channel message to another router the Channel - Message payload MUST have been decrypted and MUST be re-encrypted - with the session key shared between the another router. In this - case the packet encryption is as with any normal SILC packet. - - It must be noted that this is only when the channel messages are sent - from router to another router. In all other cases the channel - message encryption and decryption is as described before. This - different processing of channel messages with router to router - connection is because channel keys are cell specific. All cells have - their own channel keys thus the channel message traveling from one - cell to another MUST be protected as it would be any normal SILC - packet. - - If the SILC_CMODE_PRIVKEY channel mode has been set for the channel - then the router cannot decrypt the packet as it does not know the - private key. In this case the entire packet MUST be encrypted with - the session key and sent to the router. The router receiving the - packet MUST check the channel mode and decrypt the packet accordingly. - - -2.5.3 Private Message Encryption And Decryption - - - - -Riikonen [Page 51] - -Internet Draft XXX - - - By default, private message in SILC are protected by session keys. - In this case the private message encryption and decryption process is - equivalent to normal packet encryption and decryption. - - However, private messages MAY be protected with private message key - which causes the packet to be special packet. The procedure in this - case is very much alike to channel packets. The actual private message - is encrypted with the private message key and other parts of the - packet is encrypted with the session key. See 2.7 Packet Padding - Generation for more information about padding on special packets. - - The difference from channel message processing is that server or router - en route never decrypts the actual private message, as it does not - have the key to do that. Thus, when sending packets between router - the processing is same as in any other case as well; the packet’s header - and padding is protected by the session key and the data area is not - touched and is not re-encrypted. - - The true receiver of the private message is able to decrypt the private - message as it shares the key with the sender of the message. - - -2.6 Packet MAC Generation - - Data integrity of a packet is protected by including a message - authentication code (MAC) at the end of the packet. The MAC is computed - from shared secret MAC key, that is established by the SILC Key Exchange - protocol, from packet sequence number, and from the encrypted packet - data. The MAC is always computed after packet is encrypted. This is - so called Encrypt-Then-MAC order; packet is first encrypted, then MAC - is computed from the encrypted data. - - The MAC is computed from entire packet. Every bit of data in the packet, - including SILC Packet Header is used in the MAC computing. This way - the entire packet becomes authenticated. - - Hence, packet’s MAC generation is as follows: - - mac = MAC(key, sequence number | Encrypted SILC packet) - - The MAC key is negotiated during the SKE protocol. The sequence number - is a 32 bit MSB first value starting from zero for first packet and - increasing for subsequent packets, finally wrapping after 2^32 packets. - The value is never reset, not even after rekey has been performed. - However, rekey MUST be performed before the sequence number wraps - and repeats from zero. Note that the sequence number is incremented only - when MAC is computed for a packet. If packet is not encrypted and MAC is - not computed then the sequence number is not incremented. Hence, the - - - -Riikonen [Page 52] - -Internet Draft XXX - - - sequence number is zero for the very first encrypted packet. - - See [SILC1] for defined and allowed MAC algorithms. - - -2.7 Packet Padding Generation - - Padding is needed in the packet because the packet is encrypted. It - always MUST be multiple by eight (8) or multiple by the block size - of the cipher, which ever is larger. The padding is always encrypted. - - For normal packets the padding is added after the SILC Packet Header - and between the Data Payload area. The padding for normal packets - may be calculated as follows: - - padding_length = 16 - (packet_length mod block_size) - if (padding_length < 8) - padding_length += block_size - - The ‘block_size’ is the block size of the cipher. The maximum padding - length is 128 bytes, and minimum is 8 bytes. For example, packets that - include a passphrase or a password for authentication purposes SHOULD - pad the packet up to the maximum padding length. The maximum padding - is calculated as follows: - - padding_length = 128 - (packet_length mod block_size) - - For special packets the padding calculation is different as special - packets may be encrypted differently. In these cases the encrypted - data area MUST already be multiple by the block size thus in this case - the padding is calculated only for SILC Packet Header, not for any - other area of the packet. The same algorithm works in this case as - well, except that the ‘packet length’ is now the SILC Packet Header - length. - - The padding MUST be random data, preferably, generated by - cryptographically strong random number generator for each packet - separately. - - -2.8 Packet Compression - - SILC Packets MAY be compressed. In this case the data payload area - is compressed and all other areas of the packet MUST remain as they - are. After compression is performed for the data area, the length - field of Packet Header MUST be set to the compressed length of the - data. - - - - -Riikonen [Page 53] - -Internet Draft XXX - - - The compression MUST always be applied before encryption. When - the packet is received and decrypted the data area MUST be decompressed. - Note that the true sender of the packet MUST apply the compression and - the true receiver of the packet MUST apply the decompression. Any - server or router en route SHOULD NOT decompress the packet. - - -2.9 Packet Sending - - The sender of the packet MUST assemble the SILC Packet Header with - correct values. It MUST set the Source ID of the header as its own - ID, unless it is forwarding the packet. It MUST also set the Destination - ID of the header to the true destination. If the destination is client - it will be Client ID, if it is server it will be Server ID and if it is - channel it will be Channel ID. - - If the sender wants to compress the packet it MUST apply the - compression now. Sender MUST also compute the padding as described - in above sections. Then sender MUST encrypt the packet as has been - described in above sections according whether the packet is normal - packet or special packet. Then sender MUST compute the MAC of the - packet. The computed MAC MUST NOT be encrypted. - - -2.10 Packet Reception - - On packet reception the receiver MUST check that all fields in the - SILC Packet Header are valid. It MUST check the flags of the - header and act accordingly. It MUST also check the MAC of the packet - and if it is to be failed the packet MUST be discarded. Also if the - header of the packet includes any bad fields the packet MUST be - discarded. - - See above sections on the decryption process of the received packet. - - The receiver MUST also check that the ID’s in the header are valid - ID’s. Unsupported ID types or malformed ID’s MUST cause packet - rejection. The padding on the reception is always ignored. - - The receiver MUST also check the packet type and start parsing the - packet according to the type. However, note the above sections on - special packet types and their parsing. - - -2.11 Packet Routing - - Routers are the primary entities in the SILC network that takes care - of packet routing. However, normal servers routes packets as well, for - - - -Riikonen [Page 54] - -Internet Draft XXX - - - example, when they are routing channel message to the local clients. - Routing is quite simple as every packet tells the true origin and the - true destination of the packet. - - It is still RECOMMENDED for routers that has several routing connections - to create route cache for those destinations that has faster route than - the router’s primary route. This information is available for the router - when other router connects to the router. The connecting party then - sends all of its locally connected clients, servers and channels. These - informations helps to create the route cache. Also, when new channels - are created to a cell its information is broadcasted to all routers - in the network. Channel ID’s are based on router’s ID thus it is easy - to create route cache based on these informations. If faster route for - destination does not exist in router’s route cache the packet MUST be - routed to the primary route (default route). - - However, there are some issues when routing channel messages to group - of users. Routers are responsible of routing the channel message to - other routers, local servers and local clients as well. Routers MUST - send the channel message to only one router in the network, preferably - to the shortest route to reach the channel users. The message can be - routed into either upstream or downstream. After the message is sent - to a router in the network it MUST NOT be sent to any other router in - either same route or other route. The message MUST NOT be routed to - the router it came from. - - When routing for example private messages they should be routed to the - shortest route always to reach the destination client as fast as possible. - - For server which receives a packet to be routed to an entity that is - indirectly connected to the sender, the server MUST check whether that - particular packet type is allowed to be routed to that destination. Not - all packets may be sent by some odd entity to for example a local client, - or to some remote server or router, that is indirectly connected to the - sender. See section 2.3 SILC Packet Types and paragraph about indirectly - connected entities and sending packets to them. That section defines the - packets that may be sent to indirectly connected entities. When a server - or a router receives a packet that may be sent to indirectly connected - entity and it is destined to other entity except that server, it MUST - route it further either to shortest route or to the primary route to reach - that destination. - - Routers form a ring in the SILC network. However, routers may have other - direct connections to other routers in the network too. This can cause - interesting routing problems in the network. Since the network is a ring, - the packets usually should be routed into clock-wise direction, or if it - cannot be used then always counter clock-wise (primary route) direction. - Problems may arise when a faster direct route exists and router is routing - - - -Riikonen [Page 55] - -Internet Draft XXX - - - a channel message. Currently channel messages must be routed either - in upstream or downstream, they cannot be routed to other direct routes. - The SILC protocol should have a shortest path discovery protocol, and some - existing routing protocol, that can handle a ring network with other - direct routes inside the ring (so called hybrid ring-mesh topology), - MAY be defined to be used with the SILC protocol. Additional - specifications MAY be written on the subject to permeate this - specification. - - -2.12 Packet Broadcasting - - SILC packets MAY be broadcasted in SILC network. However, only router - server may send or receive broadcast packets. Client and normal server - MUST NOT send broadcast packets and they MUST ignore broadcast packets - if they receive them. Broadcast packets are sent by setting Broadcast - flag to the SILC packet header. - - Broadcasting packets means that the packet is sent to all routers in - the SILC network, except to the router that sent the packet. The router - receiving broadcast packet MUST send the packet to its primary route. - The fact that SILC routers may have several router connections can - cause problems, such as race conditions inside the SILC network, if - care is not taken when broadcasting packets. Router MUST NOT send - the broadcast packet to any other route except to its primary route. - - If the primary route of the router is the original sender of the packet - the packet MUST NOT be sent to the primary route. This may happen - if router has several router connections and some other router uses - the router as its primary route. - - Routers use broadcast packets to broadcast for example information - about newly registered clients, servers, channels etc. so that all the - routers may keep these informations up to date. - - -3 Security Considerations - - Security is central to the design of this protocol, and these security - considerations permeate the specification. Common security considerations - such as keeping private keys truly private and using adequate lengths for - symmetric and asymmetric keys must be followed in order to maintain the - security of this protocol. - - -4 References - - [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), - - - -Riikonen [Page 56] - -Internet Draft XXX - - - Protocol Specification", Internet Draft, May 2002. - - [SILC3] Riikonen, P., "SILC Key Exchange and Authentication - Protocols", Internet Draft, May 2002. - - [SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002. - - [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol", - RFC 1459, May 1993. - - [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, - April 2000. - - [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC - 2811, April 2000. - - [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC - 2812, April 2000. - - [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC - 2813, April 2000. - - [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", - Internet Draft. - - [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440, - November 1998. - - [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693, - September 1999. - - [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key - Infrastructure, Certificate and CRL Profile", RFC 2459, - January 1999. - - [Schneier] Schneier, B., "Applied Cryptography Second Edition", - John Wiley & Sons, New York, NY, 1996. - - [Menezes] Menezes, A., et al, "Handbook of Applied Cryptography", - CRC Press 1997. - - [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", - RFC 2412, November 1998. - - [ISAKMP] Maughan D., et al, "Internet Security Association and - Key Management Protocol (ISAKMP)", RFC 2408, November - 1998. - - - - -Riikonen [Page 57] - -Internet Draft XXX - - - [IKE] Harkins D., and Carrel D., "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message - Authentication", RFC 2104, February 1997. - - [PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography - Specifications, Version 2.0", RFC 2437, October 1998. - - [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [SFTP] Ylonen T., and Lehtinen S., "Secure Shell File Transfer - Protocol", Internet Draft, March 2001. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", RFC 3629, November 2003. - - -5 Author’s Address - - Pekka Riikonen - Snellmaninkatu 34 A 15 - 70100 Kuopio - Finland - - EMail: priikone@iki.fi - - -6 Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - - - -Riikonen [Page 58] - -Internet Draft XXX - - - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Riikonen [Page 59] - \ No newline at end of file +Draft Author(s): +Pekka Riikonen silc-toolkit-0.9.12/doc/draft-riikonen-silc-pp-09.txt /home/jas/rfc/draft-riikonen-silc-pp-09.txt differ: byte 2, line 2 tar xfz /data/debian/pool/main/s/silc-toolkit/silc-toolkit_0.9.12.orig.tar.gz silc-toolkit-0.9.12/doc/draft-riikonen-silc-spec-08.txt 43420f63d6072c41edf1f7d36f9c8a39 - silc-toolkit-0.9.12/doc/draft-riikonen-silc-spec-08.txt 3de8ad430d4c48f627ef79b8645c789e - /home/jas/rfc/draft-riikonen-silc-spec-08.txt MISMATCH draft-riikonen-silc-spec-08.txt --- silc-toolkit-0.9.12/doc/draft-riikonen-silc-spec-08.txt 2004-02-29 16:11:28.000000000 +0100 +++ /home/jas/rfc/draft-riikonen-silc-spec-08.txt 2004-03-29 05:53:32.000000000 +0200 @@ -74,13 +74,13 @@ 3.1 Client .................................................... 9 3.1.1 Client ID ........................................... 9 3.2 Server .................................................... 10 - 3.2.1 Server’s Local ID List .............................. 11 + 3.2.1 Server's Local ID List .............................. 11 3.2.2 Server ID ........................................... 12 3.2.3 SILC Server Ports ................................... 12 3.3 Router .................................................... 13 - 3.3.1 Router’s Local ID List .............................. 13 - 3.3.2 Router’s Global ID List ............................. 14 - 3.3.3 Router’s Server ID .................................. 14 + 3.3.1 Router's Local ID List .............................. 13 + 3.3.2 Router's Global ID List ............................. 14 + 3.3.3 Router's Server ID .................................. 14 3.4 Channels .................................................. 15 3.4.1 Channel ID .......................................... 16 3.5 Operators ................................................. 16 @@ -133,7 +133,7 @@ 4.11 Detaching and Resuming a Session ......................... 48 5 Security Considerations ....................................... 49 6 References .................................................... 50 - 7 Author’s Address .............................................. 52 + 7 Author's Address .............................................. 52 Appendix A ...................................................... 52 Appendix B ...................................................... 54 Full Copyright Statement ........................................ 54 @@ -472,20 +472,20 @@ interface of the SILC services for end user. Clients are distinguished from other clients by unique Client ID. Client ID is a 128 bit ID that is used in the communication in the SILC network. The client ID is - based on the user’s IP address and nickname. User use logical nicknames + based on the user's IP address and nickname. User use logical nicknames in communication which are then mapped to the corresponding Client ID. Client IDs are low level identifications and should not be seen by the end user. Clients provide other information about the end user as well. Information such as the nickname of the user, username and the host name of the end - user and user’s real name. See section 3.2 Server for information of + user and user's real name. See section 3.2 Server for information of the requirements of keeping this information. The nickname selected by the user is not unique in the SILC network. There can be 2^8 same nicknames for one IP address. As for comparison to IRC [IRC] where nicknames are unique this is a fundamental difference - between SILC and IRC. This typically causes the server names or client’s + between SILC and IRC. This typically causes the server names or client's host names to be used along with the nicknames on user interface to identify specific users when sending messages. This feature of SILC makes IRC style nickname-wars obsolete as no one owns their nickname; @@ -534,7 +534,7 @@ o MD5 hash - MD5 hash value of the case folded nickname is truncated taking 88 bits from the start of the hash value. - This hash value is used to search the user’s Client ID + This hash value is used to search the user's Client ID from the ID lists. Note that the nickname MUST be prepared using the stringprep [RFC3454] profile described in the Appendix A before computing the MD5 hash. See also the @@ -574,15 +574,15 @@ by the client is destined outside the local server it is always sent to the router server for further routing. Server may only have one active connection to router on same port. Normal server MUST NOT connect to other - cell’s router except in situations where its cell’s router is unavailable. + cell's router except in situations where its cell's router is unavailable. -3.2.1 Server’s Local ID List +3.2.1 Server's Local ID List Normal server keeps various information about the clients and their end users connected to it. Every normal server MUST keep list of all locally connected clients, Client IDs, nicknames, usernames and host names and - user’s real name. Normal servers only keeps local information and it + user's real name. Normal servers only keeps local information and it does not keep any global information. Hence, normal servers knows only about their locally connected clients. This makes servers efficient as they do not have to worry about global clients. Server is also responsible @@ -694,7 +694,7 @@ global information and keeping them up to date at all time. -3.3.1 Router’s Local ID List +3.3.1 Router's Local ID List Router server as well MUST keep local list of connected clients and locally created channels. However, this list is extended to include all @@ -702,7 +702,7 @@ normal servers. However, on router this list is a lot smaller since routers do not need - to keep information about user’s nickname, username and host name and real + to keep information about user's nickname, username and host name and real name since these are not needed by the router. The router keeps only information that it needs. @@ -711,7 +711,7 @@ server list - All servers in the cell o Server name o Server ID - o Router’s Server ID + o Router's Server ID o Sending key o Receiving key @@ -733,25 +733,25 @@ Note that locally connected clients and other information include all the - same information as defined in section section 3.2.1 Server’s Local ID + same information as defined in section section 3.2.1 Server's Local ID List. Router MAY also cache same detailed information for other clients if needed. -3.3.2 Router’s Global ID List +3.3.2 Router's Global ID List Router server MUST also keep global list. Normal servers do not have global list as they know only about local information. Global list includes all the clients on SILC, their Client IDs, all created channels and their Channel IDs and all servers and routers on SILC and their Server IDs. That is said, global list is for global information and the - list must not include the local information already on the router’s local + list must not include the local information already on the router's local list. Note that the global list does not include information like nicknames, - usernames and host names or user’s real names. Router does not need to + usernames and host names or user's real names. Router does not need to keep these informations as they are not needed by the router. This - information is available from the client’s server which maybe queried + information is available from the client's server which maybe queried when needed. Hence, global list includes: @@ -759,7 +759,7 @@ server list - All servers in SILC o Server name o Server ID - o Router’s Server ID + o Router's Server ID client list - All clients in SILC o Client ID @@ -771,9 +771,9 @@ -3.3.3 Router’s Server ID +3.3.3 Router's Server ID - Router’s Server ID is equivalent to normal Server ID. As routers are + Router's Server ID is equivalent to normal Server ID. As routers are normal servers same types of IDs applies for routers as well. See section 3.2.2 Server ID. @@ -815,7 +815,7 @@ privileges. Basically, channel founder can fully operate the channel and all of its modes. The privileges are limited only to the particular channel. There can be only one channel founder per - channel. Channel founder supersedes channel operator’s privileges. + channel. Channel founder supersedes channel operator's privileges. Channel founder privileges cannot be removed by any other operator on channel. When channel founder leaves the channel there is no channel @@ -855,23 +855,23 @@ 64 bit Channel ID based on IPv4 addresses: - 32 bit Router’s Server ID IP address (bits 1-32) - 16 bit Router’s Server ID port (bits 33-48) + 32 bit Router's Server ID IP address (bits 1-32) + 16 bit Router's Server ID port (bits 33-48) 16 bit Random number or counter 160 bit Channel ID based on IPv6 addresses: - 128 bit Router’s Server ID IP address (bits 1-128) - 16 bit Router’s Server ID port (bits 129-144) + 128 bit Router's Server ID IP address (bits 1-128) + 16 bit Router's Server ID port (bits 129-144) 16 bit Random number or counter - o Router’s Server ID IP address - Indicates the IP address of + o Router's Server ID IP address - Indicates the IP address of the router of the cell where this channel is created. This is - taken from the router’s Server ID. This way SILC router knows + taken from the router's Server ID. This way SILC router knows where this channel resides in the SILC network. - o Router’s Server ID port - Indicates the port of the channel on - the server. This is taken from the router’s Server ID. + o Router's Server ID port - Indicates the port of the channel on + the server. This is taken from the router's Server ID. o Random number or counter - To further randomize the Channel ID. Another choice is to use a counter starting from zero (0). @@ -908,7 +908,7 @@ Client usually sends the commands and server replies by sending a reply packet to the command. Server MAY also send commands usually to serve - the original client’s request. Usually server cannot send commands to + the original client's request. Usually server cannot send commands to clients, however there MAY be commands that allow the server to send commands to client. By default servers MAY send commands only to other servers and routers. @@ -1000,9 +1000,9 @@ packet. The original sender, for example client, assembles the packet and the packet header and server or router between the sender and the receiver MUST NOT change the packet header. Note however, that some - packets such as commands may be resent by a server to serve the client’s + packets such as commands may be resent by a server to serve the client's original command. In this case the command packet sent by the server - includes the server’s IDs as it is a different packet. When server + includes the server's IDs as it is a different packet. When server or router receives a packet it MUST verify that the Source ID is @@ -1255,7 +1255,7 @@ cryptography function selected in the SKE protocol, unless otherwise stated in the context where this payload is used. The public key is SILC style public key unless certificates are used. The ID is the - entity’s ID (Client or Server ID) which is authenticating itself. The + entity's ID (Client or Server ID) which is authenticating itself. The ID encoding is described in [SILC2]. The random bytes are non-zero random bytes of length between 128 and 4096 bytes, and will be included into the Public Data field as is. @@ -1633,14 +1633,14 @@ Examples of an identifier: - ‘UN=priikone, HN=poseidon.pspt.fi, E=priikone@poseidon.pspt.fi’ + `UN=priikone, HN=poseidon.pspt.fi, E=priikone@poseidon.pspt.fi' - ‘UN=sam, HN=dummy.fi, RN=Sammy Sam, O=Company XYZ, C=Finland’ + `UN=sam, HN=dummy.fi, RN=Sammy Sam, O=Company XYZ, C=Finland' At least user name (UN) and host name (HN) MUST be provided as - identifier. The fields are separated by commas (‘,’). If - comma is in the identifier string it must be escaped as ‘\,’, - for example, ‘O=Company XYZ\, Inc.’. Other characters that + identifier. The fields are separated by commas (`,'). If + comma is in the identifier string it must be escaped as `\,', + for example, `O=Company XYZ\, Inc.'. Other characters that require escaping are listed in [RFC2253] and are to be escaped as defined therein. @@ -1802,7 +1802,7 @@ many other special characters are prohibited. All identifier strings are case folded and comparing the identifier strings MUST be done as caseless matching. Also, identifier strings may not include any - commas (’,’), ’@’, ’!’ or any wildcard characters, as defined in the + commas (','), '@', '!' or any wildcard characters, as defined in the stringprep profile in Appendix A. In general, the identifier strings does not have a maximum length. @@ -1842,7 +1842,7 @@ Backup router must know everything that the primary router knows to be able to take over the tasks of the primary router. It is the primary - router’s responsibility to feed the data to the backup router. If the + router's responsibility to feed the data to the backup router. If the backup router does not know all the data in the case of failure some @@ -1872,9 +1872,9 @@ failure of the primary router they must start using the connection to the first backup router as their primary route. - Also, if any other router in the network is using the cell’s primary + Also, if any other router in the network is using the cell's primary router as its own primary router, it must also have passive connection - to the cell’s backup router. It too is prepared to switch to use the + to the cell's backup router. It too is prepared to switch to use the backup router as its new primary router as soon as the original primary router becomes unresponsive. @@ -2099,7 +2099,7 @@ This section describes various SILC procedures such as how the connections are created and registered, how channels are created and so on. The references [SILC2], [SILC3] and [SILC4] permeate this - section’s definitions. + section's definitions. 4.1 Creating Client Connection @@ -2118,7 +2118,7 @@ Typical server implementation would keep a list of connections that it allows to connect to the server. The implementation would check, for - example, the connecting client’s IP address from the connection list + example, the connecting client's IP address from the connection list before the SILC Key Exchange protocol has been started. The reason for this is that if the host is not allowed to connect to the server there is no reason to perform the key exchange protocol. @@ -2150,7 +2150,7 @@ that all SILC packets from the client MUST have the Client ID as the Source ID in the SILC Packet Header, described in [SILC2]. - Client MUST also get the server’s Server ID that is to be used as + Client MUST also get the server's Server ID that is to be used as Destination ID in the SILC Packet Header when communicating with the server (for example when sending commands to the server). The ID may be resolved in two ways. Client can take the ID from an @@ -2203,10 +2203,10 @@ After server and router have successfully performed the key exchange and connection authentication protocol, the server MUST register itself to the router by sending SILC_PACKET_NEW_SERVER packet. This packet - includes the server’s Server ID that it has created by itself and + includes the server's Server ID that it has created by itself and other relevant information about the server. The router receiving the ID MUST verify that the IP address in the Server ID is same as the - server’s real IP address. + server's real IP address. After router has received the SILC_PACKET_NEW_SERVER packet it distributes the information about newly registered server to all routers @@ -2217,7 +2217,7 @@ is to get the ID from previously received packet. The server MAY also use SILC_COMMAND_INFO command to resolve the ID. Server MUST also start using its own Server ID as Source ID in SILC Packet Header and the - router’s Server ID as Destination when communicating with the router. + router's Server ID as Destination when communicating with the router. 4.2.1 Announcing Clients, Channels and Servers @@ -2230,7 +2230,7 @@ All clients are announced by compiling a list of ID Payloads into the SILC_PACKET_NEW_ID packet. All channels are announced by compiling a list of Channel Payloads into the SILC_PACKET_NEW_CHANNEL packet. - Channels’ mode, founder public key, channel public keys, and other + Channels' mode, founder public key, channel public keys, and other channel mode specific data is announced by sending the SILC_NOTIFY_TYPE_CMODE_CHANGE notify list. @@ -2248,7 +2248,7 @@ Also, the channel users on the channels must be announced by compiling a list of Notify Payloads with the SILC_NOTIFY_TYPE_JOIN notify type - into the SILC_PACKET_NOTIFY packet. The users’ modes on the channel + into the SILC_PACKET_NOTIFY packet. The users' modes on the channel must also be announced by compiling list of Notify Payloads with the SILC_NOTIFY_TYPE_CUMODE_CHANGE notify type into the SILC_PACKET_NOTIFY packet. @@ -2256,12 +2256,12 @@ The router MUST also announce the local servers by compiling list of ID Payloads into the SILC_PACKET_NEW_ID packet. - Also, clients’ modes (user modes in SILC) MUST be announced. This is + Also, clients' modes (user modes in SILC) MUST be announced. This is done by compiling a list of Notify Payloads with SILC_NOTIFY_UMODE_CHANGE - notify type into the SILC_PACKET_NOTIFY packet. Also, channels’ topics + notify type into the SILC_PACKET_NOTIFY packet. Also, channels' topics MUST be announced by compiling a list of Notify Payloads with the SILC_NOTIFY_TOPIC_SET notify type into the SILC_PACKET_NOTIFY packet. - Also, channel’s invite and ban lists MUST be announced by compiling list + Also, channel's invite and ban lists MUST be announced by compiling list of Notify Payloads with the SILC_NOTIFY_TYPE_INVITE and SILC_NOTIFY_TYPE_BAN notify types, respectively, into the SILC_PACKET_NOTIFY packet. @@ -2321,7 +2321,7 @@ also be sent to the local clients on the channel. The new channel key is also sent to the router and to local clients on the channel. - If the channel does not exist in the local list the client’s command + If the channel does not exist in the local list the client's command MUST be sent to the router which will then perform the actual joining procedure. When server receives the reply to the command from the router it MUST be sent to the client which sent the command originally. @@ -2339,7 +2339,7 @@ the SILC_NOTIFY_TYPE_JOIN notify type to local clients on the channel and to local servers that have clients on the channel. - If the channel does not exist on the router’s local list it MUST + If the channel does not exist on the router's local list it MUST check the global list whether the channel exists at all. If it does the client is joined to the channel as described previously. If the channel does not exist the channel is created and the client @@ -2358,11 +2358,11 @@ If the router created the channel in the process, information about the new channel MUST be broadcast to all routers. This is done by - broadcasting SILC_PACKET_NEW_CHANNEL packet to the router’s primary + broadcasting SILC_PACKET_NEW_CHANNEL packet to the router's primary route. When the router joins the client to the channel it MUST also send information about newly joined client to all routers in the SILC network. This is done by broadcasting the SILC_NOTIFY_TYPE_JOIN notify - type to the router’s primary route. + type to the router's primary route. It is important to note that new channel key is created always when new client joins to channel, whether the channel has existed previously @@ -2434,7 +2434,7 @@ other packet as well. The Source ID in the SILC Packet Header MUST be the ID of the sender of the message. - If the sender of a private message does not know the receiver’s Client + If the sender of a private message does not know the receiver's Client ID, it MUST resolve it from server. There are two ways to resolve the client ID from server; it is RECOMMENDED that client implementations send SILC_COMMAND_IDENTIFY command to receive the Client ID. Client @@ -2498,7 +2498,7 @@ used in the key material processing is the one that HMAC algorithm is defined to use. If the SILC_PACKET_PRIVATE_MESSAGE_KEY was not sent at all, then the hash algorithm to be used SHOULD be SHA1. In this case - also, implementations SHOULD use the SILC protocol’s mandatory cipher + also, implementations SHOULD use the SILC protocol's mandatory cipher and HMAC in private message encryption. @@ -2556,11 +2556,11 @@ If PFS flag was not set, which is the default case, then re-key is done without executing SKE protocol. In this case, the new key is created by - providing the current sending encryption key to the SKE protocol’s key + providing the current sending encryption key to the SKE protocol's key processing function. The process is described in the section Processing the Key Material in [SILC3]. The difference in the processing is that the initial data for the hash function is the current sending encryption - key and not the SKE’s KEY and HASH values. Other than that, the key + key and not the SKE's KEY and HASH values. Other than that, the key processing is equivalent to normal SKE negotiation. After both parties have regenerated the session key, both MUST send @@ -2585,7 +2585,7 @@ for detailed description of all commands. However, if the server is not able to process the command, it is sent to - the server’s router. This is case for example with commands such as + the server's router. This is case for example with commands such as SILC_COMMAND_JOIN and SILC_COMMAND_WHOIS commands. However, there are other commands as well [SILC4]. For example, if client sends the WHOIS command requesting specific information about some client the server must @@ -2614,7 +2614,7 @@ When remote client connection is closed the server MUST send the notify type SILC_NOTIFY_TYPE_SIGNOFF to its primary router and to all channels - the client was joined. The server MUST also save the client’s information + the client was joined. The server MUST also save the client's information for a period of time for history purposes. When remote server or router connection is closed the server or router @@ -2622,7 +2622,7 @@ from the SILC Network. The server or router MUST also send the notify type SILC_NOTIFY_TYPE_SERVER_SIGNOFF to its primary router and to all local clients that are joined on the same channels with the remote - server’s or router’s clients. + server's or router's clients. Router server MUST also check whether some client in the local cell is watching for the nickname this client has, and send the @@ -2672,16 +2672,16 @@ completed the client MUST NOT send SILC_PACKET_NEW_CLIENT packet, but MUST send SILC_PACKET_RESUME_CLIENT packet. This packet is used to perform the resuming procedure. The packet MUST include the detached - client’s Client ID, which the client must know. It also includes + client's Client ID, which the client must know. It also includes Authentication Payload which includes signature computed with the - client’s private key. The signature is computed as defined in the + client's private key. The signature is computed as defined in the section 3.9.1. Thus, the authentication method MUST be based in public key authentication. When server receive the SILC_PACKET_RESUME_CLIENT packet it MUST do the following: Server checks that the Client ID is valid client and that it has the SILC_UMODE_DETACHED mode set. Then it verifies - the Authentication Payload with the detached client’s public key. + the Authentication Payload with the detached client's public key. If it does not have the public key it retrieves it by sending SILC_COMMAND_GETKEY command to the server that has the public key from @@ -2718,7 +2718,7 @@ same server that it originally came from. They must update their caches according to this. The server that now owns the client session MUST check whether the Client ID of the resumed client is based - on the server’s Server ID. If it is not it creates a new Client + on the server's Server ID. If it is not it creates a new Client ID and send SILC_NOTIFY_TYPE_NICK_CHANGE to the network. It MUST also send the channel keys of all channels that the client has joined to the client since it does not have them. Whether the @@ -2753,7 +2753,7 @@ security of this protocol. Special attention must also be paid to the servers and routers that are - running the SILC service. The SILC protocol’s security depends greatly + running the SILC service. The SILC protocol's security depends greatly on the security and the integrity of the servers and administrators that are running the service. It is recommended that some form of registration is required by the server and router administrator prior to acceptance to @@ -2784,12 +2784,12 @@ If this is unacceptable for the client or end user, the private keys negotiated outside the SILC Network should always be used. In the end - it is the implementor’s choice whether to negotiate private keys by + it is the implementor's choice whether to negotiate private keys by default or whether to use the keys generated by the servers. It is also recommended that router operators in the SILC Network would form a joint forum to discuss the router and SILC Network management - issues. Also, router operators along with the cell’s server operators + issues. Also, router operators along with the cell's server operators should have a forum to discuss the cell management issues. @@ -2892,7 +2892,7 @@ Strings ("stringprep")", RFC 3454, December 2002. -7 Author’s Address +7 Author's Address Pekka Riikonen Snellmaninkatu 34 A 15 silc-toolkit-0.9.12/doc/draft-riikonen-silc-spec-08.txt /home/jas/rfc/draft-riikonen-silc-spec-08.txt differ: byte 2848, line 77 pkg stunnel ver 2:3.26-11 lastfile stunnel_3.26.orig.tar.gz files stunnel-3.26/doc/rfc2246.txt tar xfz /data/debian/pool/main/s/stunnel/stunnel_3.26.orig.tar.gz stunnel-3.26/doc/rfc2246.txt 6a7d8e6a395facf7022753ca62e73847 - stunnel-3.26/doc/rfc2246.txt 6a7d8e6a395facf7022753ca62e73847 - /home/jas/rfc/rfc2246.txt MATCH rfc2246.txt pkg subversion ver 1.3.2-5 lastfile subversion_1.3.2.orig.tar.gz files subversion-1.3.2/notes/old/draft-korn-vcdiff-01.txt tar xfz /data/debian/pool/main/s/subversion/subversion_1.3.2.orig.tar.gz subversion-1.3.2/notes/old/draft-korn-vcdiff-01.txt 37019f808e1af64864853a67526cfe19 - subversion-1.3.2/notes/old/draft-korn-vcdiff-01.txt bdf022664af1e65b6046f811569e4fa3 - /home/jas/rfc/draft-korn-vcdiff-01.txt MISMATCH draft-korn-vcdiff-01.txt --- subversion-1.3.2/notes/old/draft-korn-vcdiff-01.txt 2003-01-13 23:43:13.000000000 +0100 +++ /home/jas/rfc/draft-korn-vcdiff-01.txt 2000-11-09 14:00:00.000000000 +0100 @@ -1,7 +1,3 @@ -[ This paper makes reference to the "Sfio" library. See - http://www.research.att.com/sw/tools/sfio/ for more. -kff] - - Network Services Research Lab David Korn and Kiem-Phong Vo AT&T Labs Submission: March 09, 2000 subversion-1.3.2/notes/old/draft-korn-vcdiff-01.txt /home/jas/rfc/draft-korn-vcdiff-01.txt differ: byte 1, line 1 pkg tcllib ver 1.8-1 lastfile tcllib_1.8.orig.tar.gz files tcllib-1.8/modules/ftpd/rfc959.txt tcllib-1.8/modules/ident/rfc1413.txt tcllib-1.8/modules/nntp/rfc977.txt tcllib-1.8/modules/pop3d/rfc1939.txt tcllib-1.8/modules/pop3d/rfc2449.txt tar xfz /data/debian/pool/main/t/tcllib/tcllib_1.8.orig.tar.gz tcllib-1.8/modules/ftpd/rfc959.txt 61fe27e8453911367a6b1efdb218faa7 - tcllib-1.8/modules/ftpd/rfc959.txt 61fe27e8453911367a6b1efdb218faa7 - /home/jas/rfc/rfc959.txt MATCH rfc959.txt tar xfz /data/debian/pool/main/t/tcllib/tcllib_1.8.orig.tar.gz tcllib-1.8/modules/ident/rfc1413.txt 7b72fafe2fb39b86316142416d248d22 - tcllib-1.8/modules/ident/rfc1413.txt 7b72fafe2fb39b86316142416d248d22 - /home/jas/rfc/rfc1413.txt MATCH rfc1413.txt tar xfz /data/debian/pool/main/t/tcllib/tcllib_1.8.orig.tar.gz tcllib-1.8/modules/nntp/rfc977.txt 5be13669c9dbee8ccaf27c32b74301ba - tcllib-1.8/modules/nntp/rfc977.txt 5be13669c9dbee8ccaf27c32b74301ba - /home/jas/rfc/rfc977.txt MATCH rfc977.txt tar xfz /data/debian/pool/main/t/tcllib/tcllib_1.8.orig.tar.gz tcllib-1.8/modules/pop3d/rfc1939.txt 718ed11a29a4d43dacc14eb978e486fd - tcllib-1.8/modules/pop3d/rfc1939.txt 15ff19982bd41e884ce1b5675054ac22 - /home/jas/rfc/rfc1939.txt MISMATCH rfc1939.txt --- tcllib-1.8/modules/pop3d/rfc1939.txt 2002-03-19 23:56:15.000000000 +0100 +++ /home/jas/rfc/rfc1939.txt 1996-05-09 23:20:15.000000000 +0200 @@ -2,6 +2,8 @@ + + Network Working Group J. Myers Request for Comments: 1939 Carnegie Mellon STD: 53 M. Rose @@ -1287,5 +1289,3 @@ Myers & Rose Standards Track [Page 23] - - tcllib-1.8/modules/pop3d/rfc1939.txt /home/jas/rfc/rfc1939.txt differ: byte 5, line 5 tar xfz /data/debian/pool/main/t/tcllib/tcllib_1.8.orig.tar.gz tcllib-1.8/modules/pop3d/rfc2449.txt 20e27be1834fe8c044ef4eeb77e886ab - tcllib-1.8/modules/pop3d/rfc2449.txt 20e27be1834fe8c044ef4eeb77e886ab - /home/jas/rfc/rfc2449.txt MATCH rfc2449.txt pkg teapop ver 0.3.7-4.2 lastfile teapop_0.3.7.orig.tar.gz files teapop-0.3.7.orig/rfc/rfc1939.txt teapop-0.3.7.orig/rfc/rfc2449.txt tar xfz /data/debian/pool/main/t/teapop/teapop_0.3.7.orig.tar.gz teapop-0.3.7.orig/rfc/rfc1939.txt 15ff19982bd41e884ce1b5675054ac22 - teapop-0.3.7.orig/rfc/rfc1939.txt 15ff19982bd41e884ce1b5675054ac22 - /home/jas/rfc/rfc1939.txt MATCH rfc1939.txt tar xfz /data/debian/pool/main/t/teapop/teapop_0.3.7.orig.tar.gz teapop-0.3.7.orig/rfc/rfc2449.txt 20e27be1834fe8c044ef4eeb77e886ab - teapop-0.3.7.orig/rfc/rfc2449.txt 20e27be1834fe8c044ef4eeb77e886ab - /home/jas/rfc/rfc2449.txt MATCH rfc2449.txt pkg uw-imap ver 7:2002edebian1-13 lastfile uw-imap_2002edebian1.orig.tar.gz files imap-2002e/docs/rfc/rfc3502.txt imap-2002e/docs/rfc/rfc2971.txt imap-2002e/docs/rfc/rfc1731.txt imap-2002e/docs/rfc/rfc1732.txt imap-2002e/docs/rfc/rfc1733.txt imap-2002e/docs/rfc/rfc3501.txt imap-2002e/docs/rfc/rfc2061.txt imap-2002e/docs/rfc/rfc2062.txt imap-2002e/docs/rfc/rfc2086.txt imap-2002e/docs/rfc/rfc2087.txt imap-2002e/docs/rfc/rfc2088.txt imap-2002e/docs/rfc/rfc2177.txt imap-2002e/docs/rfc/rfc2180.txt imap-2002e/docs/rfc/rfc2192.txt imap-2002e/docs/rfc/rfc2193.txt imap-2002e/docs/rfc/rfc2195.txt imap-2002e/docs/rfc/rfc2221.txt imap-2002e/docs/rfc/rfc2222.txt imap-2002e/docs/rfc/rfc2245.txt imap-2002e/docs/rfc/rfc2342.txt imap-2002e/docs/rfc/rfc2234.txt imap-2002e/docs/rfc/rfc2359.txt imap-2002e/docs/rfc/rfc2683.txt imap-2002e/docs/rfc/rfc2595.txt imap-2002e/docs/rfc/rfc3348.txt imap-2002e/docs/rfc/rfc3503.txt imap-2002e/docs/rfc/rfc3516.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc3502.txt ccd7a89d77269a09dfd9dfa53d1f0f95 - imap-2002e/docs/rfc/rfc3502.txt ccd7a89d77269a09dfd9dfa53d1f0f95 - /home/jas/rfc/rfc3502.txt MATCH rfc3502.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2971.txt 1938a00ba4559200ad0c73b42e6c4c59 - imap-2002e/docs/rfc/rfc2971.txt 1938a00ba4559200ad0c73b42e6c4c59 - /home/jas/rfc/rfc2971.txt MATCH rfc2971.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc1731.txt 82e7bb0077d0706b495ac512ea400bc1 - imap-2002e/docs/rfc/rfc1731.txt 82e7bb0077d0706b495ac512ea400bc1 - /home/jas/rfc/rfc1731.txt MATCH rfc1731.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc1732.txt 13e7b39d5ba6e1903c83b256ba067089 - imap-2002e/docs/rfc/rfc1732.txt 13e7b39d5ba6e1903c83b256ba067089 - /home/jas/rfc/rfc1732.txt MATCH rfc1732.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc1733.txt aa25bfe07e80e37534e117978de55146 - imap-2002e/docs/rfc/rfc1733.txt aa25bfe07e80e37534e117978de55146 - /home/jas/rfc/rfc1733.txt MATCH rfc1733.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc3501.txt 4a9334d5750a6239640697bda38348cf - imap-2002e/docs/rfc/rfc3501.txt f49bfc28b5980e6db512acc32febd7a3 - /home/jas/rfc/rfc3501.txt MISMATCH rfc3501.txt --- imap-2002e/docs/rfc/rfc3501.txt 2003-03-17 19:27:45.000000000 +0100 +++ /home/jas/rfc/rfc3501.txt 2003-03-17 22:10:09.000000000 +0100 @@ -5017,7 +5017,7 @@ ; these two regardless of order. ; Example: 2:4 and 4:2 are equivalent and indicate ; values 2, 3, and 4. - ; Example: a unique identifer sequence range of + ; Example: a unique identifier sequence range of ; 3291:* includes the UID of the last message in ; the mailbox, even if that value is less than 3291. @@ -5646,7 +5646,7 @@ command should only be done if a security layer was not negotiated. 84) Change the definition of atom to exclude "]". Update astring to - include "]" for compatiblity with the past. Remove resp-text-atom. + include "]" for compatibility with the past. Remove resp-text-atom. 85) Remove NEWNAME. It can't work because mailbox names can be literals and can include "]". Functionality can be addressed via @@ -6049,4 +6049,3 @@ Crispin Standards Track [Page 108] - imap-2002e/docs/rfc/rfc3501.txt /home/jas/rfc/rfc3501.txt differ: byte 189762, line 5020 tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2061.txt e9d1774f7e95ec54c33929a889565ad0 - imap-2002e/docs/rfc/rfc2061.txt e9d1774f7e95ec54c33929a889565ad0 - /home/jas/rfc/rfc2061.txt MATCH rfc2061.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2062.txt c79400a4a2030810e2b1e10ec5b578ae - imap-2002e/docs/rfc/rfc2062.txt c79400a4a2030810e2b1e10ec5b578ae - /home/jas/rfc/rfc2062.txt MATCH rfc2062.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2086.txt 08dd84b0546b917ce316baf3021a9dbf - imap-2002e/docs/rfc/rfc2086.txt 08dd84b0546b917ce316baf3021a9dbf - /home/jas/rfc/rfc2086.txt MATCH rfc2086.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2087.txt dd611be0081bdd93af0136d030131a05 - imap-2002e/docs/rfc/rfc2087.txt dd611be0081bdd93af0136d030131a05 - /home/jas/rfc/rfc2087.txt MATCH rfc2087.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2088.txt 396b3b410f45da9b98932fefb1f49da5 - imap-2002e/docs/rfc/rfc2088.txt 396b3b410f45da9b98932fefb1f49da5 - /home/jas/rfc/rfc2088.txt MATCH rfc2088.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2177.txt dd8f2b9b4c2898334f41f8843f0f0efa - imap-2002e/docs/rfc/rfc2177.txt dd8f2b9b4c2898334f41f8843f0f0efa - /home/jas/rfc/rfc2177.txt MATCH rfc2177.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2180.txt 92a49bb4560db4896524896900238f49 - imap-2002e/docs/rfc/rfc2180.txt 92a49bb4560db4896524896900238f49 - /home/jas/rfc/rfc2180.txt MATCH rfc2180.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2192.txt 06a4f0eb97f0930b960dd5a42b4832bf - imap-2002e/docs/rfc/rfc2192.txt 06a4f0eb97f0930b960dd5a42b4832bf - /home/jas/rfc/rfc2192.txt MATCH rfc2192.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2193.txt 8c92ced2fd1b5bc16f753e303bf79d70 - imap-2002e/docs/rfc/rfc2193.txt 8c92ced2fd1b5bc16f753e303bf79d70 - /home/jas/rfc/rfc2193.txt MATCH rfc2193.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2195.txt 58a62f906e60dbb5c1dd12a6f0e92f6a - imap-2002e/docs/rfc/rfc2195.txt 58a62f906e60dbb5c1dd12a6f0e92f6a - /home/jas/rfc/rfc2195.txt MATCH rfc2195.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2221.txt 5e01beb9ec8c27d91c7c2b29b0cd91e2 - imap-2002e/docs/rfc/rfc2221.txt 5e01beb9ec8c27d91c7c2b29b0cd91e2 - /home/jas/rfc/rfc2221.txt MATCH rfc2221.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2222.txt a692a183140d0c2aff620b959f0f56ed - imap-2002e/docs/rfc/rfc2222.txt a692a183140d0c2aff620b959f0f56ed - /home/jas/rfc/rfc2222.txt MATCH rfc2222.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2245.txt a1ec4f21a9c79e64ccd5770f764d07e4 - imap-2002e/docs/rfc/rfc2245.txt a1ec4f21a9c79e64ccd5770f764d07e4 - /home/jas/rfc/rfc2245.txt MATCH rfc2245.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2342.txt 2f0f339458a114b666cee21fcfdf17e6 - imap-2002e/docs/rfc/rfc2342.txt 2f0f339458a114b666cee21fcfdf17e6 - /home/jas/rfc/rfc2342.txt MATCH rfc2342.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2234.txt 279ba7cff5522e9558cf17a0f8fe498b - imap-2002e/docs/rfc/rfc2234.txt 279ba7cff5522e9558cf17a0f8fe498b - /home/jas/rfc/rfc2234.txt MATCH rfc2234.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2359.txt d6a62e185568e19c3bf7243d2c6780c3 - imap-2002e/docs/rfc/rfc2359.txt d6a62e185568e19c3bf7243d2c6780c3 - /home/jas/rfc/rfc2359.txt MATCH rfc2359.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2683.txt eb1a2bda87de73def5f2554116c3d5e8 - imap-2002e/docs/rfc/rfc2683.txt eb1a2bda87de73def5f2554116c3d5e8 - /home/jas/rfc/rfc2683.txt MATCH rfc2683.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc2595.txt 4ce96161b6a9155f912d043d69197334 - imap-2002e/docs/rfc/rfc2595.txt 4ce96161b6a9155f912d043d69197334 - /home/jas/rfc/rfc2595.txt MATCH rfc2595.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc3348.txt 108a527df34cdea02b9cbca30a8e9591 - imap-2002e/docs/rfc/rfc3348.txt 108a527df34cdea02b9cbca30a8e9591 - /home/jas/rfc/rfc3348.txt MATCH rfc3348.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc3503.txt 325eb3a524c75f246c4731423aae34dc - imap-2002e/docs/rfc/rfc3503.txt 325eb3a524c75f246c4731423aae34dc - /home/jas/rfc/rfc3503.txt MATCH rfc3503.txt tar xfz /data/debian/pool/main/u/uw-imap/uw-imap_2002edebian1.orig.tar.gz imap-2002e/docs/rfc/rfc3516.txt 713abcbabb3c6260e85e3d146bd5a0bf - imap-2002e/docs/rfc/rfc3516.txt 713abcbabb3c6260e85e3d146bd5a0bf - /home/jas/rfc/rfc3516.txt MATCH rfc3516.txt pkg vflib3 ver 3.6.13-3.6 lastfile vflib3_3.6.13.orig.tar.gz files VFlib3-3.6.13/ccv/TBL/RFC/rfc1489.txt tar xfz /data/debian/pool/main/v/vflib3/vflib3_3.6.13.orig.tar.gz VFlib3-3.6.13/ccv/TBL/RFC/rfc1489.txt 3348751f27ac44cc91066ae770160fc4 - VFlib3-3.6.13/ccv/TBL/RFC/rfc1489.txt 3348751f27ac44cc91066ae770160fc4 - /home/jas/rfc/rfc1489.txt MATCH rfc1489.txt pkg vpim ver 0.15-1 lastfile vpim_0.15.orig.tar.gz files vpim-0.15/etc/rfc2425.txt vpim-0.15/etc/rfc2426.txt vpim-0.15/etc/rfc2445.txt tar xfz /data/debian/pool/main/v/vpim/vpim_0.15.orig.tar.gz vpim-0.15/etc/rfc2425.txt fa9d745204a7414ba12451ad31935e81 - vpim-0.15/etc/rfc2425.txt fa9d745204a7414ba12451ad31935e81 - /home/jas/rfc/rfc2425.txt MATCH rfc2425.txt tar xfz /data/debian/pool/main/v/vpim/vpim_0.15.orig.tar.gz vpim-0.15/etc/rfc2426.txt edd09e7feda53fa790f5c0de0094e30c - vpim-0.15/etc/rfc2426.txt edd09e7feda53fa790f5c0de0094e30c - /home/jas/rfc/rfc2426.txt MATCH rfc2426.txt tar xfz /data/debian/pool/main/v/vpim/vpim_0.15.orig.tar.gz vpim-0.15/etc/rfc2445.txt af41dc6e189b9d1e0b3bb07cb34924b6 - vpim-0.15/etc/rfc2445.txt af41dc6e189b9d1e0b3bb07cb34924b6 - /home/jas/rfc/rfc2445.txt MATCH rfc2445.txt pkg xfmail ver 1.5.5-3 lastfile xfmail_1.5.5.orig.tar.gz files xfmail-1.5.5/docs/rfc/rfc1823.txt.bz2 xfmail-1.5.5/docs/rfc/rfc1939.txt.bz2 xfmail-1.5.5/docs/rfc/rfc2045.txt.bz2 xfmail-1.5.5/docs/rfc/rfc2046.txt.bz2 xfmail-1.5.5/docs/rfc/rfc2047.txt.bz2 xfmail-1.5.5/docs/rfc/rfc2048.txt.bz2 xfmail-1.5.5/docs/rfc/rfc2049.txt.bz2 xfmail-1.5.5/docs/rfc/rfc2060.txt.bz2 xfmail-1.5.5/docs/rfc/rfc2554.txt.bz2 xfmail-1.5.5/docs/rfc/rfc2822.txt.bz2 xfmail-1.5.5/docs/rfc/rfc821.txt.bz2 xfmail-1.5.5/docs/rfc/rfc822.txt.bz2 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc1823.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc1823.txt.bz2 1ee675156f66394900d6d501e6185af0 - xfmail-1.5.5/docs/rfc/rfc1823.txt 1d4bbf8dcbaa1c23352d326a93baf3be - /home/jas/rfc/rfc1823.txt MISMATCH rfc1823.txt xfmail-1.5.5/docs/rfc/rfc1823.txt /home/jas/rfc/rfc1823.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc1939.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc1939.txt.bz2 19e2c5d8a8f6b4c7f6a73cfa6b15903b - xfmail-1.5.5/docs/rfc/rfc1939.txt 15ff19982bd41e884ce1b5675054ac22 - /home/jas/rfc/rfc1939.txt MISMATCH rfc1939.txt xfmail-1.5.5/docs/rfc/rfc1939.txt /home/jas/rfc/rfc1939.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc2045.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc2045.txt.bz2 8ee6605370729fd5777768765200013b - xfmail-1.5.5/docs/rfc/rfc2045.txt d61fb11bcd7b60142207209bcfa7f4b1 - /home/jas/rfc/rfc2045.txt MISMATCH rfc2045.txt xfmail-1.5.5/docs/rfc/rfc2045.txt /home/jas/rfc/rfc2045.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc2046.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc2046.txt.bz2 65ba77c0e246d3bbf972dfd5acce35dc - xfmail-1.5.5/docs/rfc/rfc2046.txt 6225c196e3c5a20155f3a2082aea2801 - /home/jas/rfc/rfc2046.txt MISMATCH rfc2046.txt xfmail-1.5.5/docs/rfc/rfc2046.txt /home/jas/rfc/rfc2046.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc2047.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc2047.txt.bz2 015b04953993f88ed88500a480c8207f - xfmail-1.5.5/docs/rfc/rfc2047.txt 068ac56e33a41f85b81177873cc0a581 - /home/jas/rfc/rfc2047.txt MISMATCH rfc2047.txt xfmail-1.5.5/docs/rfc/rfc2047.txt /home/jas/rfc/rfc2047.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc2048.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc2048.txt.bz2 7de894d74676ec8f32c73d376810951f - xfmail-1.5.5/docs/rfc/rfc2048.txt 687f52eeceada5356d2c6892d5a473f7 - /home/jas/rfc/rfc2048.txt MISMATCH rfc2048.txt xfmail-1.5.5/docs/rfc/rfc2048.txt /home/jas/rfc/rfc2048.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc2049.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc2049.txt.bz2 e3bdea890e6a89a8c74fd871a1e9777c - xfmail-1.5.5/docs/rfc/rfc2049.txt 2508a23f6ebcac9bc41b8a54c5852ae9 - /home/jas/rfc/rfc2049.txt MISMATCH rfc2049.txt xfmail-1.5.5/docs/rfc/rfc2049.txt /home/jas/rfc/rfc2049.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc2060.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc2060.txt.bz2 cb626f67d676efe68e7ba7cd5337d1db - xfmail-1.5.5/docs/rfc/rfc2060.txt 33c14a58e84b863682c318af9f62fc4a - /home/jas/rfc/rfc2060.txt MISMATCH rfc2060.txt xfmail-1.5.5/docs/rfc/rfc2060.txt /home/jas/rfc/rfc2060.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc2554.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc2554.txt.bz2 0983f150beb86f34a30ee71abb6ebba5 - xfmail-1.5.5/docs/rfc/rfc2554.txt da374308c160c15ec4a27fada7fa19d2 - /home/jas/rfc/rfc2554.txt MISMATCH rfc2554.txt xfmail-1.5.5/docs/rfc/rfc2554.txt /home/jas/rfc/rfc2554.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc2822.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc2822.txt.bz2 97c538a7a2df52a8470781dcbd2d456c - xfmail-1.5.5/docs/rfc/rfc2822.txt 97c538a7a2df52a8470781dcbd2d456c - /home/jas/rfc/rfc2822.txt MATCH rfc2822.txt tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc821.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc821.txt.bz2 78bbb789a30057dd67204530e0017410 - xfmail-1.5.5/docs/rfc/rfc821.txt a23c27fac2732113aa8ad6df7dc50d7c - /home/jas/rfc/rfc821.txt MISMATCH rfc821.txt xfmail-1.5.5/docs/rfc/rfc821.txt /home/jas/rfc/rfc821.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xfmail/xfmail_1.5.5.orig.tar.gz xfmail-1.5.5/docs/rfc/rfc822.txt.bz2 bzip2 -d xfmail-1.5.5/docs/rfc/rfc822.txt.bz2 c7b2da6aff50b282b12cd522854ff0de - xfmail-1.5.5/docs/rfc/rfc822.txt 59975cc77db34020d4f62e69c6f53dcf - /home/jas/rfc/rfc822.txt MISMATCH rfc822.txt xfmail-1.5.5/docs/rfc/rfc822.txt /home/jas/rfc/rfc822.txt differ: byte 1, line 1 pkg xml2rfc ver 1.31.dfsg-1 lastfile xml2rfc_1.31.dfsg.orig.tar.gz files xml2rfc-1.31/rfc2629.txt tar xfz /data/debian/pool/main/x/xml2rfc/xml2rfc_1.31.dfsg.orig.tar.gz xml2rfc-1.31/rfc2629.txt b794d27194f6abc2e06c1d04c08be550 - xml2rfc-1.31/rfc2629.txt ec211da1c0030a8a15616bac50a486c6 - /home/jas/rfc/rfc2629.txt MISMATCH rfc2629.txt --- xml2rfc-1.31/rfc2629.txt 2006-08-21 07:38:16.000000000 +0200 +++ /home/jas/rfc/rfc2629.txt 1999-07-02 22:02:56.000000000 +0200 @@ -3,6 +3,7 @@ + Network Working Group M. Rose Request for Comments: 2629 Invisible Worlds, Inc. Category: Informational June 1999 @@ -1736,5 +1737,3 @@ Rose Informational [Page 31] - - xml2rfc-1.31/rfc2629.txt /home/jas/rfc/rfc2629.txt differ: byte 6, line 6 pkg xrn ver 9.02-7.1 lastfile xrn_9.02.orig.tar.gz files xrn-9.02.orig/doc/rfc977.txt tar xfz /data/debian/pool/main/x/xrn/xrn_9.02.orig.tar.gz xrn-9.02.orig/doc/rfc977.txt 4df449537495d127695bbbc816c8d731 - xrn-9.02.orig/doc/rfc977.txt 5be13669c9dbee8ccaf27c32b74301ba - /home/jas/rfc/rfc977.txt MISMATCH rfc977.txt xrn-9.02.orig/doc/rfc977.txt /home/jas/rfc/rfc977.txt differ: byte 1, line 1 pkg xulrunner ver 1.8.0.7-1 lastfile xulrunner_1.8.0.7.orig.tar.gz files xulrunner-1.8.0.7/directory/c-sdk/ldap/docs/draft-ietf-ldapext-ldap-c-api-05.txt xulrunner-1.8.0.7/netwerk/protocol/ftp/doc/rfc959.txt tar xfz /data/debian/pool/main/x/xulrunner/xulrunner_1.8.0.7.orig.tar.gz xulrunner-1.8.0.7/directory/c-sdk/ldap/docs/draft-ietf-ldapext-ldap-c-api-05.txt 94d7310dfd0f455b4db3540285037169 - xulrunner-1.8.0.7/directory/c-sdk/ldap/docs/draft-ietf-ldapext-ldap-c-api-05.txt b88674b6ec99af3da549509f661eb056 - /home/jas/rfc/draft-ietf-ldapext-ldap-c-api-05.txt MISMATCH draft-ietf-ldapext-ldap-c-api-05.txt xulrunner-1.8.0.7/directory/c-sdk/ldap/docs/draft-ietf-ldapext-ldap-c-api-05.txt /home/jas/rfc/draft-ietf-ldapext-ldap-c-api-05.txt differ: byte 1, line 1 tar xfz /data/debian/pool/main/x/xulrunner/xulrunner_1.8.0.7.orig.tar.gz xulrunner-1.8.0.7/netwerk/protocol/ftp/doc/rfc959.txt 61fe27e8453911367a6b1efdb218faa7 - xulrunner-1.8.0.7/netwerk/protocol/ftp/doc/rfc959.txt 61fe27e8453911367a6b1efdb218faa7 - /home/jas/rfc/rfc959.txt MATCH rfc959.txt pkg yardradius ver 1.0.21-17 lastfile yardradius_1.0.21.orig.tar.gz files yardradius-1.0.21/doc/rfc/rfc1157.txt yardradius-1.0.21/doc/rfc/rfc2618.txt yardradius-1.0.21/doc/rfc/rfc2619.txt yardradius-1.0.21/doc/rfc/rfc2620.txt yardradius-1.0.21/doc/rfc/rfc2621.txt yardradius-1.0.21/doc/rfc/rfc2865.txt yardradius-1.0.21/doc/rfc/rfc2866.txt yardradius-1.0.21/doc/rfc/rfc2867.txt yardradius-1.0.21/doc/rfc/rfc2868.txt yardradius-1.0.21/doc/rfc/rfc2869.txt yardradius-1.0.21/doc/rfc/rfc2882.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc1157.txt 5cfd63771c94a40764162d2867a9f98f - yardradius-1.0.21/doc/rfc/rfc1157.txt 5cfd63771c94a40764162d2867a9f98f - /home/jas/rfc/rfc1157.txt MATCH rfc1157.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc2618.txt c44632f8ca248245f7a0e417285dba8f - yardradius-1.0.21/doc/rfc/rfc2618.txt c44632f8ca248245f7a0e417285dba8f - /home/jas/rfc/rfc2618.txt MATCH rfc2618.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc2619.txt 4c879fe4eb0d42fe64e7df287fb9a0cb - yardradius-1.0.21/doc/rfc/rfc2619.txt 4c879fe4eb0d42fe64e7df287fb9a0cb - /home/jas/rfc/rfc2619.txt MATCH rfc2619.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc2620.txt 0671c428f7bb1b736ea1b71dda013512 - yardradius-1.0.21/doc/rfc/rfc2620.txt 0671c428f7bb1b736ea1b71dda013512 - /home/jas/rfc/rfc2620.txt MATCH rfc2620.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc2621.txt d75c8f795fbbb8cc5b10be615e92033a - yardradius-1.0.21/doc/rfc/rfc2621.txt d75c8f795fbbb8cc5b10be615e92033a - /home/jas/rfc/rfc2621.txt MATCH rfc2621.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc2865.txt 50e1582ac1b059ea2d9a1a8d412cc07c - yardradius-1.0.21/doc/rfc/rfc2865.txt 50e1582ac1b059ea2d9a1a8d412cc07c - /home/jas/rfc/rfc2865.txt MATCH rfc2865.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc2866.txt faeb07c86d5d1f257aef54a03f39576d - yardradius-1.0.21/doc/rfc/rfc2866.txt faeb07c86d5d1f257aef54a03f39576d - /home/jas/rfc/rfc2866.txt MATCH rfc2866.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc2867.txt 2901f7be0e8df9e148d83512b8aec5c1 - yardradius-1.0.21/doc/rfc/rfc2867.txt 2901f7be0e8df9e148d83512b8aec5c1 - /home/jas/rfc/rfc2867.txt MATCH rfc2867.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc2868.txt e2fcd6e771861160223bb341c7470960 - yardradius-1.0.21/doc/rfc/rfc2868.txt e2fcd6e771861160223bb341c7470960 - /home/jas/rfc/rfc2868.txt MATCH rfc2868.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc2869.txt e2607d4b8eb33e481a293f9837d61297 - yardradius-1.0.21/doc/rfc/rfc2869.txt e2607d4b8eb33e481a293f9837d61297 - /home/jas/rfc/rfc2869.txt MATCH rfc2869.txt tar xfz /data/debian/pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz yardradius-1.0.21/doc/rfc/rfc2882.txt 004c34dda7d4498427b2966ffafc701e - yardradius-1.0.21/doc/rfc/rfc2882.txt 004c34dda7d4498427b2966ffafc701e - /home/jas/rfc/rfc2882.txt MATCH rfc2882.txt pkg zcip ver 4-9 lastfile zcip_4.orig.tar.gz files zcip-4/draft-ietf-zeroconf-ipv4-linklocal-07.txt tar xfz /data/debian/pool/main/z/zcip/zcip_4.orig.tar.gz zcip-4/draft-ietf-zeroconf-ipv4-linklocal-07.txt fd1f90b783c3d26bd6a42e159b8f39ef - zcip-4/draft-ietf-zeroconf-ipv4-linklocal-07.txt fd1f90b783c3d26bd6a42e159b8f39ef - /home/jas/rfc/draft-ietf-zeroconf-ipv4-linklocal-07.txt MATCH draft-ietf-zeroconf-ipv4-linklocal-07.txt pkg zeroconf ver 0.9-1 lastfile zeroconf_0.9.orig.tar.gz files zeroconf-0.9/rfc3927.txt tar xfz /data/debian/pool/main/z/zeroconf/zeroconf_0.9.orig.tar.gz zeroconf-0.9/rfc3927.txt a36a078082e0a5e81384712eb3d34edc - zeroconf-0.9/rfc3927.txt a36a078082e0a5e81384712eb3d34edc - /home/jas/rfc/rfc3927.txt MATCH rfc3927.txt last pkg zmailer ver files