From A.Hoenes@tr-sys.de Wed Nov 10 11:27:16 2004 Return-Path: Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAAJQTi11915 for ; Wed, 10 Nov 2004 11:26:39 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA032064722; Wed, 10 Nov 2004 20:25:22 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA07597; Wed, 10 Nov 2004 20:25:11 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200411101925.UAA07597@TR-Sys.de> Subject: RFC 3926 citation problem To: tony.paila@nokia.com, luby@digitalfountain.com, rami.lehtonen@teliasonera.com, vincent.roca@inrialpes.fr, rod.walsh@nokia.com Date: Wed, 10 Nov 2004 20:25:11 +0100 (MEZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: a.hoenes@tr-sys.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000001 Status: RO Content-Length: 3597 Lines: 84 Hello, In the recently published RFC 3926 authored by you I found a multi-facetted issue regarding the MIME document citations: (1) On page 31, the Informative Reference "[21]" is inconsistent; author, title, and publication month / year match RFC 2047, *not* "RFC 1521" as stated there. (2) The first use of reference "[21]" appears on page 27, in the 10th line of the 2nd paragraph. There, "RFC 2047" _might_ be what you meant (together with [20] pointing to RFC 2048). Now, unfortunately, the current basic MIME specifications, RFC 2045..2049, do not contain a substantial general discussion of security issues. The RFC 2045 and RFC 2049 "Security Considerations" just refer to RFC 2046. But RFC 2046 for this purpose refers to two specific media type explanations / 'informal registrations' contained in the body of that memo, and to RFC 2048, which in turn does *NOT* contain a "Security Considerations" section. (NB: - RFC 2048 just describes the registration PROCEDURES and states the Security Considerations *requirement* for any such registrations. - The formal ['skeleton'] Registrations for the basic MIME content types / subtypes from RFC 1521 - Appendix F - unfortunately have been lost on their [expected] way into RFC 2046. ) RFC 2047, in particular, is an extreme: "Security issues are not discussed in this memo." (Section 10 on page 14). Therefore I suspect that "RFC 2047" might indeed NOT be what you wanted to refer to in loc. cit. Perhaps the combination of RFC 2046 and RFC 2048 would have been the most appropriate selection for this citation. (3) The second use of reference "[21]" in RFC 3926 appears 2 lines further down in the same paragraph on page 27, explicitely referring to RFC 1521. The final statement there on RFC 1521, "... even though its protocol is obsoleted by RFC 2048 [20]." as well does not seem to be very appropriate for me: It might be disputable whether one should talk about a "protocol" when talking about message/document format descriptions, but more substantially, the major part of RFC 1521 has been superseded by RFC 2046 - see (2) above - while RFC 2048 only supersedes Appendix E of RFC 1521, which at the time of its publication already had been "updated" (i.e. obsoleted) by RFC 1590. Therefore, it might be appropriate to replace the impacted bad Informative Reference citation [21] on page 31 of RFC 3926 by two citations (e.g. [21]' and [23]), one for RFC 1521 and one for RFC 2046, and to modify the abovementioned phrase. It might be useful to take a step to resolve these issues by submitting an errata note to the RFC Editor's RFC Errata web page -- please comment. Additionally, I've found a lot of (~25) minor textual issues (typos, grammar, formatting) in RFC 3926 which are perhaps not worth of similar publication. But, if you are interested in these - e.g. with respect to a future re-publication of FLUTE as a Standards Track document -, please let me know; I'll prepare a decription on your request. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From mrc@CAC.Washington.EDU Mon Nov 15 13:26:34 2004 Return-Path: Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAFLPGt12744 for ; Mon, 15 Nov 2004 13:25:16 -0800 (PST) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAFLPFAG020684 for ; Mon, 15 Nov 2004 13:25:16 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAFLPF86030792 for ; Mon, 15 Nov 2004 13:25:15 -0800 Date: Mon, 15 Nov 2004 13:25:15 -0800 (PST) From: Mark Crispin To: rfc-editor@rfc-editor.org Subject: new RFC 3501 errata Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: mrc@cac.washington.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000004 Status: RO X-Status: A Content-Length: 9589 Lines: 230 Section 2.3.1.1, page 8: old: A 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever. Unique identifiers [...] new: An unsigned 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever. Unique identifiers [...] ----- Section 2.3.1.1, page 9: old: Associated with every mailbox are two values which aid in unique identifier handling: the next unique identifier value and the unique identifier validity value. new: Associated with every mailbox are two 32-bit unsigned values which aid in unique identifier handling: the next unique identifier value (UIDNEXT) and the unique identifier validity value (UIDVALIDITY). ----- Section 5.1.3, page 19: old: All other characters (octet values 0x00-0x1f and 0x7f-0xff) are represented in modified BASE64, with a further modification from [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be used to represent any printing US-ASCII character which can represent itself. new: All other characters (octet values 0x00-0x1f and 0x7f-0xff) are represented in modified BASE64, with a further modification from [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be used to represent any printing US-ASCII character which can represent itself. Only characters inside the modified BASE64 alphabet are permitted in modified BASE64 text. ----- Section 5.5, page 22: old: Note: UID FETCH, UID STORE, and UID SEARCH are different commands from FETCH, STORE, and SEARCH. If the client sends a UID command, it must wait for a completion result response before sending a command with message sequence numbers. new: Note: EXPUNGE responses are permitted while UID FETCH, UID STORE, and UID SEARCH are in progress. If the client sends a UID command, it must wait for a completion result response before sending a command which uses message sequence numbers (this may include UID SEARCH). Any message sequence numbers in an argument to UID SEARCH are associated with messages prior to the effect of any untagged EXPUNGE returned by the UID SEARCH. ----- Section 6.2.1, page 27: old: Once [TLS] has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in- the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS. new: Once [TLS] has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in- the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities, and in particular SHOULD NOT advertise the STARTTLS capability, after a successful STARTTLS command. ----- Section 6.2.2, page 28: old: The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the authentication mechanism. A server challenge consists of a command continuation request response with the "+" token followed by a BASE64 encoded string. The client response consists of a single line consisting of a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it issues a line consisting of a single "*". If the server receives such a response, it MUST reject the AUTHENTICATE command by sending a tagged BAD response. new: The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the authentication mechanism. A server challenge consists of a command continuation request response with the "+" token followed by a BASE64 encoded string. The client response consists of a single line consisting of a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it issues a line consisting of a single "*". If the server receives such a response, or if it receives an invalid BASE64 string (e.g. characters outside the BASE64 alphabet, or non-terminal "="), it MUST reject the AUTHENTICATE command by sending a tagged BAD response. Section 6.3.4, page 36: old: It is permitted to delete a name that has inferior hierarchical names and does not have the \Noselect mailbox name attribute. In this case, all messages in that mailbox are removed, and the name will acquire the \Noselect mailbox name attribute. new: It is permitted to delete a name that has inferior hierarchical names and does not have the \Noselect mailbox name attribute. If the server implementation does not permit deleting the name while inferior hierarchical names exists the \Noselect mailbox name attribute is set for that name. In any case, all messages in that mailbox are removed by the DELETE command. ----- Section 6.3.10, page 44: old: Responses: untagged responses: STATUS new: Responses: REQUIRED untagged response: STATUS ----- Section 6.4.3, page 49: old: The EXPUNGE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox. Before returning an OK to the client, an untagged EXPUNGE response is sent for each message that is removed. new: The EXPUNGE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox. Before returning an OK to the client, an untagged EXPUNGE response is sent for each message that is removed. Note that if any messages with the \Recent flag set are expunged, an untagged RECENT response is sent after the untagged EXPUNGE(s) to update the client's count of RECENT messages. ----- Section 6.4.4, page 50: old: [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing text in a [CHARSET] other than US-ASCII. US-ASCII MUST be supported; other [CHARSET]s MAY be supported. new: [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing text. US-ASCII MUST be supported; other [CHARSET]s MAY be supported. ----- Section 6.4.4, page 50: old: In all search keys that use strings, a message matches the key if the string is a substring of the field. The matching is case-insensitive. new: In all search keys that use strings, a message matches the key if the string is a substring of the associated text. The matching is case-insensitive. Note that the empty string is a substring; this is useful when doing a HEADER search. ----- Section 6.4.4, page 54: old: C: A284 SEARCH CHARSET UTF-8 TEXT {6} C: XXXXXX S: * SEARCH 43 S: A284 OK SEARCH completed new: C: A284 SEARCH CHARSET UTF-8 TEXT {6} S: + Ready for literal text C: XXXXXX S: * SEARCH 43 S: A284 OK SEARCH completed ----- Section 7.2.2, page 70: old: If it is not feasible for the server to determine whether or not the mailbox is "interesting", or if the name is a \Noselect name, the server SHOULD NOT send either \Marked or \Unmarked. new: If it is not feasible for the server to determine whether or not the mailbox is "interesting", the server SHOULD NOT send either \Marked or \Unmarked. The server MUST NOT send more than one of \Marked, \Unmarked, and \Noselect for a single mailbox, and MAY send none of these. ----- Formal Syntax, Page 84: old: CHAR8 = %x01-ff ; any OCTET except NUL, %x00 new: CHAR8 = %x01-ff ; any OCTET except NUL, %x00 charset = atom / quoted ----- Formal Syntax, Page 89: old: resp-text-code = "ALERT" / "BADCHARSET" [SP "(" astring *(SP astring) ")" ] / new: resp-text-code = "ALERT" / "BADCHARSET" [SP "(" charset *(SP charset) ")" ] / ----- Formal Syntax, Page 89: old: search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key) new: search = "SEARCH" [SP "CHARSET" SP charset] 1*(SP search-key) ----- Formal Syntax, Page 90: old: status-att-list = status-att SP number *(SP status-att SP number) new: status-att-val = ("MESSAGES" SP number) / ("RECENT" SP number) / ("UIDNEXT" SP nz-number) / ("UIDVALIDITY" SP nz-number) / ("UNSEEN" SP number) status-att-list = status-att-val *(SP status-att-val) ----- From A.Hoenes@tr-sys.de Sat Dec 4 13:08:55 2004 Return-Path: Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iB4L67Q17405 for ; Sat, 4 Dec 2004 13:06:14 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA163564299; Sat, 4 Dec 2004 22:04:59 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA24686; Sat, 4 Dec 2004 22:04:50 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200412042104.WAA24686@TR-Sys.de> Subject: RFC 3966 To: hgs@cs.columbia.edu Date: Sat, 4 Dec 2004 22:04:49 +0100 (MEZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: a.hoenes@tr-sys.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000014 Status: RO Content-Length: 2104 Lines: 58 Hello, reading the 'fresh' RFC 3966 authored by you, I've found two issues to mention. (1) -- a typo I suspect a typo -- indeed tiny, but possibly distorting the meaning of the example presented there -- on top of page 9 (in chapter 5.1.5). >From the explanation given, I conclude that (in the 5th text line) : "+1-212-555-1 would not be a valid global context, ..." ^^ in fact should read: "+1-212-555-01 would not be a valid global context, ..." ^^^ If my suspicion is right, we perhaps should request the publication of an errata note on the RFC-Editor's "RFC Errata" web page. (2) -- Fate of "fax" and "modem" URI schemes RFC 3966 re-defines the "tel" URI scheme and obsoletes RFC 2806 which defined (and registered) three URI schemes: "tel", "fax", and "modem". Section 12 of RFC 3966 (on page 15) merely states "references to ... fax and modem URIs ... have been removed." There are *no* IANA considerations included in RFC 3966 regarding the latter URIs. Hence it is not clear whether these URIs are to be regarded as informally "deprecated" or "de-registered" by this RFC, and therefore should be marked accordingly in the IANA 'URI Schemes' reqistry. If however, by existing policy, URI schemes cannot be "deprecated" or "de-registered", the RFC 3966 meta-information should be changed to say "Updates: 2806" instead of "Obsoletes: 2806", and another errata note should be filed to change the RFC 3966 heading accordingly, to avoid the situation of having no more 'valid' documentation for two registered URI schemes. The fate of the "fax" and "modem" URI schemes should be made clear, formally, and in an appropriate way. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From hgs@cs.columbia.edu Sat Dec 4 13:14:24 2004 Return-Path: Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iB4LC7Q18284 for ; Sat, 4 Dec 2004 13:12:07 -0800 (PST) Received: from lion.cs.columbia.edu (IDENT:i4zikhY+QmXimHZ1b8/DKi3zkCdB1M02@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iB4LC3TO004778; Sat, 4 Dec 2004 16:12:03 -0500 (EST) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id iB4LC2iP014634 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 4 Dec 2004 16:12:03 -0500 Message-ID: <41B2281D.8040102@cs.columbia.edu> Date: Sat, 04 Dec 2004 16:11:57 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= CC: rfc-editor@rfc-editor.org Subject: Re: RFC 3966 References: <200412042104.WAA24686@TR-Sys.de> In-Reply-To: <200412042104.WAA24686@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.12.4.4 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-UID: 0000000015 Status: RO Content-Length: 2252 Lines: 61 (1) is indeed a typo. (2) requires discussion in the IPTEL working group, where I suggest you take this discussion. I have my personal opinions as to the deployment and deployability of the 'fax' URI scheme, but that's not particularly relevant. I suspect a separate document that performs the appropriate designation (e.g., historical) would be called for, rather than changing 3996. Alfred � wrote: > Hello, > > reading the 'fresh' RFC 3966 authored by you, I've found two issues > to mention. > > > (1) -- a typo > > I suspect a typo -- indeed tiny, but possibly distorting the meaning > of the example presented there -- on top of page 9 (in chapter 5.1.5). > >>From the explanation given, I conclude that (in the 5th text line) : > > "+1-212-555-1 would not be a valid global context, ..." > ^^ > in fact should read: > > "+1-212-555-01 would not be a valid global context, ..." > ^^^ > > If my suspicion is right, we perhaps should request the publication > of an errata note on the RFC-Editor's "RFC Errata" web page. > > > (2) -- Fate of "fax" and "modem" URI schemes > > RFC 3966 re-defines the "tel" URI scheme and obsoletes RFC 2806 > which defined (and registered) three URI schemes: "tel", "fax", > and "modem". Section 12 of RFC 3966 (on page 15) merely states > "references to ... fax and modem URIs ... have been removed." > There are *no* IANA considerations included in RFC 3966 regarding > the latter URIs. > > Hence it is not clear whether these URIs are to be regarded as > informally "deprecated" or "de-registered" by this RFC, and therefore > should be marked accordingly in the IANA 'URI Schemes' reqistry. > > If however, by existing policy, URI schemes cannot be "deprecated" > or "de-registered", the RFC 3966 meta-information should be changed > to say "Updates: 2806" instead of "Obsoletes: 2806", and another > errata note should be filed to change the RFC 3966 heading > accordingly, to avoid the situation of having no more 'valid' > documentation for two registered URI schemes. > > The fate of the "fax" and "modem" URI schemes should be made clear, > formally, and in an appropriate way. > > > Best regards, > Alfred H�nes. > From A.Hoenes@tr-sys.de Tue Jan 4 02:11:42 2005 Return-Path: Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j04AA6Q26181 for ; Tue, 4 Jan 2005 02:10:12 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA052503330; Tue, 4 Jan 2005 11:08:50 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA18111; Tue, 4 Jan 2005 11:08:40 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200501041008.LAA18111@TR-Sys.de> Subject: RFC 3939 To: gparsons@nortelnetworks.com, jjmaruszak@sympatico.ca Date: Tue, 4 Jan 2005 11:08:40 +0100 (MEZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: a.hoenes@tr-sys.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000018 Status: RO Content-Length: 2191 Lines: 69 Hello, I'd like to mention a few issues I found with the new RFC 3939 authored by you. Please comment, and consider which of the items below should be submitted for publication on the RFC Editor's RFC Errata web page. In item (3), I have emphasized the proposed textual changes by a change bar, '|', in column 1. (1) Outdated Reference: The last item in section '9.2. Informative References', on page 9, names RFC 2806. But, at the time of publication of RFC 3939, that RFC 2806 already had been obsoleted by RFC 3966, published two weeks before RFC 3939 ! The reference [RFC2806] therefore should be updated accordingly throughout the text. (2) Missing IANA registrations ? I suspect that -- beyond what indeed has been specified in section '8. IANA Considerations' of RFC 3939 -- , according to BCP 90 (= RFC 3864), the new IMAIL Header Fields, "Caller-ID" and "Caller-Name", as well should get formal IANA registrations listed in the RFC, using the templates from section 4.2. of RFC 3864 ! Perhaps, a citation to BCP 90 would also have been appropriate. (3) Minor textual improvements: a) Change the first line of section 6.1., on page 6, from "The intent of these headers are to record telephone number that is sent by the analog phone system with an incoming call without alteration or interpretation." ... to: | "The intent of these headers are to record the telephone number that is sent by the analog phone system with an incoming call without alteration or interpretation." ... b) In the first line of section '10. Acknowledgments', on page 9, change: "The previous authors of versions of this document were Derrick Dunne and Jason Collins." ... to: | "The authors of previous versions of this document were Derrick Dunne and Jason Collins." ... Regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@tr-sys.de Tue Jan 4 03:07:41 2005 Return-Path: Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j04B5RQ08013 for ; Tue, 4 Jan 2005 03:05:34 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA052706649; Tue, 4 Jan 2005 12:04:09 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA18166; Tue, 4 Jan 2005 12:03:57 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200501041103.MAA18166@TR-Sys.de> Subject: RFC 3965 errata To: toyoda.kiyoshi@jp.panasonic.com, hohno@ohnolab.org, jun@wide.ad.jp, dwing@cisco.com Date: Tue, 4 Jan 2005 12:03:57 +0100 (MEZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: a.hoenes@tr-sys.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000019 Status: RO Content-Length: 5804 Lines: 158 Hello, please let me note the textual issues I found with the newly published RFC 3965 authored by you. Obviously -- cf. the heading of Appendix B in the text -- there has been a very substantial delay in the publication process of this revision to RFC 2305. Nevertheless, many textual issues from RFC 2305 have not been corrected with this updated version. Please comment on the items below, and decide which of these should be submitted to the RFC Editor for inclusion on the RFC Errata web page. I have emphasized below proposed textual changes by a change bar, '|', in the first column. (1) Issues with 'References' : ======================== a) Reference [3] is outdated and not used in the text. References [1] and [2] from RFC 2305 have been updated, from pointers to RFC 821 and RFC 822, to pointers to RFC 2821 and RFC 2822, respectively. The (normative) updates to RFC 821 and RFC 822 contained in STD 3, RFC 1123 [3], have been incorporated into RFC 2821 and RFC 2822, respectively, which obsolete their predecessors. Hence, the reference to RFC 1123 is no more needed in RFC 3965, and in fact it is not mentioned in the textual body any more. Thus, the Normative Reference [3] should be deleted from section 6.1., on page 10. b) 'Oracle' in Reference [5]. The Normative Reference [5] on page 10 contains a predicted publication month and year for RFC 3949, which is not correct. It should be updated to name the true publication month and year of RFC 3949, as soon as RFC 3949 really gets published -- it isn't yet :-) . c) Reference [19] is outdated. RFC 2633 has been obsoleted by RFC 3851, published 5 months before RFC 3965. The Informative Reference [19], on page 11, should be updated accordingly. (2) Textual corrections and enhancements : ==================================== a) Change the first sentence of section 2.1.3, on page 4, from: "An offramp gateway that operate as an MTA serving multiple users SHOULD use SMTP;" ... to: | "An offramp gateway that operates as an MTA serving multiple users SHOULD use SMTP;" ... b) Change the first sentence of section 2.2.4, on page 4, from: "A single multi-page document SHOULD be sent as a single multi- page TIFF file, even though recipients MUST process multipart/mixed containing multiple TIFF files." to: | "A single multi-page document SHOULD be sent as a single multi-page TIFF file, even though recipients MUST process multipart/mixed containing multiple TIFF files." c) Change section 5.1. on page 6 from: "This specification is based on use of existing Internet mail. To maintain interoperability with Internet mail, any security to be provided should be part of the of the Internet security infrastructure, rather than a new mechanism or some other mechanism outside of the Internet infrastructure." to: | "This specification is based on the use of existing Internet mail. To maintain interoperability with Internet mail, any security to be | provided should be part of the Internet security infrastructure, rather than a new mechanism or some other mechanism outside of the Internet infrastructure." d) Change the final sentence of section 5.2, on page 6, from: ... "This section reviews relevant concerns about Internet mail for IFax environments, as well as considering the potential problems which can result of integrating the existing G3Fax service with Internet mail." to: ... "This section reviews relevant concerns about Internet mail for IFax environments, as well as considering the | potential problems which can result from integrating the existing G3Fax service with Internet mail." e) Change the first paragraph of section 5.2.1, on page 6, from: "The actual sender of the message might not be the same as that specified in the Sender or From fields of the message content headers or the MAIL FROM address from the SMTP envelope." to: "The actual sender of the message might not be the same as that specified in the Sender or From fields of the message content headers | or the MAIL FROM address in the SMTP envelope." f) Change the second-to-last paragraph of section 5.2.2, on page 7, from: "Originator authentication entails the use of weak or strong mechanisms, such as cleartext keywords or encryption-based data-signing, respectively, to determine and validate the identify of the sender and assess permissions accordingly." to: "Originator authentication entails the use of weak or strong mechanisms, such as cleartext keywords or encryption-based | data-signing, respectively, to determine and validate the identity of the sender and assess permissions accordingly." g) Change the first sentence of the last paragraph of section 5.2.3, on page 8, from: "Typically authorization needs to be associated to specific senders and specific messages, in order to prevent a "replay" attack which causes and earlier authorization to enable a later dial-out by a different (and unauthorized) sender." ... to: | "Typically authorization needs to be associated with specific senders and specific messages, in order to prevent a "replay" attack which | causes an earlier authorization to enable a later dial-out by a different (and unauthorized) sender." ... Best Regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From Mani_Devarajan@net.com Tue Jan 11 16:18:32 2005 Return-Path: Received: from mx01.net.com (mx01.net.com [134.56.3.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0C0G9Q07900 for ; Tue, 11 Jan 2005 16:16:09 -0800 (PST) Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14]) by mx01.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id j0C0K27O013232 for ; Tue, 11 Jan 2005 16:20:02 -0800 (PST) Received: from fmt-ex01.net.com ([134.56.112.251]) by mx02-int.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id j0C0JxG5000024 for ; Tue, 11 Jan 2005 16:20:01 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F83B.A5446826" Subject: Typo Error in RFC 3666 Date: Tue, 11 Jan 2005 16:14:14 -0800 Message-ID: <985D4DC322E5ED46A3E183D8227094FB0406EB86@fmt-ex01.net.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Typo Error in RFC 3666 Thread-Index: AcT4O6Y0H5j7/LIGQfOUSvAy8BsITg== From: "Mani Devarajan" To: X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: mani_devarajan@net.com X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-0.2 required=5.0 tests=BAYES_01,HTML_70_80, HTML_MESSAGE,UPPERCASE_25_50 autolearn=no version=2.64 X-UID: 0000000022 Status: RO X-Status: A Content-Length: 3960 Lines: 148 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F83B.A5446826 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello Sir, There is typo error in RFC3666 "Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows". =20 Section 3.1. Successful PSTN to SIP call "F2 INVITE Alice -> Proxy1" MUST be "F2 INVITE NGW 1 -> Proxy1" =20 Thanks, Mani =20 =20 ------_=_NextPart_001_01C4F83B.A5446826 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello Sir,

 There is typo error in RFC3666 = “Session Initiation Protocol (SIP)

 Public Switched Telephone Network (PSTN) Call = Flows”.

 

 Section 3.1. Successful PSTN to SIP = call

 “F2 INVITE Alice -> Proxy1”  MUST be “F2 INVITE NGW 1 -> = Proxy1”

 

Thanks,

Mani

 

 

------_=_NextPart_001_01C4F83B.A5446826-- From A.Hoenes@tr-sys.de Mon Jan 3 14:59:47 2005 Return-Path: Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j03Mv1Q26530 for ; Mon, 3 Jan 2005 14:57:23 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA050222925; Mon, 3 Jan 2005 23:55:26 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA17572; Mon, 3 Jan 2005 23:25:28 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200501032225.XAA17572@TR-Sys.de> Subject: RFC 3967 (BCP 97): unsuitable example given To: randy@psg.com, narten@us.ibm.com Date: Mon, 3 Jan 2005 23:25:28 +0100 (MEZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: a.hoenes@tr-sys.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-UID: 0000000028 Status: RO Content-Length: 2413 Lines: 68 Hello, reading the fresh RFC 3967 (== BCP 97), I found that this memo uses examples which are well known, but not very appropriate, for the desired purpose: (1) HMAC [RFC2104] This algorithm - since almost three years - is a US Federal Information Processing Standard! ( FIPS PUB 198, issued '2002 March 6' ; to download a PDF copy (updated '2002 April 8'), see ) This is an active standard published by a recognized standards body. Therefore, *Normative References* to HMAC in future IETF Standards Track documents should always refer to FIPS-198 instead of RFC 2104 ! Remark 1: FIPS-198 in turn refers to RFC 2104 as a readily available source document for the algorithm, but gives a detailed, independent description of the algorithm and its application. Remark 2: Expect alternative MAC algorithms like UMAC, TTMAC, EMAC, and RMAC to get formally standardized soon by various Standards Bodies. For example, the former three Algorithms are already (since Feb. 2003) recommended for new applications to be used in the public administration and economy within the European Union. This has been the result of the NESSIE project - an open contest similar to the AES contest of NIST's), see . (2) MD5 [RFC1321] According to the contemporary cryptographic literature, protocols should now better use SHA-xxx (xxx = [1 / ] 224 / 256 / 384 / 512) as a cryptographic hashing primitive instead of MD5. See - FIPS PUB 180-2, issued '2002 August 1', and amended by Change Note 1, issued '2004 February 25', for SHA-224, and - RFC 3174 (for SHA-1) and RFC 3874 (for SHA-224) -- based on above. FIPS 180-2 should be used for Normative References in future IETF Standards Track documents. Remark 3: SHA-1 (as well as MD5) already is no more recommended for new applications to be used in the public administration and economy within the European Union, see the URL given in Remark 2 above! Best Regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@tr-sys.de Tue Jan 4 01:33:43 2005 Return-Path: Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j049WMQ18596 for ; Tue, 4 Jan 2005 01:32:29 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA052361065; Tue, 4 Jan 2005 10:31:05 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA18052; Tue, 4 Jan 2005 10:30:49 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200501040930.KAA18052@TR-Sys.de> Subject: Errata note for RFC 3944 To: Tyler_Johnson@unc.edu, sokubo@waseda.jp, simao.campos@itu.int Date: Tue, 4 Jan 2005 10:30:49 +0100 (MEZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: a.hoenes@tr-sys.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000030 Status: RO Content-Length: 7524 Lines: 219 Hello, I'd like to mention a couple of typos and other textual issues I've found in the new RFC 3944 authored by you. One general inconsistency observed throughout the text, is related to the use of 'architecture' (singular) vs. 'architectures' (plural). Since the H.350 series recommendations describe a *single* [LDAP directory] architecture [extension], I propose to modify the text to use the singular form in a consistent manner as noted below. Further, there are a lot of places where I miss expected articles ('the' / 'a' / 'an') -- even in the text that is said to be copied from the ITU-T Recommendations. Please check the textual changes proposed below, and decide which of these should be submitted to the RFC editor for inclusion on the RFC Errata web page. Modified lines are emphasized by a change bar "|" in the first column. (1) Change the first 4 (identical) lines of - 'Abstract' on page 1, and - '1. Scope' on page 3, from : "The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to" ... ^^^^^^^^^^^^^^^^!! to: "The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify | a directory services architecture in support of multimedia conferencing protocols. The goal of the architecture is to" ... (2) Change the second paragraph of '1. Scope' on page 3: "H.350 architectures are not intended to change the operation of multimedia conferencing protocols in any way. Rather, they are meant to standardize the way the already defined protocol elements are stored in a directory, so that they can be accessed in a standardized manner." to: | "The H.350 architecture is not intended to change the operation of | multimedia conferencing protocols in any way. Rather, it is meant to standardize the way the already defined protocol elements are stored in a directory, so that they can be accessed in a standardized manner." (3) In lines 2..4 of '4.1. Scope' on page 4, change: ... "Standardized directory services can support association of persons with endpoints, searchable white pages, and clickable dialling." ... to: ... "Standardized directory services | can support the association of persons with endpoints, searchable white pages, and clickable dialling." ... (4) In the bottom half of the second paragraph of section 4.1. on page 5, change: ... "Each of these disparate systems can access the same underlying data source, reducing or eliminating the need to coordinate separate management of each system. A significant benefit to the user is that the management of this data can be incorporated into existing customer management tools, allowing for quick and flexible scaling up of applications. Indeed, many technology providers have already incorporate LDAP into their products, but have been forced to do so without benefit of a standardized schema." ... to: ... "Each of these disparate systems can access the same underlying data source, | reducing or eliminating the need to coordinate the separate management of each system. A significant benefit to the user is that the management of this data can be incorporated into existing customer management tools, allowing for quick and flexible scaling up of applications. Indeed, many technology providers have already incorporate LDAP into their products, but have been forced to do so | without the benefit of a standardized schema." ... (5) In lines 3..7 of the forth paragraph of section 4.1. on page 5, change: ... "LDAP provides a convenient storage location that can be accessed by both call server and endpoint; thus it is possible to use the directory to support endpoint configuration, which is important for simplified operation and supporting user mobility." to: ... "LDAP provides a convenient storage location that can be accessed by both call server | and endpoint; thus it is possible to use the directory to support the endpoint configuration, which is important for simplified operation and supporting user mobility." (6) In the bottom half of the sixth paragraph of section 4.1. on page 6, change: ... "Similarly, commObject contains a pointer, called commOwner, which points to the individual or resource that is associated with the commObject. In this way, people or resources can be associated with endpoints. The only change required in the enterprise directory is the addition of the simple object class commURI. CommObject data may be instantiated in the same or in entirely separate directories, thus allowing flexibility in implementation." to: | ... "Similarly, each commObject contains a pointer, called commOwner, which points to the individual or resource that is associated with the commObject. In this way, people or resources can be associated with endpoints. The only change required | to the enterprise directory is the addition of the simple object class commURI. CommObject data may be instantiated in the same or in | an entirely separate directory, thus allowing flexibility in implementation." (7) In the first lines of the final paragraph of section 4.1.2.1, on page 9, change: "Note that this example and approach demonstrate extension of the general commObject object class, and not any individual H.350.x classes." ... to: | "Note that this example and approach demonstrate an extension of the general commObject object class, and not any individual H.350.x classes." ... (8) In the first line of section 4.2., on page 10, change: "Auxiliary object class that contains the commURI attribute." ... to: | "An Auxiliary object class that contains the commURI attribute." ... (9) Change the 'definition' clause of section 5.2.4., on page 20, from: "Address which specifies the domain location of SIP proxy within a domain. RFC 3261 defines the role of the SIP proxy." to: | "Address which specifies the domain location of a SIP proxy within a domain. RFC 3261 defines the role of the SIP proxy." (10) In the second paragraph of section 6. (6th text line on page 27), change: "(https//:videnet.unc.edu)" to: | "(https://videnet.unc.edu)" (11) In the first two lines of the second paragraph of section 7., on page 27, change: "H.350 does not alter the security architectures of any particular protocol." to: | "H.350 does not alter the security architecture of any particular protocol." Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From picaune@hotmail.com Wed Nov 20 09:53:09 2002 Received: from hotmail.com (f166.pav2.hotmail.com [64.4.37.166]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id gAKHr8C00165 for ; Wed, 20 Nov 2002 09:53:08 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Nov 2002 09:53:03 -0800 Received: from 151.188.36.252 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 20 Nov 2002 17:53:03 GMT X-Originating-IP: [151.188.36.252] From: "Andrew Cook" To: rfc-editor@rfc-editor.org, picaune@hotmail.com Subject: Error in RFC2324 Date: Wed, 20 Nov 2002 12:53:03 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Nov 2002 17:53:03.0715 (UTC) FILETIME=[AC810330:01C290BD] X-UID: 0000000060 Status: RO Content-Length: 465 Lines: 11 There is a descrepancy in RFC2324 regarding the content type for HTCPCP requests. In section 2.1.1, the MIME type is "application/coffee-pot-command", while in section 4 the MIME type is "message/coffepot". I have not been able to reach the author regarding this. Thanks, Andrew Cook _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From bjh21@cus.cam.ac.uk Wed Feb 12 04:55:07 2003 Received: from draco.cus.cam.ac.uk (cusexim@draco.cus.cam.ac.uk [131.111.8.18]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h1CCt6H21858 for ; Wed, 12 Feb 2003 04:55:06 -0800 (PST) Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.12) id 18iwPp-0002OP-00 for rfc-editor@rfc-editor.org; Wed, 12 Feb 2003 12:55:05 +0000 Date: Wed, 12 Feb 2003 12:55:05 +0000 (GMT) From: Ben Harris To: rfc-editor@rfc-editor.org Subject: RFC errata errata Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Ben Harris X-Spam-Status: No, hits=1.5 required=5.0 tests=FROM_ENDS_IN_NUMS,MAILTO_TO_SPAM_ADDR, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Spam-Level: * X-UID: 0000000061 Status: RO Content-Length: 451 Lines: 12 is written in pretty ropey HTML in general, but a particularly serious problem is that less-than and greater-than signs in
 text haven't always been replaced with HTML
entities.

Errata to which this applies include those for RFCs 3108, 2046, 1959,
and 1034.

-- 
Ben Harris
Unix Support, University of Cambridge Computing Service.
E-mail: bjh21@cam.ac.uk  Tel: +44 (0)1223 334728  Fax: +44 (0)1223 334679

From housley@vigilsec.com Mon Feb 17 09:02:56 2003
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5])
	by boreas.isi.edu (8.11.6/8.11.2) with SMTP id h1HH2tH21566
	for ; Mon, 17 Feb 2003 09:02:56 -0800 (PST)
Received: (qmail 5040 invoked from network); 17 Feb 2003 17:02:45 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.185.180)
  by woodstock.binhost.com with SMTP; 17 Feb 2003 17:02:45 -0000
Message-Id: <5.2.0.9.2.20030217120153.0322add0@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 17 Feb 2003 12:02:42 -0500
To: rfc-editor@rfc-editor.org
From: Russ Housley 
Subject: Fwd: Re: mistake in RFC 3126
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
X-Spam-Status: No, hits=0.7 required=5.0
	tests=AWL,CTYPE_JUST_HTML,EMAIL_ATTRIBUTION,FWD_MSG,
	      MSG_ID_ADDED_BY_MTA_3,SPAM_PHRASE_00_01
	version=2.43
X-Spam-Level: 
X-UID: 0000000062
Status: RO
Content-Length: 2775
Lines: 71



Please generate an errata for this mistake.  I made a mistake in the
note I sent a minute ago.  there should NOT be a comma after the
third OPTIONAL.

The correct ASN.1 is as follows:

  RevocationValues ::=  SEQUENCE {
     crlVals           [0] SEQUENCE OF CertificateList     OPTIONAL,
     ocspVals          [1] SEQUENCE OF BasicOCSPResponse   OPTIONAL,
     otherRevVals      [2] OtherRevVals                    OPTIONAL
     }

Thanks,
   Russ


Delivered-To: housley@mail.binhost.com
Delivered-To: alias-582@vigilsec.com
From: "Nystrom, Magnus" <mnystrom@rsasecurity.com>
Reply-To: "Nystrom, Magnus" <magnus@rsasecurity.com>
To: Russ Housley <housley@vigilsec.com>
Date: Mon, 17 Feb 2003 10:20:07 +0100 (W. Europe Standard Time)
Subject: Re: mistake in RFC 3126
X-X-Sender: mnystrom@[10.81.217.7]

Russ,

It most certainly is. "OPTIONAL" is present in ETSI TS 101 733 V1.4.0
(2002-09).

-- Magnus

On Fri, 14 Feb 2003, Russ Housley wrote:

>
> This definitely looks like an error to me.
>
> Russ
>
>
> At 10:27 AM 2/13/2003 +0100, Petra Barzin wrote:
> >Hello,
> >
> >I think there is a mistake in RFC 3126 - Electronic Signature
> >Formats for long term electronic signatures. The definition of the
> >RevocationValues attribute is as follows:
> >
> >   RevocationValues ::=  SEQUENCE {
> >       crlVals           [0] SEQUENCE OF CertificateList     OPTIONAL,
> >       ocspVals          [1] SEQUENCE OF BasicOCSPResponse   OPTIONAL,
> >       otherRevVals      [2] OtherRevVals
> >    }
> >
> >Shouldn't the other revocation values be optional as well?
> >Did I miss something or am I right?
> >
> >Best regards - Petra Barzin
> >
> >
> >
>
From Joerg.Ammon@computacenter.com Tue Mar 4 10:06:30 2003 Received: from dehq0ds2.gecits-eu.com ([195.36.75.51]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h24I6Rv06999 for ; Tue, 4 Mar 2003 10:06:29 -0800 (PST) Sensitivity: Subject: Possible Typo in RFC1195?!? To: rfc-editor@rfc-editor.org Cc: Rfc-admin@faqs.org From: Joerg.Ammon@computacenter.com Date: Tue, 4 Mar 2003 18:57:02 +0100 Message-ID: X-MIMETrack: Serialize by Router on dehq0ds2/DEHQ0DS2/DE(Release 5.0.9 |November 16, 2001) at 03/04/2003 07:05:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=2.5 required=5.0 tests=NO_REAL_NAME,PLING_QUERY,SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: ** X-UID: 0000000064 Status: RO Content-Length: 829 Lines: 28 Hi there, during my current research effort regarding IS-IS, I have encountered a problem with RFC1195. Although I doubt that I am the first to realize an error of this magnitude, I couldn't find an answer to my question even after a considerable research effort. In chapter '3.3 Addressing Routers in ISIS Packets' the RFC describes a standard procedure for deriving NSAP-addresses for IS in IP-only environments. However, the DFI as well as the AA are defined to be 'xx' and 'xx xx xx' respectively, which represents neither a valid decimal nor hexadecimal value. Maybe you could be of assistance and point me to the correct location, where I can find the appropriate information... Thanks for your effort... Best regards Joerg P.S.: Please note that I did receive a delivery failed method with the e-mail-address in cc From A.Hoenes@tr-sys.de Wed Feb 23 12:39:47 2005 Return-Path: Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j1NKdDE04240 for ; Wed, 23 Feb 2005 12:39:19 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA072941057; Wed, 23 Feb 2005 21:37:37 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA02441; Wed, 23 Feb 2005 21:34:35 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200502232034.VAA02441@TR-Sys.de> Subject: RFC 3816 To: quittek@netlab.nec.de, stiemerling@netlab.nec.de, hartenstein@rz.uni-karlsruhe.de Date: Wed, 23 Feb 2005 21:34:34 +0100 (MEZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: a.hoenes@tr-sys.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000086 Status: RO Content-Length: 8756 Lines: 271 Hello, I'd like to note some textual issues I found when reading RFC 3816 (ROHC MIB) authored by you. These remarks might be useful for either - issuing an errata note for publication on the RFC Editor's RFC Errata web page, or else - being kept in mind for the case that there should ever be planned an update to this RFC. I use change bars ('|') in column 1 to emphasize modified text. 1) Minor issues in prose - simply grammar (singular - plural mismatches) 1a) Section 4.1.2., near the bottom of page 5, says: "... But when accessing the rohcInstanceTable (and the rohcContextTable that shares a part of its index with the rohcInstanceTable) there are many cases where either a compressor contexts or a decompressor contexts are of interest. ..." It should say: "... But when accessing the rohcInstanceTable (and the rohcContextTable that shares a part of its index with the rohcInstanceTable) there are many cases | where either a compressor context or a decompressor context are of interest. ..." 1b) Section 4.3.1., near the bottom of page 8, says: "... For compressor contexts it optionally contains managed object containing the numbers of allowed and used packet sizes. ..." It should say: "... For compressor contexts it optionally contains | managed objects containing the numbers of allowed and used packet sizes. ..." 2) Textual issues in the ROHC-MIB definition 2a) The DESCRIPTION clause of the `RohcChannelIdentifierOrZero' TEXTUAL-CONVENTION (near the bottom of page 10), "A number identifying a channel. The value of 0 is indicates that no channel is identified." should be: "A number identifying a channel. | The value of 0 indicates that no channel is identified." 2b) The DESCRIPTION clause for `rohcChannelEntry' (extending from the last 2 lines on page 11 to page 12) contains inappropriate text -- obviously borrowed from the Script MIB (RFC 3165, page 18, last 3 lines) and unintentionally left un-edited: "An entry describing a particular script. Every script that is stored in non-volatile memory is required to appear in this script table. Note ..." This should be replaced by appropriate text, e.g., | "An entry describing a particular ROHC channel. Note ..." [ Please add whatever you consider appropriate here! ] 2c) The DESCRIPTION clause for `rohcChannelFeedbackFor', on page 13, seems to me to be not strict enough. Perhaps, "If no feedback information is transferred on this channel, then the value of this ID is 0. If the channel type is set to notInUse(1), then the value of this object must be 0. If the channel type is rohc(2) and the value of this object is a valid channel ID, then feedback information is piggy-backed on the ROHC channel. If the channel type is should be replaced by: "If no feedback information is transferred on this channel, then the value of this ID is 0. If the channel type is set to notInUse(1), then the value of this object must be 0. If the channel type is rohc(2) and the value of this object | is non-zero, then feedback information for this channel is | piggy-backed and/or interspersed on the same ROHC channel; | hence the value of this object must be equal to the value | of the indexing rohcChannelID. If the channel type is dedicatedFeedback(3), ..." [or similar]. Rationale: As far as I understand RFC 3095 (Section 5.2.2 et al.), it is not possible to intersperse or/and piggyback feedback information of another channel on a ROHC channel carrying payload packets. 2d) The DESCRIPTION clause for `rohcInstanceVendor', on page 15, contains two issues. Its first sentence contains the word "description" instead of "compression", and the second sentence is subject to mis-interpretation due to unfortunate placement of the words "allocated for the vendor". I propose to change the text: "An object identifier that identifies the vendor who provides the implementation of robust header description. This object identifier SHALL point to the object identifier directly below the enterprise object identifier {1 3 6 1 4 1} allocated for the vendor. ... to better read: "An object identifier that identifies the vendor who | provides the implementation of robust header compression. This object identifier SHALL point to the object identifier | allocated for the vendor directly below the `enterprise' | object identifier {1 3 6 1 4 1}. ... 2e) The DESCRIPTION clause for `rohcInstanceContextStorageTime', on page 17, says: ... . The value of this object is used to initialize rohcContexStorageTime object when a new context is created. Changing ... where it should better say: ... . The value of this object is used | to initialize the rohcContexStorageTime object when a new context is created. Changing ... 2f) To better distinguish the counters for payload (i. e. IP) packets from the counters IR packets, I recommend to enhance the sentence: "Counter of all packets passing this instance." to read: | "Counter of all IP packets passing this instance." in the DESCRIPTION clauses of following two objects: o `rohcInstancePackets' (page 18), o `rohcContextPackets' (page 25). 2g) The DESCRIPTION clause for `rohcProfileVendor', on page 21, contains the same two issues as the DESCRIPTION clause for `rohcInstanceVendor'. Hence, the modification given above, under 2d), should be applied here as well. 2h) The DESCRIPTION clause for `rohcProfileNegotiated', on page 21, contains a small typo. It says: "When retrieved, this boolean object returns true if the profile has been negotiated to be used at the instance, i.e., is supported also be the corresponding compressor/decompressor." It should say: "When retrieved, this boolean object returns true if the profile has been negotiated to be used at | the instance, i.e., is supported also by the corresponding compressor/decompressor." 2i) The DESCRIPTION clause for `rohcContextStorageTime', on page 24, contains an improper self-reference. Therefore, replace the text: ... . This object returns the remaining time that the row may exist before it is aged out. The object is initialized with the value of the associated rohcContextStorageTime object. After expiration ... by: ... . This object returns the remaining time that the row may exist before it is aged out. The object is initialized with the value of the associated | rohcInstanceContextStorageTime object. After expiration ... ^^^^^^^^ 2j) The DESCRIPTION clauses for `ContextAllPacketsMeanSize' and `rohcContextAllHeadersMeanSize', on page 28, are concluded with the sentence: The mean value is given in byte rounded to the next integer value." This should be: The mean value is given in bytes rounded to the next integer value." [ Note: I wished this RFC (and many other MIB RFCs, too) would make frequent use of the UNITS clause specified in STD 58 ! ] 3) Textual issues in the ROHC-RTP-MIB definition 3a) The DESCRIPTION clause for `rohcRtpContextNACKs', on page 42, says: "The number of all dynamic negative feedbacks (ACK) sent or received in this context, respectively. ..." It should say: | "The number of all dynamic negative feedbacks (NACK) sent or received in this context, respectively. ..." 3b) The DESCRIPTION clause for `rohcRtpContextSNACKs', on page 42, says: "The number of all static negative feedbacks (ACK) sent or received in this context, respectively. ..." It should say: | "The number of all static negative feedbacks (STATIC-NACK) | sent or received in this context, respectively. ..." Please comment. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@tr-sys.de Mon Feb 28 01:11:29 2005 Return-Path: Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j1S9B0E04387 for ; Mon, 28 Feb 2005 01:11:06 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA097721768; Mon, 28 Feb 2005 10:09:28 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA10933; Mon, 28 Feb 2005 10:09:20 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200502280909.KAA10933@TR-Sys.de> Subject: RFC 4009 To: khopri@kisa.or.kr, sjlee@kisa.or.kr, jykim@kisa.or.kr, jilee@kisa.or.kr Date: Mon, 28 Feb 2005 10:09:20 +0100 (MEZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: a.hoenes@tr-sys.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000087 Status: RO Content-Length: 3438 Lines: 97 Hello, I just picked up and read the new RFC 4009 authored by you, to find significant concerns with section 2.2. (on pages 3 and 4 of the RFC): (A) Unfortunately, within a few lines in the RFC text, the variable name 'X' gets used for two very distinct purposes and contexts: o X = X0 || X1 || X2 || X3 (2) ... the 32 bit wide input to the function G o X used as formal argument in the defining equations for the 'SS-boxes' SS0 ... SS3 ... a single octet (8 bit wide entity), [application of the formulas - see (3) below - will substitute X0, ..., X3 in turn for the arguments] Perhaps, it would have been better to use another symbol, e.g. 'x', for the latter purpose. (B) As far as I can see, feeding the definition of the SS-boxes given in the last 4 text/formule lines on page 3 into the formula on top of page 4, Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3) does ***NOT*** yield the same result as using the primary defining formulas given for Z0 ... Z3 in the first formula block of section 2.2., together with Z = Z0 || Z1 || Z2 || Z3 (1). I suspect a mis-ordering in the use of m0 ... m3 in the equations defining SS0 ... SS3 : With regard to the formulas (1), (2), and (3) (as numbered above), the 'matrix' pattern of the 4x4 terms in braces { ... } , obtained from the formula block defining SS0 ... SS3 by substitution of Xi for the argument of SSi (i=0,1,2,3) - as required in (3) -, should be the matrix transpose of the pattern of the same terms in braces appearing in the formula block defining Z0 ... Z3 , e. g. the first 'column' of {...} terms for SSi() should contain the {...} terms appearing in the formula for Z0. But this is not the case. Therefore, I suspect that the last 6 text/formula lines on page 3 of RFC 4009 should in fact read (including the enhancement from (A) above): " To increase the efficiency of the G function, four extended S-boxes 'SS-box' (See Appendix A.2) are defined as follows: SS0(x)= {S1(x) & m0} || {S1(x) & m1} || {S1(x) & m2} || {S1(x) & m3} SS1(x)= {S2(x) & m1} || {S2(x) & m2} || {S2(x) & m3} || {S2(x) & m0} SS2(x)= {S1(x) & m2} || {S1(x) & m3} || {S1(x) & m0} || {S1(x) & m1} SS3(x)= {S2(x) & m3} || {S2(x) & m0} || {S2(x) & m1} || {S2(x) & m2} " Please check and comment. If you agree with my arguments, we should immediately submit an errata note for these issues to the RFC Editor for publication on the RFC Errata web page. In this case, I also recommend to include a textual enhancement for the first sentence of section 2.3., replacing: "The key schedule generates each round subkeys." by: "The key schedule generates subkeys for each round." And finally, for completeness, it would have been useful as well to give additional Informational Reference(s) for the seedMAC (and the [seed]CBC) algorithm(s)/construct(s) mentioned in section 2.5. - e.g. RFC 3610 (and RFC 2451 / NIST SP 800-38A) [?]. Best Regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From wayne@schlitt.net Thu May 12 16:33:59 2005 Return-Path: Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4CNXR610964 for ; Thu, 12 May 2005 16:33:27 -0700 (PDT) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DWNBC-0000gk-2U for rfc-editor@rfc-editor.org; Thu, 12 May 2005 18:33:26 -0500 To: rfc-editor@rfc-editor.org From: wayne Content-Type: text/plain; charset=US-ASCII User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) Date: Thu, 12 May 2005 18:33:21 -0500 Message-ID: MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: rfc-editor@rfc-editor.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: errata for RFC2821 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: wayne@schlitt.net X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000094 Status: RO Content-Length: 222 Lines: 8 In several places, RFC2821 referese to "section 2.4.1.". Unfortunately there *is* no section 2.4.1. To be quite honest, I'm really not sure what the intended section number is. It doesn't appear obvious to me. -wayne From kzm@cisco.com Thu May 19 11:49:56 2005 Return-Path: Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4JImJ327663 for ; Thu, 19 May 2005 11:48:20 -0700 (PDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 19 May 2005 11:48:15 -0700 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4JIm9O3009617 for ; Thu, 19 May 2005 11:48:10 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA02358 for rfc-editor@rfc-editor.org; Thu, 19 May 2005 11:48:12 -0700 (PDT) From: Keith McCloghrie Message-Id: <200505191848.LAA02358@cisco.com> Subject: typo in RFC 2234 ? To: rfc-editor@rfc-editor.org Date: Thu, 19 May 2005 11:48:12 -0700 (PDT) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: kzm@cisco.com X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-UID: 0000000098 Status: RO Content-Length: 388 Lines: 15 Hi, FYI -- I happened to be looking at http://www.ietf.org/rfc/rfc2234.txt and noticed this text on its page 5: LINEAR WHITE SPACE: Concatenation is ... ... ... ... ... ... to be freelyPand implicitlyPinterspersed around ... presumably, each "P" character should be a parenthesis and a space ?? Keith. From \rfc-ed@ISI.EDU Sat Apr 14 09:12:02 2001 Subject: About RFC 2184 MIME-Version: 1.0 Date: Sat, 14 Apr 2001 18:11:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About RFC 2184 Thread-Index: AcDE/Y4w9MZ9hH8RT1mL/ooe91vAgA== From: =?iso-8859-1?Q?Terje_Br=E5ten?= To: , , Cc: =?iso-8859-1?Q?Terje_Br=E5ten?= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id f3EGC1500340 X-Lines: 75 Content-Type: text/plain; charset="iso-8859-1" X-UID: 0000000105 Status: RO Content-Length: 2454 Lines: 75 I would like to address some inconsistencies in RFC 2184 regarding parameter values in MIME header. It is two inconsistencies I would like to point out. The first one is about at what number should the counting of the parameter parts start (0 or 1). A part of page 3 of RFC 2184 reads: > are being used to encapsulate a single parameter value. The count > starts at 0 and increments by 1 for each subsequent section of the > parameter value. Decimal values are used and neither leading zeroes > nor gaps in the sequence are allowed. > > The original parameter value is recovered by concatenating the > various sections of the parameter, in order. For example, the > content-type field > > Content-Type: message/external-body; access-type=URL; > URL*0="ftp://"; > URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar" > This clearly states that the numbering of the parameter parts should start at 0. But further down in the RFC an example is used where the count starts with 1. At page 4 of RFC 2184 you can read: >4.1. Combining Character Set, Language, and Parameter Continuations > > Character set and language information may be combined with the > parameter continuation mechanism. For example: > > Content-Type: application/x-stuff > title*1*=us-ascii'en'This%20is%20even%20more%20 > title*2*=%2A%2A%2Afun%2A%2A%2A%20 > title*3="isn't it!" And in section 7 "Modificatons to MIME ABNF" it clearly states that the counting shall begin with 1. Note at the end of page 5, intial-section is defined as: > initial-section := "*1" And on the start of page 6 you have the definition: > other-sections := "*" (("2" / "3" / "4" / "5" / > "6" / "7" / "8" / "9") *DIGIT) / > ("1" 1*DIGIT)) If you follow this ABNF, the counting must start at 1 and not 0. The other thing about RFC 2184 that is clearly wrong, is the change of the ABNF given in RFC 2047 for encoded-words. RFC 2184 reads: > The ABNF given in RFC 2047 for encoded-words is: > > encoded-word := "=?" charset "?" encoding "?" encoded-text "?=" > > This specification changes this ABNF to: > > encoded-word := "=?" charset ["*" language] "?" encoded-text "?=" The correct change would have be: This specification changes this ABNF to: encoded-word := "=?" charset ["*" language] "?" encoding "?" encoded-text "?=" -- Terje Bråten E-mail: terje@oslo.kvalito.no From rfc-ed@ISI.EDU Thu Jan 31 20:46:05 2002 From: "Suman Choudhary B." To: rfc-editor@rfc-editor.org Date: Fri, 1 Feb 2002 10:19:15 +0530 Subject: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_10_22_16_Friday_February_01_2002_23041" X-AntiVirus: scanned by AMaViS 0.2.1 X-Lines: 118 X-UID: 0000000115 Status: RO Content-Length: 3604 Lines: 115 ----=_NextPart_ST_10_22_16_Friday_February_01_2002_23041 Content-Type: text/plain; charset="gb2312" X-Sun-Content-Length: 1074 Dear Sir, In the section 14.1. A.1 Coding of wildcards in RFC3015 Megaco Protocol 1.0 The following statement appears to be gramatically incomplete. I think a keyword has been missed out. Could you clarify the same for me ? Bits 0 through 5 of the wildcarding field specify the bit position in the Termination ID at which the starts. I feel that some keyword should be present between the and starts. Please reply at the earliest possible convenience of yours.. Awaiting your reply, Regards, Suman Choudhary -------------------------------------------------------------------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Huawei Technologies India Pvt. Ltd. ----=_NextPart_ST_10_22_16_Friday_February_01_2002_23041 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Sun-Content-Length: 2170

Dear Sir,


In the section

14.1. A.1 Coding of wildcards<= /B>

in RFC3015 Megaco Protocol 1.0<= /B>

The following statement appears to be gramatically= incomplete.
I think a keyword has been missed out. Could you = clarify the same
for me ?

Bits 0 through 5 of the wildcarding field specify = the bit position in the
   Termination ID at which
the st= arts.

I feel that some keyword should be present between= the and starts.

Please reply at the earliest possible convenience = of yours..

Awaiting your reply,

Regards,

Suman Choudhary

---------------------------------------------------------------------------= -----------------------------------------
This email and any files trans= mitted with it are confidential and
intended solely for the use of the i= ndividual or entity to whom
they are addressed. If you have received thi= s email in error please notify the
originator of the message.

An= y views expressed in this message are those of the individual
sender, ex= cept where the sender specifies and with authority,
states them to be th= e views of Huawei Technologies India Pvt. Ltd. ----=_NextPart_ST_10_22_16_Friday_February_01_2002_23041-- From rfc-ed@ISI.EDU Tue Feb 26 17:12:54 2002 From: RFC Editor Date: Wed, 27 Feb 2002 01:12:39 GMT To: mtxinu!excelan!avnish@ucbvax.berkeley.edu Subject: rfc1001 Cc: rfc-ed@ISI.EDU, sengehest@soningsdyktig.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="-LA_F2204651367R-3A-1123701664=:550NCE.cde_" X-AntiVirus: scanned by AMaViS 0.2.1 X-Lines: 103 X-UID: 0000000116 Status: RO Content-Length: 2863 Lines: 104 ---LA_F2204651367R-3A-1123701664=:550NCE.cde_ Content-Type: Text/plain; charset=X-us-ascii; name="text" Content-Description: text Avnish, We received the comment below regarding RFC 1001. Please let us know if this is something that needs to be added to our errata page. If so, please formulate the text similar to that found at: http://www.rfc-editor.org/errata.html Thank you. RFC Editor ----- Begin Included Message ----- >From rfc-ed@ISI.EDU Mon Feb 25 06:36:21 2002 From: "bla bla" To: Subject: rfc1001 Date: Mon, 25 Feb 2002 15:48:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C1BE13.E92A3CC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-AntiVirus: scanned by AMaViS 0.2.1 Content-Length: 2084 Hi there. I found something strange in rfc1001 Maybe my code is wrong, but it returns "Tge NetBIOS tame" instead of "The NetBIOS name" when I try to encode FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF "For example, the NetBIOS name "The NetBIOS name" in the NetBIOS scope "SCOPE.ID.COM" would be represented at level one by the ASCII character string: FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM" ----- End Included Message ----- ---LA_F2204651367R-3A-1123701664=:550NCE.cde_ Content-Type: Application/X-sun-html Content-Transfer-Encoding: quoted-printable
Hi there.
 
I found something strange in = rfc1001
Maybe my code is wrong, but it returns = "Tge NetBIOS=20 tame"
instead of "The NetBIOS name" when I = try to=20 encode
FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF
 
"For example, the NetBIOS name "The NetBIOS = name" in the=20 NetBIOS scope

"SCOPE.ID.COM" would be represented at level one = by the=20 ASCII

character string:

FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM"

 

 

 

---LA_F2204651367R-3A-1123701664=:550NCE.cde_-- From rfc-ed@ISI.EDU Sun Mar 24 08:13:36 2002 Date: Sun, 24 Mar 2002 17:12:16 +0100 (CET) From: Sebastian Kulpa To: rfc-editor@rfc-editor.org Subject: Error in RFC 2834 MIME-Version: 1.0 X-AntiVirus: scanned by AMaViS 0.2.1 X-Lines: 53 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-UID: 0000000117 Status: RO Content-Length: 2342 Lines: 53 I think there's small error in rfc 2834 "ARP and IP Broadcast over HIPPI-800". when i'm right, please contact me regards, Sebastian Kulpa Technical University of Gdansk, Poland On page 19 : Data sizes and field meaning: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type of the protocol fields below ar$op 16 bits Operation code (request, reply, or NAK) ar$pln 8 bits byte length of each protocol address ar$rhl 8 bits requester's HIPPI hardware address length (q) <---- THERE IS A FIELD ar$rhl ar$thl 8 bits target's HIPPI hardware address length (x) ar$rpa 32 bits requester's protocol address ar$tpa 32 bits target's protocol address ar$rha qbytes requester's HIPPI Hardware address ar$tha xbytes target's HIPPI Hardware address On page 20, there is : Where : ar$hrd - SHALL contain 28. (HIPARP) ar$pro - SHALL contain the IP protocol code 2048 (decimal). ar$op - SHALL contain the operational value (decimal): 1 for HARP_REQUESTs 2 for HARP_REPLYs 8 for InHARP_REQUESTs 9 for InHARP_REPLYs 10 for HARP_NAK ar$pln - SHALL contain 4. ar$rln - SHALL contain 10 IF this is a HIPPI-800 HW address <---- THERE SHOULD BE A FIELD ar$rhl TOO, not as$rln... ELSE, for HIPPI-6400, it SHALL contain 6. ar$thl - SHALL contain 10 IF this is a HIPPI-800 HW address ELSE, for HIPPI-6400, it SHALL contain 6. ar$rha - in requests and NAKs it SHALL contain the requester's HW address. In replies it SHALL contain the target port's HW address. ar$rpa - in requests and NAKs it SHALL contain the requester's IP address if known, otherwise zero. In other replies it SHALL contain the target port's IP address. ar$tha - in requests and NAKs it SHALL contain the target's HW address if known, otherwise zero. In other replies it SHALL contain the requester's HW addressA. ar$tpa - in requests and NAKs it SHALL contain the target's IP address if known, otherwise zero. In other replies it SHALL contain the requester's IP address. From rfc-ed@ISI.EDU Tue Apr 23 13:19:02 2002 X-mProtect: <200204232018> Nokia Silicon Valley Messaging Protection Date: Tue, 23 Apr 2002 13:18:44 -0700 From: "Charles E. Perkins" X-Accept-Language: en MIME-Version: 1.0 To: RFC Editor , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts CC: Thomas Narten , Erik Nordmark Subject: Errata page for RFC 3220 Content-Type: multipart/mixed; boundary="------------28F1CB42EC7632CEE05D2B85" X-AntiVirus: scanned by AMaViS 0.2.1 X-Lines: 103 X-UID: 0000000119 Status: RO Content-Length: 3763 Lines: 101 --------------28F1CB42EC7632CEE05D2B85 Content-Type: text/plain; charset="us-ascii" X-Sun-Content-Length: 232 Hello folks, There is some text missing from RFC 3220. I have prepared the attached file as Errata, to be posted on the Errata page I reckon. Please let me know if there is a procedure I should be following. Regards, Charlie P. --------------28F1CB42EC7632CEE05D2B85 Content-Type: text/plain; charset="us-ascii"; name="ForRFCed-err.txt" Content-Disposition: inline; filename="ForRFCed-err.txt" X-Sun-Content-Length: 3182 This errata lists two corrections. Correction 1: to be inserted after current page 41: ======================================================================== Internet Draft IP Mobility Support 19 December 2001 The Lifetime field is chosen as follows: - If the mobile node is registering with a foreign agent, the Lifetime SHOULD NOT exceed the value in the Registration Lifetime field of the Agent Advertisement message received from the foreign agent. When the method by which the care-of address is learned does not include a Lifetime, the default ICMP Router Advertisement Lifetime (1800 seconds) MAY be used. - The mobile node MAY ask a home agent to delete a particular mobility binding, by sending a Registration Request with the care-of address for this binding, with the Lifetime field set to zero (Section 3.8.2). - Similarly, a Lifetime of zero is used when the mobile node deregisters all care-of addresses, such as upon returning home. The Home Address field MUST be set to the mobile node's home address, if this information is known. Otherwise, the Home Address MUST be set to zeroes. The Home Agent field MUST be set to the address of the mobile node's home agent, if the mobile node knows this address. Otherwise, the mobile node MAY use dynamic home agent address resolution to learn the address of its home agent. In this case, the mobile node MUST set the Home Agent field to the subnet-directed broadcast address of the mobile node's home network. Each home agent receiving such a Registration Request with a broadcast destination address MUST reject the mobile node's registration and SHOULD return a rejection Registration Reply indicating its unicast IP address for use by the mobile node in a future registration attempt. The Care-of Address field MUST be set to the value of the particular care-of address that the mobile node wishes to (de)register. In the special case in which a mobile node wishes to deregister all care-of addresses, it MUST set this field to its home address. The mobile node chooses the Identification field in accordance with the style of replay protection it uses with its home agent. This is part of the mobility security association the mobile node shares with its home agent. See Section 5.7 for the method by which the mobile node computes the Identification field. 3.6.1.3. Extensions This section describes the ordering of any mandatory and any optional Extensions that a mobile node appends to a Registration Request. This following ordering MUST be followed: Perkins, editor Expires 19 June 2002 [Page 41.5] ======================================================================== Correction 2: to be inserted before the line on page 74 starting "of any Registration..." ======================================================================== The mobile node MUST verify that the low-order 32 bits ======================================================================== --------------28F1CB42EC7632CEE05D2B85-- From rfc-ed@ISI.EDU Wed Sep 4 05:02:11 2002 Subject: Error in RFC 2834 To: rfc-editor@rfc-editor.org, iesg@ietf.org From: Sebastian.Kulpa@comtegra.pl Date: Wed, 4 Sep 2002 13:53:47 +0200 X-MIMETrack: Serialize by Router on notes1/ACL(Release 5.0.8 |June 18, 2001) at 2002-09-04 13:53:55 MIME-Version: 1.0 X-AntiVirus: scanned by AMaViS 0.2.1 X-Lines: 59 Content-Type: text/plain; charset="us-ascii" X-UID: 0000000125 Status: RO Content-Length: 2453 Lines: 59 There's an error in document rfc 2834 titled "ARP and IP Broadcast over HIPPI-800". On page 19 : Data sizes and field meaning: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type of the protocol fields below ar$op 16 bits Operation code (request, reply, or NAK) ar$pln 8 bits byte length of each protocol address ar$rhl 8 bits requester's HIPPI hardware address length (q) <---- THERE IS A FIELD ar$rhl ar$thl 8 bits target's HIPPI hardware address length (x) ar$rpa 32 bits requester's protocol address ar$tpa 32 bits target's protocol address ar$rha qbytes requester's HIPPI Hardware address ar$tha xbytes target's HIPPI Hardware address On page 20, there is : Where : ar$hrd - SHALL contain 28. (HIPARP) ar$pro - SHALL contain the IP protocol code 2048 (decimal). ar$op - SHALL contain the operational value (decimal): 1 for HARP_REQUESTs 2 for HARP_REPLYs 8 for InHARP_REQUESTs 9 for InHARP_REPLYs 10 for HARP_NAK ar$pln - SHALL contain 4. ar$rln - SHALL contain 10 IF this is a HIPPI-800 HW address <---- THERE SHOULD BE A FIELD "ar$rhl" TOO, not as$rln... ELSE, for HIPPI-6400, it SHALL contain 6. ar$thl - SHALL contain 10 IF this is a HIPPI-800 HW address ELSE, for HIPPI-6400, it SHALL contain 6. ar$rha - in requests and NAKs it SHALL contain the requester's HW address. In replies it SHALL contain the target port's HW address. ar$rpa - in requests and NAKs it SHALL contain the requester's IP address if known, otherwise zero. In other replies it SHALL contain the target port's IP address. ar$tha - in requests and NAKs it SHALL contain the target's HW address if known, otherwise zero. In other replies it SHALL contain the requester's HW addressA. ar$tpa - in requests and NAKs it SHALL contain the target's IP address if known, otherwise zero. In other replies it SHALL contain the requester's IP address. Sebastian Kulpa System engineer Sebastian.Kulpa@comtegra.pl ___________________________ Comtegra Sp. z o.o. tel. (48 22) 685 50 80, fax. (48 22) 685 19 55 ul. Karola Miarki 11 D, 01-496 Warszawa http://www.comtegra.pl From rfc-ed@ISI.EDU Tue Aug 10 10:56:04 2004 To: rfc-editor@rfc-editor.org, ietf-smtp@imc.org Subject: Buglet in RFC3461 - DSN, section 4.2. From: Valdis.Kletnieks@vt.edu Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1085894988P"; micalg="pgp-sha1"; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 10 Aug 2004 13:53:39 -0400 X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 X-Lines: 32 X-UID: 0000000128 Status: RO Content-Length: 1181 Lines: 34 --==_Exmh_-1085894988P Content-Type: text/plain; charset="us-ascii" X-Sun-Content-Length: 743 (Will the appropriate people please make a note of this for whenever we turn the crank on 3461 again?) RFC3461, section 4.2 says: The "addr-type" portion MUST be an IANA-registered electronic mail address-type (as defined in [3]), while the "xtext" portion contains an encoded representation of the original recipient address using the rules in section 5 of this document. The entire ORCPT parameter MAY be up to 500 characters in length. In fact, the encoding rules are in section *4*. Much hilarity ensued as an MUA enhancement I was writing failed to escape a '+' because section 5 didn't say anything about the plus or equals characters, while the section 4 that I didn't read did say something about escaping them.... --==_Exmh_-1085894988P Content-Type: application/pgp-signature X-Sun-Content-Length: 226 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFBGQuicC3lWbTT17ARAtpDAKCaC6lgCphpsUBkBcHeILJrieKLHwCfVTci h7hv4GN7cq1ZpUeETfhxUZ0= =a8gr -----END PGP SIGNATURE----- --==_Exmh_-1085894988P-- From rfc-ed@ISI.EDU Wed Oct 20 03:34:05 2004 From: Alfred =?hp-roman8?B?SM5uZXM=?= Subject: RFC 3886 To: eric@sendmail.com, rfc-editor@rfc-editor.org Date: Wed, 20 Oct 2004 12:27:53 +0200 (MESZ) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Lines: 93 Content-Type: text/plain; charset="hp-roman8" X-UID: 0000000130 Status: RO Content-Length: 3052 Lines: 93 Hello, I've found a few issues with the recently published RFC 3886 authored by you. According to published policy, a few of these might require consent by the author(s) to be published on the RFC Editor's "RFC Errata" web page -- so please confirm if you agree. (1) RFC 3886, Section 3., 2nd text line on page 3: looking into RFC 3887, it seems appropriate to replace: "A Message Tracking Status Motification (MTSN) is intended to be returned as the body of a Message Tracking request [RFC-MTRK-MTQP]." ^^^^^^^ by: "A Message Tracking Status Motification (MTSN) is intended to be returned as the body of a Message Tracking response [RFC-MTRK-MTQP]." (2) RFC 3886, Section 3.1., 2nd text line of major text paragraph, in the middle of page 3, change: ... "That body consists of one or more "fields" formatted to according to" ... ^^^ by: ... "That body consists of one or more "fields" formatted according to" ... (3) RFC 3886, Sections 3.3.5, 3.3.6, and 3.3.7 (on page 7): The first line of these sections seem to have inhereted some undue editing history inserting the appropriate references; the word "Reference" should be removed in every case; therefore a) in section 3.3.5 replace: "The Remote-MTA field is defined as in section Reference 2.3.5 of [RFC-DSN-STAT]." ... ^^^^^^^^^^ by: "The Remote-MTA field is defined as in section 2.3.5 of [RFC-DSN-STAT]." ... b) in section 3.3.6 replace: "The Last-Attempt-Date field is defined as in section Reference 2.3.7 of [RFC-DSN-STAT]." ... ^^^^^^^^^^ by: "The Last-Attempt-Date field is defined as in section 2.3.7 of [RFC-DSN-STAT]." ... c) in section 3.3.7 replace: "The Will-Retry-Until field is defined as in section Reference 2.3.9 of [RFC-DSN-STAT]." ... ^^^^^^^^^^ by: "The Will-Retry-Until field is defined as in section 2.3.9 of [RFC-DSN-STAT]." ... (4) The text of RFC 3886, Section 5. (on page 8) appears to by copied unchanged from RFC 3885 and thus does not fit the context of RFC 3885. It should be changed from: "IANA has registered the SMTP extension defined in section 3." ^^^^^^^^^^^^^^ to: "IANA has registered the MIME subtype defined in section 3." (or similarly). Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From rfc-ed@ISI.EDU Wed Oct 20 03:42:25 2004 From: Alfred =?hp-roman8?B?SM5uZXM=?= Subject: RFC 3887 To: tony+msgtrk@maillennium.att.com, rfc-editor@rfc-editor.org Date: Wed, 20 Oct 2004 12:39:13 +0200 (MESZ) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Lines: 42 Content-Type: text/plain; charset="hp-roman8" X-UID: 0000000131 Status: RO Content-Length: 1284 Lines: 42 Hello, I've found two typos in the recently published RFC 3887 : o The bottom of page 11 (in section 5.), ... "All optional text provided with the COMMENT command are ignored." ^^^ should probably read: ... "All optional text provided with the COMMENT command is ignored." o Similarly, in the 3rd paragraph of section 11. (middle of page 17), replace: ... "Thus, if an MTQP client/server pair decide to use TLS confidentially," ... ^^ by: ... "Thus, if an MTQP client/server pair decides to use TLS confidentially," ... RFC-Editor: According to published policy, please include these remarks in the 'RFC Errata' web page. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From rfc-ed@ISI.EDU Wed Oct 20 05:17:05 2004 From: Alfred =?hp-roman8?B?SM5uZXM=?= Subject: RFC 3798 To: tony+rfc3798@maillennium.att.com, GregV@ieee.org, rfc-editor@rfc-editor.org Date: Wed, 20 Oct 2004 14:13:07 +0200 (MESZ) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Lines: 108 Content-Type: text/plain; charset="hp-roman8" X-UID: 0000000132 Status: RO Content-Length: 3465 Lines: 108 Hello, triggered by the recent RFC 3886, I have re-visited RFC 3798 and found a serious general issue with that document: The 'Changes from RFC 2298' -- as listed in Appendix A on page 29 of RFC 3798 -- in fact have NOT been applied consistently to this document. As a result, the textual description of actions throughout RFC 3398 often remains in contradiction to the new, restricted MDN grammar! Details: (1) disposition types ===================== Appendix A says: The dispositions "denied" and "failed" were removed from the document reflecting the lack of implementation or usage ... Now, the syntax production "disposition-type" in section 3.2.6. (on page 14) and section 7. (on mid-page 22) has been changed to read: disposition-type = "displayed" / "deleted" This means that the RFC 2298 disposition types "dispatched" and "processed" have been removed from the syntax definitions as well! Thus, either Appendix A lacks mentioning these removals OR these items should not have been removed from the syntax definitions. Nevertheless, all these disposition types removed from the syntax are mentioned at many places througout RFC 3798: o "dispatched" : - section 3.2.6. , final paragraph of the section on page 16 - section 4. , third-to-last bullet on page 17 - section 4. , first bullet on page 18 o "processed" : - section 4. , third-to-last bullet on page 17 - section 4. , first bullet on page 18 - section 5. , 4th paragraph on page 18 o "denied" : - section 2.1. , bottom of page 4 - section 2.1. , end of 3rd paragraph on page 5 - section 4. , third-to-last bullet on page 17 - section 4. , first bullet on page 18 - section 6.2. , end of first paragraph on page 19 o "failed" : - section 2.2. , middle of second-to-last paragraph on page 6 - section 2.2. , middle of second paragraph on page 7 (twice) - section 2.2. , third paragraph on page 7 (twice) - section 3.2.7. , in 2nd text line, on page 16 (mis-spelled "failure" there) - section 4. , third-to-last bullet on page 17 - section 4. , first bullet on page 18 All these places in the text deal with the issue/sending/generation of MDNs with the named deprecated disposition types (it would be acceptable to talk about what to do with *received* such disposition types for backwards compatibility with RFC 2298) ! (2) disposition modifiers ========================= Appendix A says: The disposition modifiers "warning", "superseded", "expired", "mailbox-terminated" have not seen actual implementation. They have been deleted from this document. Accordingly, the syntax production "disposition-type" in section 3.2.6. (on page 14) and section 7. (on mid-page 22) has been changed to read: disposition-modifier = "error" / disposition-modifier-extension Nevertheless, one of these 'removed' modifiers disposition is mentioned in the text of RFC 3798: o "warning" : - section 3.2.7. , 3rd line of text on page 16 These inconsistencies urgently need clarification! Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From rfc-ed@ISI.EDU Sat Oct 23 22:10:39 2004 Date: Sat, 23 Oct 2004 22:08:35 -0700 From: Alex Zinin X-Priority: 3 (Normal) To: "Adrian Farrel" CC: "Loa Andersson" , rfc-editor@rfc-editor.org Subject: Re: snafu with RFC3468 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.64 X-Lines: 35 Content-Type: text/plain; charset="us-ascii" X-UID: 0000000133 Status: RO Content-Length: 796 Lines: 35 Adrian, I think we should fix this. I'm cc'ing the RFC Editor guys. Let's see what they say. Thanks for looking at this. -- Alex http://www.psg.com/~zinin Saturday, October 23, 2004, 3:23:51 PM, Adrian Farrel wrote: > Hi, > RFC3468 documents the MPLS WG's decision to ice CR-LDP. > I was just researching why some folks (in China) think it is OK to do CR-LDP GMPLS and I > discovered that there is no link in the repository between the various RFCs. > Thus, RFC3468 is not marked as updating RFC3212 (CR-LDP base spec) in the registry. > Do you think it is possible/worth changing this? > The RFCs updated by 3468 are > 3212 > 3472 > 3475 > 3476 > Yes! Three of these are numerically later than 3468. This arises because of the famous RFC > Editor queue backlog. > Cheers, > A From rfc-ed@ISI.EDU Wed Dec 8 12:50:23 2004 From: Peter Saint-Andre To: rfc-editor@rfc-editor.org Subject: Fwd: typo in RFC 3920 User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X) Date: Wed, 08 Dec 2004 13:44:34 -0700 X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Lines: 21 X-UID: 0000000144 Status: RO Content-Length: 668 Lines: 21 > From: Peter Saint-Andre > Subject: typo in RFC 3920 > Date: Wed, 08 Dec 2004 13:36:13 -0700 > Newsgroups: gmane.ietf.xmpp > Message-ID: > > It has been brought to my attention that in Section 6.6 of RFC 3920, the > protocol snippet in Step 11 is as follows: > > xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > from='example.com' > id='s2s_345' > version='1.0'> > > > Because this is a server-to-server example, the xmlns for that stream > header should instead be 'jabber:server'. > > /psa From rfc-ed@ISI.EDU Sun Jan 23 21:13:50 2005 Date: Sat, 22 Jan 2005 13:11:51 -0500 To: rfc-editor@rfc-editor.org From: Russ Housley Subject: RFC 3770 Errata Cc: ietf-pkix@imc.org Mime-Version: 1.0 X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Lines: 38 Content-Type: text/plain; charset="us-ascii"; format="flowed" X-UID: 0000000146 Status: RO Content-Length: 974 Lines: 38 Dear RFC Editor: Section 4 of RFC 3770 contains a significant error. There is a typographical error in the object identifier. Please publish this errata as soon as possible. OLD: The WLAN SSID attribute certificate attribute is identified by id-aca-wlanSSID. id-aca OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 } id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 } NEW: The WLAN SSID attribute certificate attribute is identified by id-aca-wlanSSID. id-aca OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 } id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 7 } This same error is repeated in the ASN.1 Module (Section 8). OLD: id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 } NEW: id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 7 } Thanks, Russ From rfc-ed@ISI.EDU Sat Feb 26 22:37:17 2005 Date: Sun, 27 Feb 2005 06:07:04 +0100 From: Frank Ellermann MIME-Version: 1.0 To: rfc-editor@rfc-editor.org Subject: RfC 2069 errata Content-Transfer-Encoding: 7bit X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Lines: 41 Content-Type: text/plain; charset="us-ascii" X-UID: 0000000152 Status: RO Content-Length: 1525 Lines: 41 RfC 2069 (digest access authentication) chapter 2.4 is an example, the userame is "Mufasa", the password is "CircleOfLife": | username="Mufasa", | realm="testrealm@host.com", | nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", | uri="/dir/index.html", | response="e966c932a9242554e42c8ee200cec7f6", | opaque="5ccc069c403ebaf9f0171e9517f40e41" The "respose" is MD5( MD5( A1 ) || ':' || nonce || ':' || MD5( A2 )) MD5( A1 ) = MD5( username || ':' || realm || ':' || password ) = MD5( "Mufasa:testrealm@host.com:CircleOfLife" ) = "4945ecf42b1bb868634058a845bedde8" MD5( A2 ) = MD5( Method || ':' || digest-uri-value ) = MD5( "GET:/dir/index.html" ) = "39aff3a2bab6126f332b942af96d3366" This results in a response = "1949323746fe6a43ef61f9606e7febea" instead of the shown value = "e966c932a9242554e42c8ee200cec7f6". Quick reality check, the RfC 2617 example uses the same values username = "Mufasa" nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093" realm = "testrealm@host.com" A2 = "GET:/dir/index.html" with a slightly different password = "Circle Of Life" resulting in MD5( A1 ) = "939e7578ed9e3c518a452acee763bce9" The "respose" is MD5( MD5( A1 ) || ':' || X || ':' || MD5( A2 )) for X = "dcd98b7102dd2f0e8b11d0f600bfb0c093:00000001:0a4f113b:auth" and here the response = "6629fae49393a05397450978507c4ef1" works as expected. I've tried to contact two of the RfC 2069 authors about this issue, but got no reply. Regards, F.Ellermann From rfc-ed@ISI.EDU Tue Mar 1 10:47:43 2005 Date: Tue, 1 Mar 2005 12:45:04 -0600 From: John Kristoff To: rfc-editor@rfc-editor.org Subject: typos in RFC 3031 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Lines: 17 Content-Type: text/plain; charset="US-ASCII" X-UID: 0000000155 Status: RO Content-Length: 451 Lines: 17 Hello, I'm reporting what I believe are typos in RFC 3031, MPLS Architecture. On page 9, in the acronyms and abbreviations section, following the 'L2' description is the 'L3' acronym and description on the same line. Apparently there is a missing CR/LF. On page 21, under 3.20 Aggregation, first paragraph, 3rd sentence there is this: "...swapping might be used only to get the the traffic to the egress node." Notice the double 'the'. John From rfc-ed@ISI.EDU Tue May 17 10:55:07 2005 From: Alfred =?hp-roman8?B?SM5uZXM=?= Subject: RFC 4073 To: housley@vigilsec.com Date: Tue, 17 May 2005 16:13:02 +0200 (MESZ) Cc: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-ISI-4-39-6-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=2.64 X-Lines: 111 Content-Type: text/plain; charset="hp-roman8" X-UID: 0000000166 Status: RO Content-Length: 3954 Lines: 111 Hello, having read the recent RFC 4073 authored by you I suspect a small but perhaps technically important flaw in the text that finally turned out to be a more general issue: In the module heading and in the IMPORTS clause of the ASN.1 module of RFC 4073 (Appendix A on page 7), the textual label for the sub-identifier 9 of the OBJECT IDENTIFIER 1.2.840.113549.1 is spelled "pkcs-9(9)". But, ALL other (#=4) appearances of this same sub-identifier in the text of RFC 4073 use the spelling "pkcs9(9)" (without the '-'). I've tried to resolve this inconsistency going "back to the roots", and unfortunately found a big mess! (see detailed list below) Basically, PKCS#9 v2.0 from RSA Labs and its ASCII-fication RFC 2985 should be considered the primary reference because this spec contains the definition of the OBJECT IDENTIFIER 1.2.840.113549.1.9 . There, the spelling consistently is "pkcs-9(9)" . This notation style is strictly followed in all PKCS publications from RSA (as far as I could verify), and in most RFCs related to PKCS/CMS/PKIX. I've found 24 RFCs of this kind. But there are two RFCs using the spelling "pkcs9(9)" (without the '-') exlusively. And finally, I found 8 RFCs - including RFC 4073 and your RFC 4049, as well - using both spellings mixed without any recognizable pattern. Here are the detailed results of my RFC scan - with shortened titles, and some content oriented grouping applied: 'pkcs-9(9)' only : ---------------- 2985 - PKCS #9 2311 - S/MIME v.2 Message Specification, 2312 - S/MIME v.2 Certificate Handling, 2633 - S/MIME v.3 Message Specification 3114 - Company Classifying Policy via S/MIME Security Label 3183 - Domain Security Services using S/MIME 3850 - S/MIME v.3.1 Certificate Handling 3855 - Transporting S/MIME Objects in X.400 2459 - PKIX Certificate and CRL Profile [ obsoleted by: 3280 ] 3280 - PKIX Certificate and CRL Profile 2511 - PKIX Certificate Request Messages 3029 - PKIX Data Validation and Certification Server Protocols 2797 - Certificate Mgmt Messages over CMS 3161 - PKIX Time-Stamp Protocol 3125 - Electronic Signature Policies 3211 - Password-based Encryption for CMS [ obsoleted by: 3369+3370 ] 3274 - Compressed Data Content for CMS 2875 - D-H Proof-of-Posession 3185 - Reuse of CMS CEKs 3217 - Triple-DES and RC2 Key Wrapping 3370 - CMS Algorithms 3537 - HMAC Key Wrapping with 3DES or AES 3560 - RSAES-OAEP Key Transport in CMS 3565 - Use of AES Encryption in CMS 'pkcs9(9)' only : --------------- 3657 - Use of Camellia Encryption in CMS 4010 - Use of SEED Encryption in CMS mixed spelling : -------------- 2630 - CMS [ obsoleted by: 3369+3370 ] 3369 - CMS [ obsoleted by: 3852 ] 3852 - CMS 2634 - Enhanced Security Services for S/MIME 3851 - S/MIME v.3.1 Message Specification 3126 - Electronic Signature Formats for lon-term signatures 4049 - BinaryTime 4073 - Multiple Content in CMS Note: I fear that there might exist similar inconsistencies for other ==== object identifiers (verification: t.b.d.) So, what should be done? It certainly would be VERY preferrable to follow identifier naming literally, always and strictly, once published in a normatively referrable way. At least, we should ensure a consistent use of already defined identifiers to be followed in future IETF publications. Additionally, it might be considered to post Errata Notes for some (or all non-obsoleted) RFCs in the 2nd and 3rd category above (i.e., RFCs 2634, 3126, 3657, 3851, 3852, 4010, 4049, 4073). Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From rfc-ed@ISI.EDU Tue May 17 13:08:56 2005 Date: Tue, 17 May 2005 16:04:31 -0400 To: Alfred =?hp-roman8?B?SM5uZXM=?= From: Russ Housley Subject: Re: RFC 4073 Cc: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-ISI-4-39-6-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Lines: 118 Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-UID: 0000000167 Status: RO Content-Length: 4325 Lines: 118 Thanks for reporting the typo. It should not be a problem in practice. "pkcs9" and "pkcs-9" will simpley be treated as synonyms for the integer value 9. Russ At 10:13 AM 5/17/2005, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >Hello, >having read the recent RFC 4073 authored by you I suspect a small >but perhaps technically important flaw in the text that finally >turned out to be a more general issue: > >In the module heading and in the IMPORTS clause of the ASN.1 module >of RFC 4073 (Appendix A on page 7), the textual label for the >sub-identifier 9 of the OBJECT IDENTIFIER 1.2.840.113549.1 is >spelled "pkcs-9(9)". >But, ALL other (#=4) appearances of this same sub-identifier in the >text of RFC 4073 use the spelling "pkcs9(9)" (without the '-'). > >I've tried to resolve this inconsistency going "back to the roots", >and unfortunately found a big mess! (see detailed list below) > >Basically, PKCS#9 v2.0 from RSA Labs and its ASCII-fication RFC 2985 >should be considered the primary reference because this spec contains >the definition of the OBJECT IDENTIFIER 1.2.840.113549.1.9 . >There, the spelling consistently is "pkcs-9(9)" . > >This notation style is strictly followed in all PKCS publications >from RSA (as far as I could verify), and in most RFCs related to >PKCS/CMS/PKIX. I've found 24 RFCs of this kind. > >But there are two RFCs using the spelling "pkcs9(9)" (without the '-') >exlusively. > >And finally, I found 8 RFCs - including RFC 4073 and your RFC 4049, >as well - using both spellings mixed without any recognizable pattern. > >Here are the detailed results of my RFC scan - with shortened titles, >and some content oriented grouping applied: > >'pkcs-9(9)' only : >---------------- > 2985 - PKCS #9 > > 2311 - S/MIME v.2 Message Specification, > 2312 - S/MIME v.2 Certificate Handling, > 2633 - S/MIME v.3 Message Specification > 3114 - Company Classifying Policy via S/MIME Security Label > 3183 - Domain Security Services using S/MIME > 3850 - S/MIME v.3.1 Certificate Handling > 3855 - Transporting S/MIME Objects in X.400 > > 2459 - PKIX Certificate and CRL Profile [ obsoleted by: 3280 ] > 3280 - PKIX Certificate and CRL Profile > > 2511 - PKIX Certificate Request Messages > 3029 - PKIX Data Validation and Certification Server Protocols > > 2797 - Certificate Mgmt Messages over CMS > 3161 - PKIX Time-Stamp Protocol > > 3125 - Electronic Signature Policies > > 3211 - Password-based Encryption for CMS [ obsoleted by: 3369+3370 ] > 3274 - Compressed Data Content for CMS > > 2875 - D-H Proof-of-Posession > 3185 - Reuse of CMS CEKs > 3217 - Triple-DES and RC2 Key Wrapping > 3370 - CMS Algorithms > 3537 - HMAC Key Wrapping with 3DES or AES > 3560 - RSAES-OAEP Key Transport in CMS > 3565 - Use of AES Encryption in CMS > >'pkcs9(9)' only : >--------------- > 3657 - Use of Camellia Encryption in CMS > 4010 - Use of SEED Encryption in CMS > >mixed spelling : >-------------- > 2630 - CMS [ obsoleted by: 3369+3370 ] > 3369 - CMS [ obsoleted by: 3852 ] > 3852 - CMS > > 2634 - Enhanced Security Services for S/MIME > 3851 - S/MIME v.3.1 Message Specification > > 3126 - Electronic Signature Formats for lon-term signatures > > 4049 - BinaryTime > > 4073 - Multiple Content in CMS > >Note: I fear that there might exist similar inconsistencies for other >==== object identifiers (verification: t.b.d.) > > >So, what should be done? >It certainly would be VERY preferrable to follow identifier naming >literally, always and strictly, once published in a normatively >referrable way. >At least, we should ensure a consistent use of already defined >identifiers to be followed in future IETF publications. >Additionally, it might be considered to post Errata Notes for some >(or all non-obsoleted) RFCs in the 2nd and 3rd category above >(i.e., RFCs 2634, 3126, 3657, 3851, 3852, 4010, 4049, 4073). > >Best regards, > Alfred HÎnes. > >-- > >+------------------------+--------------------------------------------+ >| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | >| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | >| D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | >+------------------------+--------------------------------------------+ From rfc-ed@ISI.EDU Tue May 31 07:05:25 2005 From: "Unai Pildain (ML/EEM)" To: "'rfc-editor@rfc-editor.org'" Subject: RFC 2867 Date: Tue, 31 May 2005 15:59:50 +0200 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-ISI-4-39-6-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Lines: 8 Content-Type: text/plain; charset="iso-8859-1" X-UID: 0000000169 Status: RO Content-Length: 251 Lines: 8 Hi, Attributes that should be included in Tunnel-Stop and Tunnel-Link-Stop include attribute Acct-Multi-Session-Id with code 51. Acct-Multi-Session-Id has an associated code of 50 in RFC 2866. Is it therefore an error in RFC 2867 ? Regards, Unai. From mikek@muonics.com Sun Feb 13 03:13:07 2005 X-Unix-From: mikek@muonics.com Sun Feb 13 03:13:07 2005 Return-Path: Received: from slepton.muonics.com (adsl-64-168-64-114.dsl.snfc21.pacbell.net [64.168.64.114]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j1DBCxQ23697 for ; Sun, 13 Feb 2005 03:12:59 -0800 (PST) Received-SPF: Received-SPF: pass (slepton.muonics.com: domain of mikek@muonics.com designates 64.168.64.114 as permitted sender) receiver=slepton.muonics.com; client_ip=64.168.64.114; envelope-from=mikek@muonics.com; Received: from slepton.muonics.com (slepton.muonics.com [64.168.64.114]) by slepton.muonics.com (8.13.2/8.13.2) with ESMTP id j1DB1PcT083745 for ; Sun, 13 Feb 2005 03:01:26 -0800 (PST) Date: Sun, 13 Feb 2005 03:01:20 -0800 (PST) From: Michael Kirkham To: rfc-editor@rfc-editor.org Subject: NMRG-SMING-SNMP-MAPPING (RFC 3781) errata (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: mikek@muonics.com X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.64 X-UID: 0000000181 Status: RO Content-Length: 1376 Lines: 46 ---------- Forwarded message ---------- Date: Sun, 13 Feb 2005 03:00:49 -0800 (PST) From: Michael Kirkham To: ietfmibs@ops.ietf.org Subject: NMRG-SMING-SNMP-MAPPING (RFC 3781) errata While not technically a MIB module and possibly of no interest to anyone given the SMIng working group (and I'm pretty sure the mailing list) shut down, unless it restarts some day, this is probably the most appropriate place to mention this too, short of the snmpv3 list. (I'll forward this and the other two MPLS MIB errata emails to the RFC editor as well.) There are ASN.1 syntax errors on all but one of the type definitions defined in NMRG-SMING-SNMP-MAPPING (missing "::=" operator): --- rfc3781.txt Thu May 13 16:15:38 2004 +++ rfc3781-fixed.txt Sun Feb 13 02:58:06 2005 @@ -477,19 +477,19 @@ [APPLICATION 10] IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) - Unsigned64 + Unsigned64 ::= [APPLICATION 11] IMPLICIT INTEGER (0..18446744073709551615) - Float32 + Float32 ::= [APPLICATION 12] IMPLICIT OCTET STRING (SIZE (4)) - Float64 + Float64 ::= [APPLICATION 13] IMPLICIT OCTET STRING (SIZE (8)) - Float128 + Float128 ::= [APPLICATION 14] IMPLICIT OCTET STRING (SIZE (16)) -- Michael Kirkham www.muonics.com From ah@tr-sys.de Tue Feb 22 01:55:37 2005 X-Unix-From: ah@tr-sys.de Tue Feb 22 01:55:37 2005 Return-Path: Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j1M9srE27847 for ; Tue, 22 Feb 2005 01:54:59 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA064486002; Tue, 22 Feb 2005 10:53:22 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA28845; Tue, 22 Feb 2005 10:53:14 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200502220953.KAA28845@TR-Sys.de> Subject: RFC 3970 To: kireeti@juniper.net Date: Tue, 22 Feb 2005 10:53:13 +0100 (MEZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: a.hoenes@tr-sys.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-UID: 0000000183 Status: RO Content-Length: 1649 Lines: 44 Hello, reading the recently published RFC 3970 authored by you I found some unfortunate textual issues on page 16: The DESCRIPTION clauses of - teTunnelOctects and teTunnelLPOctects - teTunnelPackets and teTunnelLPPackets are pairwise identical, respectively. There is no precise description of the precise meaning of these "teTunnelLPxxx" objects. Admittedly, one might guess from the SYNTAX clauses of these objects that "LP" stands for 'lower part' -- meaning that the value of a "teTunnelLPOctets" object should always equal the value of the corresponding "teTunnelOctets" object MODULO 2^32 (and similarly for the "...Packets" objects), but this is not stated in the text. Furthermore, unfortunately the naming of these objects does not conform to the conventional naming style used in (almost) all IETF standards track MIB modules with High Capacity counters, e. g. "xxxOctets" and "xxxHCOctets" . The above interpretation would be more manifest if this standard naming convention would have been followed. Now, given that the naming of the objects cannot be changed any more, it would certainly be useful to have a textual clarification of these DESCRIPTIONs posted on the RFC Editor's RFC-Errata web page. Please comment. Best Regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From ah@tr-sys.de Sun Mar 6 17:03:00 2005 X-Unix-From: ah@tr-sys.de Sun Mar 6 17:03:00 2005 Return-Path: Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2712K610263 for ; Sun, 6 Mar 2005 17:02:26 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA144197246; Mon, 7 Mar 2005 02:00:46 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA22442; Mon, 7 Mar 2005 01:30:58 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200503070030.BAA22442@TR-Sys.de> Subject: Re: RFC 4009 (again) To: sjlee@kisa.or.kr Date: Mon, 7 Mar 2005 01:30:57 +0100 (MEZ) Cc: khopri@kisa.or.kr, jykim@kisa.or.kr, jilee@kisa.or.kr, rfc-editor@rfc-editor.org In-Reply-To: from Sungjae Lee at Mar "4," 2005 "05:07:24" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: a.hoenes@tr-sys.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000186 Status: RO Content-Length: 19873 Lines: 496 Hello again, and thanks for your quick response. Meanwhile, I've tried to figure out in detail what's wrong with the formulas for SSi by applying my version and your version to a few examples (calculated by hand). In the course of this effort, again going through the text, I have detected additional issues with the RFC text. [ I continue the enumeration from my first mail. ] (C) First, a formal issue with the ASN.1 given in the RFC text: In the ASN.1 definitions in section 2.5., it would perhaps be more natural and consistent with the requirements from the text (and the ASN.1 comment already present there!) to give an explicit SIZE restriction in the definition of the syntax of the initialization vector for SEED in CBC mode (which indeed *MUST* be 16 octets long). To this end, I recommend to replace the 7th text line of section 2.5., "seedCDCParameter ::= OCTET STRING -- 128-bit Initialization Vector" by: | "seedCDCParameter ::= OCTET STRING (SIZE(16)) | -- 128-bit Initialization Vector" (D) The text in section 2.2. talks about two basic 8x8 S-boxes, named "S1" and "S2". Contrary to that, Appendix A.1. (on page 7) gives tables for "S-Box S0" and "S-Box S1". It would be easier to change the headlines in Appendix A.1., but, given the numbering style of all other formula elements, it is certainly be more appropriate and consistent to modify the equations in section 2.2., replacing "S1" by "S0", and "S2" by "S1". I'll give a full replacement text for section 2.2. below, covering this issue as well. [ Now, returning to the open issue ... ] (B) In short, sorry, I do NOT agree with your definition of the SS-boxes. It does not conform with the primary definition of the function G. Below, I'll give you a detailed step-by-step explanation, using a concrete example, for the reasoning already presented in my first mail. Note: For brevity and due to the email line length restriction, in the subsequent reasoning, I will omit the braces '{ ... }' around the ANDed terms, making use of the usual precedence rule for multiplication over addition and the facts that - the '^' operation is the normal addition in the 8 / 32 dimensional vector spaces over GF(2) we are working on, - '&' representing the 8 / 32 fold tensor product of the scalar multiplication over GF(2) . I repeat and extend the numeration of the formulas from my first email, already applying item (D). X = X0 || X1 || X2 || X3 (2) ... the 32 bit wide input to the function G; Z = Z0 || Z1 || Z2 || Z3 (1) ... the 32 bit wide output of the function G applied to X; with the 8-bit wide components computed by the application of the two S-Boxes S0 and S1 via the equations: Z0 = S0(X0) & m0 ^ S1(X1) & m1 ^ S0(X2) & m2 ^ S1(X3) & m3 (1.0) Z1 = S0(X0) & m1 ^ S1(X1) & m2 ^ S0(X2) & m3 ^ S1(X3) & m0 (1.1) Z2 = S0(X0) & m2 ^ S1(X1) & m3 ^ S0(X2) & m0 ^ S1(X3) & m1 (1.2) Z3 = S0(X0) & m3 ^ S1(X1) & m0 ^ S0(X2) & m1 ^ S1(X3) & m2 (1.3) with m0 = 0xFC , m1 = 0xF3 , m2 = 0xCF , and m3 = 0x3F (1.4) The alternate description of the Function G is to be Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3) where, below, I'll try "my" version of the SS-Box definition ... SS0(x) = S0(x) & m0 || S0(x) & m1 || S0(x) & m2 || S0(x) & m3 (4.0) SS1(x) = S1(x) & m1 || S1(x) & m2 || S1(x) & m3 || S1(x) & m0 (4.1) SS2(x) = S0(x) & m2 || S0(x) & m3 || S0(x) & m0 || S0(x) & m1 (4.2) SS3(x) = S1(x) & m3 || S1(x) & m0 || S1(x) & m1 || S1(x) & m2 (4.3) ... and the version from the text (with the formal changes already discussed properly applied) ... SS0(x) = S0(x) & m3 || S0(x) & m2 || S0(x) & m1 || S0(x) & m0 (5.0) SS1(x) = S1(x) & m0 || S1(x) & m3 || S1(x) & m2 || S1(x) & m1 (5.1) SS2(x) = S0(x) & m1 || S0(x) & m0 || S0(x) & m3 || S0(x) & m2 (5.2) SS3(x) = S1(x) & m2 || S1(x) & m1 || S1(x) & m0 || S1(x) & m3 (5.3) With these notations, let's challenge the example octet sequence X0 = 0x09 , X1 = 0x11 , X2 = 0xE1 , X3 = 0xF9 (6a) i.e., by (2) : X = (0x) 09 11 E1 F9 (6b) Applying the tables from Appendix A.1., we obtain (*) : S0(X0) = 0x43 , S1(X1) = 0x62 , S0(X2) = 0xB9 , S1(X3) = 0x4C . To first compute Z with the original definition of G, substituting (*) and (1.4) into (1.0) .. (1.3), we obtain, step by step: Z0 = S0(X0) & m0 ^ S1(X1) & m1 ^ S0(X2) & m2 ^ S1(X3) & m3 (1.0) = 0x43 & 0xFC ^ 0x62 & 0xF3 ^ 0xB9 & 0xCF ^ 0x4C & 0x3F = 0x40 ^ 0x62 ^ 0x89 ^ 0x0C ==> Z0 = 0xA7 (7.0) Z1 = S0(X0) & m1 ^ S1(X1) & m2 ^ S0(X2) & m3 ^ S1(X3) & m0 (1.1) = 0x43 & 0xF3 ^ 0x62 & 0xCF ^ 0xB9 & 0x3F ^ 0x4C & 0xFC = 0x43 ^ 0x42 ^ 0x39 ^ 0x4C ==> Z1 = 0x74 (7.1) Z2 = S0(X0) & m2 ^ S1(X1) & m3 ^ S0(X2) & m0 ^ S1(X3) & m1 (1.2) = 0x43 & 0xCF ^ 0x62 & 0x3F ^ 0xB9 & 0xFC ^ 0x4C & 0xF3 = 0x43 ^ 0x22 ^ 0xB8 ^ 0x40 ==> Z2 = 0x99 (7.2) Z3 = S0(X0) & m3 ^ S1(X1) & m0 ^ S0(X2) & m1 ^ S1(X3) & m2 (1.3) = 0x43 & 0x3F ^ 0x62 & 0xFC ^ 0xB9 & 0xF3 ^ 0x4C & 0xCF = 0x03 ^ 0x60 ^ 0xB1 ^ 0x4C ==> Z3 = 0x9E (7.3) Putting (7.0) .. (7.3) together using (1), we get the byte sequence Z = Z0 || Z1 || Z2 || Z3 (1) ==> Z = (0x) A7 74 99 9E (7) Now let's see what happens when we apply "my" definition of the SS-Boxes, substituting (6a), (*), and (1.4) into (4.0) .. (4.3) : SS0(X0) = S0(X0) & m0 || S0(X0) & m1 || S0(X0) & m2 || S0(X0) & m3 = 0x43 & 0xFC || 0x43 & 0xF3 || 0x43 & 0xCF || 0x43 & 0x3F = 0x40 || 0x43 || 0x43 || 0x03 ==> SS0(X0) = (0x) 40 43 43 03 (8.0) SS1(X1) = S1(X1) & m1 || S1(X1) & m2 || S1(X1) & m3 || S1(X1) & m0 = 0x62 & 0xF3 || 0x62 & 0xCF || 0x62 & 0x3F || 0x62 & 0xFC = 0x62 || 0x42 || 0x22 || 0x60 ==> SS1(X1) = (0x) 62 42 22 60 (8.1) SS2(X2) = S0(X2) & m2 || S0(X2) & m3 || S0(X2) & m0 || S0(X2) & m1 = 0xB9 & 0xCF || 0xB9 & 0x3F || 0xB9 & 0xFC || 0xB9 & 0xF3 = 0x89 || 0x39 || 0xB8 || 0xB1 ==> SS2(X2) = (0x) 89 39 B8 B1 (8.2) SS3(X3) = S1(X3) & m3 || S1(X3) & m0 || S1(X3) & m1 || S1(X3) & m2 = 0x4C & 0x3F || 0x4C & 0xFC || 0x4C & 0xF3 || 0x4C & 0xCF = 0x0C || 0x4C || 0x40 || 0x4C ==> SS3(X3) = (0x) 0C 4C 40 4C (8.3) Note: Please observe that the terms in (8.0) .. (8.3) are indeed the same terms as in (7.0) .. (7.3), but in 4x4 matrix transposed order -- as stated abstractly in my first email. Summing up (8.0) .. (8.3) according to (3), we get what should be the alternate definition of G(X) : Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3) = (0x) 40 43 43 03 ^ -- from (8.0) (0x) 62 42 22 60 ^ -- from (8.1) (0x) 89 39 B8 B1 ^ -- from (8.2) (0x) 0C 4C 40 4C -- from (8.3) ==> ----------- Z = (0x) A7 74 99 9E (8) Obviously, (8) indeed is identical to (7). Finally, let's look for what we get with your definition of the SS-Boxes, substituting (6a), (*), and (1.4) into (5.0) .. (5.3) : SS0(X0) = S0(X0) & m3 || S0(X0) & m2 || S0(X0) & m1 || S0(X0) & m0 = 0x43 & 0x3F || 0x43 & 0xCF || 0x43 & 0xF3 || 0x43 & 0xFC = 0x03 || 0x43 || 0x43 || 0x40 ==> SS0(X0) = (0x) 03 43 43 40 (9.0) SS1(X1) = S1(X1) & m0 || S1(X1) & m3 || S1(X1) & m2 || S1(X1) & m1 = 0x62 & 0xFC || 0x62 & 0x3F || 0x62 & 0xCF || 0x62 & 0xF3 = 0x60 || 0x22 || 0x42 || 0x62 ==> SS1(X1) = (0x) 60 22 42 62 (9.1) SS2(X2) = S0(X2) & m1 || S0(X2) & m0 || S0(X2) & m3 || S0(X2) & m2 = 0xB9 & 0xF3 || 0xB9 & 0xFC || 0xB9 & 0x3F || 0xB9 & 0xCF = 0xB1 || 0xB8 || 0x39 || 0x89 ==> SS2(X2) = (0x) B1 B8 39 89 (9.2) SS3(X3) = S1(X3) & m2 || S1(X3) & m1 || S1(X3) & m0 || S1(X3) & m3 = 0x4C & 0xCF || 0x4C & 0xF3 || 0x4C & 0xFC || 0x4C & 0x3F = 0x4C || 0x40 || 0x4C || 0x0C ==> SS3(X3) = (0x) 4C 40 4C 0C (8.3) Summing up (9.0) .. (9.3) according to (3), we get Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3) = (0x) 03 43 43 40 ^ -- from (9.0) (0x) 60 22 42 62 ^ -- from (9.1) (0x) B1 B8 39 89 ^ -- from (9.2) (0x) 4C 40 4C 0C -- from (9.3) ==> ----------- Z = (0x) 9E 99 74 A7 (9) This is NOT the same as (7). In fact, it is the byte-reversed sequence from (7) . -- Bingo! Taking a closer look at (5.0) .. (5.3), I now see that indeed the terms in these equations are in the reverse concatenation sequence compared to (4.0) .. (4.3) ! After a detailed inspection of the tables given in Appendix A.2. of RFC 4009, it now becomes clear that -- disregarding the IETF conventions to represent all binary data in network byte order, and without any further notice of this fact -- these tables do NOT represent octect sequences (as expected from the presentation of above formula using octet concatenation, not arithmetic left-shift or multiply-by-256 operations), BUT the hexadecimal representation of the proper 4-octet sequences improperly cast into 32 bit numbers on a 'little endian' processor, i.e., without using the ntohl() intrinsic! I suspect that your definition of the SS-boxes (5.0) .. (5.3) has been inadvertently retrofitted to match the values given in the tables in Appendix A.2., again re-formulating the printed byte order (which is NOT the storage byte order [= octet concatenation order] in a little endian processor) using the octet concatenation notation / formalism. Because definition of the function G according to section 2.2. does not make use of 32-bit integer arithmetic operations, I recommend to clarify the situation by o giving formula (4.0) .. (4.3) for the SS-Boxes, consistent with the other formulas, and o stating explicitely in Appendix A.2. that these tables give byte reversed presentations of the octet sequences to be used as the output of the SS-boxes. To catch up, here's my proposed replacement text for the whole section 2.2. of RFC 4009, covering the issues (A), (B), and (D) mentioned so far: ---------------- cut here ------------------------------- 2.2. The Function G The function G has two layers: a layer of two 8x8 S-boxes, S0 and S1, and a layer of block permutation of sixteen 8-bit sub-blocks. The output octet sequence Z (= Z0 || Z1 || Z2 || Z3) of the function G with the four-octet input X (= X0 || X1 || X2 || X3) is as follows: Z0 = {S0(X0) & m0} ^ {S1(X1) & m1} ^ {S0(X2) & m2} ^ {S1(X3) & m3} Z1 = {S0(X0) & m1} ^ {S1(X1) & m2} ^ {S0(X2) & m3} ^ {S1(X3) & m0} Z2 = {S0(X0) & m2} ^ {S1(X1) & m3} ^ {S0(X2) & m0} ^ {S1(X3) & m1} Z3 = {S0(X0) & m3} ^ {S1(X1) & m0} ^ {S0(X2) & m1} ^ {S1(X3) & m2} where m0 = 0xFC , m1 = 0xF3 , m2 = 0xCF , and m3 = 0x3F . To increase the efficiency of the calculation of the function G, four extended S-boxes with 4-octet output ('SS-boxes', see Appendix A.2.) are defined as follows: SS0(x) = {S0(x) & m0} || {S0(x) & m1} || {S0(x) & m2} || {S0(x) & m3} SS1(x) = {S1(x) & m1} || {S1(x) & m2} || {S1(x) & m3} || {S1(x) & m0} SS2(x) = {S0(x) & m2} || {S0(x) & m3} || {S0(x) & m0} || {S0(x) & m1} SS3(x) = {S1(x) & m3} || {S1(x) & m0} || {S1(x) & m1} || {S1(x) & m2} Hereby, the function G can be defined as follows: Z = G(X) = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) . This alternate definition of the function G is faster than the original definition but it takes 16 times the memory to store the four SS-boxes compared to the two original S-boxes. ---------------- cut here ------------------------------- Immediately below the headline of Appendix A.2., on page 8, I propose to insert the following text (or similar): "The following tables specify the byte-reversed SS-box values, i.e., the first octet to be returned from the function G (named Z0 in section 2.2.), is obtained by XORing together the rightmost bytes from the appropriate entries looked up in the following four tables, etc." (E) The above discussion, and the observed deviation from the IETF standard ('network') byte ordering convention, immediately raises additional byte ordering concerns for - the definition of the round function F in section 2.1., and - the Key Schedule definition given in section 2.3. The function G -- as defined in section 2.2. -- operates on a four- octet sequence and returns a four-octet sequence, according to the formulae labelled (1) and (2) above. The definition of the round function F and the key schedule make use of several multi-byte INTEGER arithmetic operations, in particular 32-bit (mod 2^32) addition and subtraction, on input and output values of the function G, and the key schedule uses circular shift operations on concatenated (64 bit) intermediate key blocks. With regard to the observations made above, I now suspect that some of the implicit 'cast' operations (between octet sequences and multi- byte integers) involved in the round functions and the key schedule might also be formulated in a little-endian centric way, omitting the necessary application of the htonl() and ntohl() intrinsics when producing the test cases in Appendix B. (I did not have the time to verify that.) For the sake of interoperability, it SHOULD be clarified whether the formulae given for R0' and R1' in section 2.1., and for Ki0 and Ki1 in section 2.3., as well as the constant's values tabulated in the latter section, are specified according to IEFT standard byte ordering rules, or with implicit little-endian byte order in mind. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ On Fri, 4 Mar 2005 17:07:24 +0900, "Sungjae Lee" wrote: > > Hello, > > We, authors, agree with you. > > But SS-box are defined as follows: > > SS0(X0) = {S1(X0) & m3} || {S1(X0) & m2} || {S1(X0) & m1} || {S1(X0) & m0} > SS1(X1) = {S2(X1) & m0} || {S2(X1) & m3} || {S2(X1) & m2} || {S2(X1) & m1} > SS2(X2) = {S1(X2) & m1} || {S1(X2) & m0} || {S1(X2) & m3} || {S1(X2) & m2} > SS3(X3) = {S2(X3) & m2} || {S2(X3) & m1} || {S2(X3) & m0} || {S2(X3) & m3} > > If you agree with my arguments, we will immediately submit an errata note > for these issues to the RFC Editor for publication on the RFC Errata web > page. > > Thank you for your concernings and contributions. > > Best Regards, > > -----Original Message----- > From: Alfred HÎnes [mailto:ah@tr-sys.de] > Sent: Monday, February 28, 2005 6:09 PM > To: khopri@kisa.or.kr; sjlee@kisa.or.kr; jykim@kisa.or.kr; jilee@kisa.or.kr > Cc: rfc-editor@rfc-editor.org > Subject: RFC 4009 > > > Hello, > > I just picked up and read the new RFC 4009 authored by you, to find > significant concerns with section 2.2. (on pages 3 and 4 of the RFC): > > > (A) > > Unfortunately, within a few lines in the RFC text, the variable name 'X' > gets used for two very distinct purposes and contexts: > > o X = X0 || X1 || X2 || X3 (2) > ... the 32 bit wide input to the function G > > o X used as formal argument in the defining equations for > the 'SS-boxes' SS0 ... SS3 > ... a single octet (8 bit wide entity), > [application of the formulas - see (3) below - will > substitute X0, ..., X3 in turn for the arguments] > > Perhaps, it would have been better to use another symbol, e.g. 'x', for the > latter purpose. > > > (B) > > As far as I can see, feeding the definition of the SS-boxes given in the > last 4 text/formule lines on page 3 into the formula on top of page 4, > > Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3) > > does ***NOT*** yield the same result as using the primary defining formulas > given for Z0 ... Z3 in the first formula block of section 2.2., together > with > > Z = Z0 || Z1 || Z2 || Z3 (1). > > I suspect a mis-ordering in the use of m0 ... m3 in the equations defining > SS0 ... SS3 : > > With regard to the formulas (1), (2), and (3) (as numbered above), the > 'matrix' pattern of the 4x4 terms in braces { ... } , obtained from the > formula block defining SS0 ... SS3 by substitution of Xi for the argument of > SSi (i=0,1,2,3) - as required in (3) -, should be the matrix transpose of > the pattern of the same terms in braces appearing in the formula block > defining Z0 ... Z3 , e. g. the first 'column' of {...} terms for SSi() > should contain the {...} terms appearing in the formula for Z0. > But this is not the case. > > Therefore, I suspect that the last 6 text/formula lines on page 3 of RFC > 4009 should in fact read (including the enhancement from (A) > above): > > " > To increase the efficiency of the G function, four extended S-boxes > 'SS-box' (See Appendix A.2) are defined as follows: > > SS0(x)= {S1(x) & m0} || {S1(x) & m1} || {S1(x) & m2} || {S1(x) & m3} > SS1(x)= {S2(x) & m1} || {S2(x) & m2} || {S2(x) & m3} || {S2(x) & m0} > SS2(x)= {S1(x) & m2} || {S1(x) & m3} || {S1(x) & m0} || {S1(x) & m1} > SS3(x)= {S2(x) & m3} || {S2(x) & m0} || {S2(x) & m1} || {S2(x) & m2} > " > > > Please check and comment. > > > If you agree with my arguments, we should immediately submit an errata note > for these issues to the RFC Editor for publication on the RFC Errata web > page. > > In this case, I also recommend to include a textual enhancement for the > first sentence of section 2.3., replacing: > > "The key schedule generates each round subkeys." > by: > "The key schedule generates subkeys for each round." > > And finally, for completeness, it would have been useful as well to give > additional Informational Reference(s) for the seedMAC (and the > [seed]CBC) algorithm(s)/construct(s) mentioned in section 2.5. - e.g. RFC > 3610 (and RFC 2451 / NIST SP 800-38A) [?]. > > > Best Regards, > Alfred HÎnes. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | > +------------------------+--------------------------------------------+ From casner@acm.org Thu Mar 10 19:38:37 2005 X-Unix-From: casner@acm.org Thu Mar 10 19:38:37 2005 Return-Path: Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2B3cW622064 for ; Thu, 10 Mar 2005 19:38:32 -0800 (PST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id j2B3bH6c086940; Thu, 10 Mar 2005 19:37:18 -0800 (PST) (envelope-from casner@acm.org) Date: Thu, 10 Mar 2005 19:38:26 -0800 (PST) From: Stephen Casner Sender: casner@packetdesign.com To: rfc-editor@rfc-editor.org cc: Katsushi Kobayashi , Carsten Bormann Subject: Erratum in RFC 3189 Message-ID: <20050310193128.B3415@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: casner@acm.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000187 Status: RO Content-Length: 1010 Lines: 33 There are two errors in the SDP examples shown in RFC 3189: 1. In an fmtp paramter, there should not be a space after the colon. 2. The examples show the use of two fmtp parameters for a single payload type. This was not necessary since they can be combined. In draft-ietf-mmusic-sdp-new-24.txt, section 6, the rules of RFC 2327 are clarified to say that only one fmtp parameter is allowed per payload type. Therefore, the examples should be reformatted to use a single line. There are two places in the RFC where these errors appear. In Section 3.1, the RFC says: a=fmtp:113 encode=SD-VCR/525-60 a=fmtp:113 audio=none It should say: a=fmtp:113 encode=SD-VCR/525-60 audio=none In Section 3.2, the RFC says: a=fmtp: 112 encode=SD-VCR/525-60 a=fmtp: 112 audio=bundled a=fmtp: 113 encode=306M/525-60 a=fmtp: 113 audio=bundled It should say: a=fmtp:112 encode=SD-VCR/525-60 audio=bundled a=fmtp:113 encode=306M/525-60 audio=bundled From mrc@CAC.Washington.EDU Fri Apr 15 17:55:08 2005 X-Unix-From: mrc@CAC.Washington.EDU Fri Apr 15 17:55:08 2005 Return-Path: Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3G0re613869 for ; Fri, 15 Apr 2005 17:53:40 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.4+UW05.03/8.13.3+UW05.01) with ESMTP id j3G0re9E025548 for ; Fri, 15 Apr 2005 17:53:40 -0700 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) (authenticated bits=0) by smtp.washington.edu (8.13.4+UW05.03/8.13.3+UW05.01) with ESMTP id j3G0rd0e023445 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 15 Apr 2005 17:53:39 -0700 Date: Fri, 15 Apr 2005 17:53:39 -0700 (PDT) From: Mark Crispin To: rfc-editor@rfc-editor.org Subject: updated errata for RFC 3501 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: mrc@cac.washington.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-UID: 0000000189 Status: RO Content-Length: 9986 Lines: 243 Section 2.3.1.1, page 8: old: A 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever. Unique identifiers [...] new: An unsigned 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever. Unique identifiers [...] ----- Section 2.3.1.1, page 9: old: Associated with every mailbox are two values which aid in unique identifier handling: the next unique identifier value and the unique identifier validity value. new: Associated with every mailbox are two 32-bit unsigned values which aid in unique identifier handling: the next unique identifier value (UIDNEXT) and the unique identifier validity value (UIDVALIDITY). ----- Section 5.1.3, page 19: old: All other characters (octet values 0x00-0x1f and 0x7f-0xff) are represented in modified BASE64, with a further modification from [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be used to represent any printing US-ASCII character which can represent itself. new: All other characters (octet values 0x00-0x1f and 0x7f-0xff) are represented in modified BASE64, with a further modification from [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be used to represent any printing US-ASCII character which can represent itself. Only characters inside the modified BASE64 alphabet are permitted in modified BASE64 text. ----- Section 5.5, page 22: old: Note: UID FETCH, UID STORE, and UID SEARCH are different commands from FETCH, STORE, and SEARCH. If the client sends a UID command, it must wait for a completion result response before sending a command with message sequence numbers. new: Note: EXPUNGE responses are permitted while UID FETCH, UID STORE, and UID SEARCH are in progress. If the client sends a UID command, it must wait for a completion result response before sending a command which uses message sequence numbers (this may include UID SEARCH). Any message sequence numbers in an argument to UID SEARCH are associated with messages prior to the effect of any untagged EXPUNGE returned by the UID SEARCH. ----- Section 6.2.1, page 27: old: Once [TLS] has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in- the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS. new: Once [TLS] has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in- the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities, and in particular SHOULD NOT advertise the STARTTLS capability, after a successful STARTTLS command. ----- Section 6.2.2, page 28: old: The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the authentication mechanism. A server challenge consists of a command continuation request response with the "+" token followed by a BASE64 encoded string. The client response consists of a single line consisting of a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it issues a line consisting of a single "*". If the server receives such a response, it MUST reject the AUTHENTICATE command by sending a tagged BAD response. new: The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the authentication mechanism. A server challenge consists of a command continuation request response with the "+" token followed by a BASE64 encoded string. The client response consists of a single line consisting of a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it issues a line consisting of a single "*". If the server receives such a response, or if it receives an invalid BASE64 string (e.g. characters outside the BASE64 alphabet, or non-terminal "="), it MUST reject the AUTHENTICATE command by sending a tagged BAD response. Section 6.3.4, page 36: old: It is permitted to delete a name that has inferior hierarchical names and does not have the \Noselect mailbox name attribute. In this case, all messages in that mailbox are removed, and the name will acquire the \Noselect mailbox name attribute. new: It is permitted to delete a name that has inferior hierarchical names and does not have the \Noselect mailbox name attribute. If the server implementation does not permit deleting the name while inferior hierarchical names exists the \Noselect mailbox name attribute is set for that name. In any case, all messages in that mailbox are removed by the DELETE command. ----- Section 6.3.10, page 44: old: Responses: untagged responses: STATUS new: Responses: REQUIRED untagged response: STATUS ----- Section 6.4.3, page 49: old: The EXPUNGE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox. Before returning an OK to the client, an untagged EXPUNGE response is sent for each message that is removed. new: The EXPUNGE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox. Before returning an OK to the client, an untagged EXPUNGE response is sent for each message that is removed. Note that if any messages with the \Recent flag set are expunged, an untagged RECENT response is sent after the untagged EXPUNGE(s) to update the client's count of RECENT messages. ----- Section 6.4.4, page 50: old: [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing text in a [CHARSET] other than US-ASCII. US-ASCII MUST be supported; other [CHARSET]s MAY be supported. new: [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing text. US-ASCII MUST be supported; other [CHARSET]s MAY be supported. ----- Section 6.4.4, page 50: old: In all search keys that use strings, a message matches the key if the string is a substring of the field. The matching is case-insensitive. new: In all search keys that use strings, a message matches the key if the string is a substring of the associated text. The matching is case-insensitive. Note that the empty string is a substring; this is useful when doing a HEADER search. ----- Section 6.4.4, page 54: old: C: A284 SEARCH CHARSET UTF-8 TEXT {6} C: XXXXXX S: * SEARCH 43 S: A284 OK SEARCH completed new: C: A284 SEARCH CHARSET UTF-8 TEXT {6} S: + Ready for literal text C: XXXXXX S: * SEARCH 43 S: A284 OK SEARCH completed ----- Section 7.2.2, page 70: old: If it is not feasible for the server to determine whether or not the mailbox is "interesting", or if the name is a \Noselect name, the server SHOULD NOT send either \Marked or \Unmarked. new: If it is not feasible for the server to determine whether or not the mailbox is "interesting", the server SHOULD NOT send either \Marked or \Unmarked. The server MUST NOT send more than one of \Marked, \Unmarked, and \Noselect for a single mailbox, and MAY send none of these. ----- Formal Syntax, Page 84: old: CHAR8 = %x01-ff ; any OCTET except NUL, %x00 new: CHAR8 = %x01-ff ; any OCTET except NUL, %x00 charset = atom / quoted ----- Formal Syntax, Page 89: old: resp-text-code = "ALERT" / "BADCHARSET" [SP "(" astring *(SP astring) ")" ] / new: resp-text-code = "ALERT" / "BADCHARSET" [SP "(" charset *(SP charset) ")" ] / ----- Formal Syntax, Page 89: old: search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key) new: search = "SEARCH" [SP "CHARSET" SP charset] 1*(SP search-key) ----- Formal Syntax, Page 90: old: status-att-list = status-att SP number *(SP status-att SP number) new: status-att-val = ("MESSAGES" SP number) / ("RECENT" SP number) / ("UIDNEXT" SP nz-number) / ("UIDVALIDITY" SP nz-number) / ("UNSEEN" SP number) status-att-list = status-att-val *(SP status-att-val) ----- Normative References, Page 95: old: [LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. new: [LANGUAGE-TAGS] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. Appendix B, Page 103: new: 115) Add support for Content-Location to BODYSTRUCTURE. From brc@zurich.ibm.com Thu Jul 28 00:22:51 2005 X-Unix-From: brc@zurich.ibm.com Thu Jul 28 00:22:51 2005 Return-Path: Received: from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.29.152]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j6S7Lxf29797 for ; Thu, 28 Jul 2005 00:22:00 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j6S7Lrmp121752 for ; Thu, 28 Jul 2005 07:21:53 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6S7Lr1m189016 for ; Thu, 28 Jul 2005 09:21:53 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j6S7Lqf3010411 for ; Thu, 28 Jul 2005 09:21:53 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j6S7Lqs2010392; Thu, 28 Jul 2005 09:21:52 +0200 Received: from zurich.ibm.com (sig-9-146-216-63.de.ibm.com [9.146.216.63]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA50226; Thu, 28 Jul 2005 09:21:50 +0200 Message-ID: <42E8878E.9010902@zurich.ibm.com> Date: Thu, 28 Jul 2005 09:21:50 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: rfc-editor@rfc-editor.org CC: Margaret Wasserman , Bob Hinden , Brian Haberman Subject: Erratum in RFC 4048 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: brc@zurich.ibm.com X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_01 autolearn=ham version=2.64 X-UID: 0000000202 Status: RO Content-Length: 154 Lines: 4 Section 4, IANA Considerations, of RFC 4048 omitted to request IANA to release IPv6 option type code 11-0-00011 = 195 decimal, C3 hexadecimal. Brian From ah@tr-sys.de Mon Jun 20 01:13:53 2005 X-Unix-From: ah@tr-sys.de Mon Jun 20 01:13:53 2005 Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id j5K8CQ104539; Mon, 20 Jun 2005 01:12:26 -0700 (PDT) Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j5K8BaL04194 for ; Mon, 20 Jun 2005 01:11:43 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA252674971; Mon, 20 Jun 2005 10:09:31 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA05785; Mon, 20 Jun 2005 10:09:22 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200506200809.KAA05785@TR-Sys.de> Subject: RFC 4113 errata To: fenner@research.att.com, john.flick@hp.com Date: Mon, 20 Jun 2005 10:09:21 +0200 (MESZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-39-6-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=ham version=2.64 X-UID: 0000000242 Status: RO Content-Length: 1897 Lines: 52 Hello, in the new RFC 4113 edited by you I found two texual issues in DESCRIPTION clauses of the MIB module that both look like the result of re-use of text from other places with the due changes applied incompletely to the copied text. (1) The DESCRIPTION clause of 'udpEndpointRemoteAddressType', at the bottom of page 10, "The address type of udpEndpointRemoteAddress. Only IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or unknown(0) if datagrams for all remote IP addresses are accepted. ..." ^^^ (borrowed from 'udpEndpointLocalAddressType' DESCRIPTION) probably should read: "The address type of udpEndpointRemoteAddress. Only IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or unknown(0) if datagrams from all remote IP addresses are accepted. ..." ^^^^ (2) The DESCRIPTION clause of 'udpEndpointRemotePort', on page 11 says (borrowed from 'udpEndpointRemoteAddress' DESCRIPTION): "The remote port number for this UDP endpoint. If datagrams from any remote system are to be accepted, this value is zero." ^^^^^^ It should say: "The remote port number for this UDP endpoint. If datagrams from any remote port are to be accepted, this value is zero." ^^^^ If you agree, I propose to submit an RFC Errata Note to the RFC Editor. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From ah@tr-sys.de Sun Sep 11 09:49:51 2005 X-Unix-From: ah@tr-sys.de Sun Sep 11 09:49:51 2005 Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id j8BGme211609; Sun, 11 Sep 2005 09:48:40 -0700 (PDT) Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8BGm1k11542 for ; Sun, 11 Sep 2005 09:48:07 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA194556737; Sun, 11 Sep 2005 18:38:57 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA23141; Sun, 11 Sep 2005 18:35:11 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200509111635.SAA23141@TR-Sys.de> Subject: Fate of the SICI URN namespace (RFC 2288)? To: cliff@cni.org, cecilia@well.com, rdaniel@acl.lanl.gov Date: Sun, 11 Sep 2005 18:35:10 +0200 (MESZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=ham version=2.64 X-UID: 0000000270 Status: RO Content-Length: 2051 Lines: 52 Hello, Once you have written RFC 2288 that defined three URN namespaces: ISSN, ISBN, and SICI. The IANA "urn-namespaces" registry does not (and probably never did) contain any pointers to RFC 2288. Meanwhile, the 'ISSN' URN namespace definition has been restated in RFC 3044, including an IANA registration -- according to and using the template specified in RFC 2611 (BCP 33) [that in the meantime has been obsoleted itself by RFC 3406 (BCP 66)] --, and 'ISSN' currently appears as formal URN namespace #3 in the IANA URN namespaces registry. Similarly, the 'ISBN' URN namespace definition has been restated in RFC 3187, including an IANA registration -- according to and using the template specified in RFC 2611 --, and 'ISBN' currently appears as formal URN namespace #9 in the IANA registry. Now, RFC 2288 is *NOT* declared "Obsoleted" in the RFC index. Contrary to that, the 'SICI' URN namespace does *NOT* appear in the current IANA URN namespaces registry. Thus the fate of the 'SICI' namespace and the status of RFC 2288 is questionable and unclear. I suspect that RFC 2288 should be considered obsoleted, and 'SICI' should be considered deprecated. So, what's to do in this case ? According to my understanding of the established procedures, the Informational RFC 2288 cannot easily be re-classified as Historic, and a specific footnote about the deprecated 'SICI' namespace would not be easily entered into the IANA registry. Therefore, to make the situation clearly understandable for everyone, it seems easiest to have the RFC-Ed add the note '(Obsoleted by 3044, RFC 3187)' to the RFC index entry for RFC 2288. Please comment. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From ah@tr-sys.de Wed Sep 14 01:27:31 2005 X-Unix-From: ah@tr-sys.de Wed Sep 14 01:27:31 2005 Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id j8E8PoR26922; Wed, 14 Sep 2005 01:25:50 -0700 (PDT) Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8E8P6k26682 for ; Wed, 14 Sep 2005 01:25:12 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA224806258; Wed, 14 Sep 2005 10:24:18 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA26728; Wed, 14 Sep 2005 10:24:07 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200509140824.KAA26728@TR-Sys.de> Subject: RFC 4140 (HMIPv6) To: h.soliman@flarion.com, claude.castelluccia@inria.fr, karim@elmalki.homeip.net, ludovic.bellier@inria.fr Date: Wed, 14 Sep 2005 10:24:07 +0200 (MESZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=ham version=2.64 X-UID: 0000000275 Status: RO Content-Length: 2033 Lines: 53 Hello, after reading the recently published RFC 4140 (HMIPv6) authored by you, I'd like to submit some comments. These might be useful for you in proparation of any future update (promotion onto the Standards Track) of HMIPv6 and/or consideration for an RFC Errata note -- at your will. 1.) There are a couple of issues with the citiations given in Appendix A, on pp. 24-27 : 1.1) I suspect that the repeated occourrences of "[5]" should in fact be "[4]" (the Fast Handover RFC 4068). 1.2) The final phrase at the bottom of page 26 should obviously refer to RFC 4067 (CXTP) instead of a "work in progress" (add appropriate ref to section 14.2.!) 1.3) The citations "[6]" on page 27 apparently make no sense -- SEND does not update RFC 4068. I suspect a reference to some "work in progress" would have been appropriate. 2.) Minor typos and proposed textual improvements 2.1) On p.8, in line 5 (i.e. the end of section 4.1.): instead of "introduced in future" the text might perhaps better say: "introduced in the future". 2.2) On p. 14, in the bottom line (at the end of section 7.1.), the final "." is missing. 2.3) On p. 16, in the 2nd-to-last paragraph of section 7.2., The phrase "RCoA is then bound to ..." should perhaps better say: "The RCoA is then bound to ...". 2.4) On page 19, in the final line of section 9.2., the word "movement" is mis-spelled "u0movement". 2.5) On page 20, in the enumerated list at the end of section 12., I propose to remove the "The" in all 3 items, aligning with the titles of the subsequent sections 12.1. - 12.3. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From singer@apple.com Wed Sep 14 08:17:43 2005 X-Unix-From: singer@apple.com Wed Sep 14 08:17:43 2005 Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id j8EFFpO10742; Wed, 14 Sep 2005 08:15:51 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8EFEqk10446 for ; Wed, 14 Sep 2005 08:14:52 -0700 (PDT) Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j8EFEjTA002788 for ; Wed, 14 Sep 2005 08:14:45 -0700 (PDT) Received: from [192.168.248.10] (vpn2p031.euro.apple.com [17.66.41.157]) by relay6.apple.com (Apple SCV relay) with ESMTP id 253EC51D for ; Wed, 14 Sep 2005 08:14:43 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Wed, 14 Sep 2005 17:12:45 +0200 To: rfc-editor@rfc-editor.org From: Dave Singer Subject: typo in rfc 2396 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.64 X-UID: 0000000276 Status: RO Content-Length: 201 Lines: 7 "A URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier." a possessive 'its' with an apostrophe... -- David Singer Apple Computer/QuickTime From vishal.bs@ittiam.com Sun Sep 25 23:38:29 2005 X-Unix-From: vishal.bs@ittiam.com Sun Sep 25 23:38:29 2005 Return-Path: Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id j8Q6ajw23856; Sun, 25 Sep 2005 23:36:45 -0700 (PDT) Received: from is01mg02.ittiam.com (mx2.ittiam.com [203.201.200.250]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8Q6ZpY23781 for ; Sun, 25 Sep 2005 23:35:52 -0700 (PDT) Received: from IS01EX02.ittiam.com ([172.20.32.17]) by is01mg02.ittiam.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 12:05:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Errata for RFC 2250 Date: Mon, 26 Sep 2005 12:04:38 +0530 Message-ID: <904DEC693BE1AB429622C6F5ABA7E0B807FDF6@is01ex02.ittiam.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Errata for RFC 2250 thread-index: AcXCZG2U9IjtmesSRGGCnLn9ZZyvaw== From: "Vishal B S" To: X-OriginalArrivalTime: 26 Sep 2005 06:35:52.0234 (UTC) FILETIME=[8A46C8A0:01C5C264] X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j8Q6ZpY23781 X-MailScanner-From: rfc-ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.64 X-UID: 0000000279 Status: RO Content-Length: 531 Lines: 19 Hi, In section 3.3 of RFC-2250 Payload Type: Distinct payload types should be assigned for video elementary streams and audio elementary streams. See [4] for payload type assignments. M bit: For video, set to 1 on packet containing MPEG frame end code, 0 otherwise. For audio, set to 1 on first packet of a "talk-spurt," 0 otherwise. PT: MPEG video or audio stream ID. Payload Type and PT mean the same in RTP header So, there exists a repetition. regards Vishal From ah@tr-sys.de Thu Sep 22 03:00:33 2005 X-Unix-From: ah@tr-sys.de Thu Sep 22 03:00:33 2005 X-UIDL: J_?"!_*N"!%"5"!`YD!! Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id j8M9wpM24706; Thu, 22 Sep 2005 02:58:51 -0700 (PDT) Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8M9w7n24438 for ; Thu, 22 Sep 2005 02:58:13 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA287073050; Thu, 22 Sep 2005 11:57:30 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA10725; Thu, 22 Sep 2005 11:52:55 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200509220952.LAA10725@TR-Sys.de> Subject: RFC 4133 erratum To: ietf@andybierman.com, kzm@cisco.com, rfc-editor@rfc-editor.org Date: Thu, 22 Sep 2005 11:52:54 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=ham version=2.64 X-UID: 0000000015 Status: RO Content-Length: 2252 Lines: 67 Hello, in the recently published RFC 4133, a reference to another new RFC, (RFC 4152), unfortunately has been left in a boilerplate like form 'RFCYYYY' at 4 places within the text. I suggest to emit an errata note for RFC 4133 including the appropriate corrections: (1) In the bottom half of page 10, the RFC text says: For example, the entPhysicalUris object may be used to encode a URI containing a Common Language Equipment Identifier (CLEI) URN for the managed physical entity. The URN name space for CLEIs is defined in [RFCYYYY], and the CLEI format is defined in [T1.213][T1.213a]. For example, an entPhysicalUris instance may have the value of URN:CLEI:D4CE18B7AA [RFC3986] and [RFCYYYY] identify this as a URI in the CLEI URN name space. The specific CLEI code, D4CE18B7AA, is based on the example provided in [T1.213a]. It should say: For example, the entPhysicalUris object may be used to encode a URI containing a Common Language Equipment Identifier (CLEI) URN for the managed physical entity. The URN name space for CLEIs is defined in [RFC4152], and the CLEI format is defined in [T1.213][T1.213a]. For example, an entPhysicalUris instance may have the value of URN:CLEI:D4CE18B7AA [RFC3986] and [RFC4152] identify this as a URI in the CLEI URN name space. The specific CLEI code, D4CE18B7AA, is based on the example provided in [T1.213a]. (2) In the 3rd-to-last item of section 8.2., on page 60, the text says: [RFCYYYY] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the CLEI Code", RFC YYYY, August 2005. It shold say: [RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the CLEI Code", RFC 4152, August 2005. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From heard@pobox.com Tue Nov 1 21:16:28 2005 X-Unix-From: heard@pobox.com Tue Nov 1 21:16:28 2005 X-UIDL: 7GY"!e\*"!oR="!)T]!! Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id jA25DtU16332; Tue, 1 Nov 2005 21:13:55 -0800 (PST) Received: from smtpout1.bayarea.net (smtpout1.bayarea.net [209.128.95.10]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA25CwM16191 for ; Tue, 1 Nov 2005 21:12:58 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id jA25CwCO025600; Tue, 1 Nov 2005 21:12:58 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id jA25CoYx024153; Tue, 1 Nov 2005 21:12:50 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id jA25CnH6024150; Tue, 1 Nov 2005 21:12:50 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 1 Nov 2005 21:12:49 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: RFC Editor cc: "Wijnen, Bert (Bert)" , David Kessens Subject: Re: Erratum for RFC 4181 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by boreas.isi.edu id jA25CwM16191 X-MailScanner-From: rfc-ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=ham version=2.64 X-UID: 0000000003 Status: RO Content-Length: 1504 Lines: 51 On Sun, 23 Oct 2005, C. M. Heard wrote: > On Sun, 16 Oct 2005, Alfred HÎnes wrote: > > I've [...] observed two minor typos in the text of RFC 4181 > > that migth be worth noting for consideration in the case of > > any future update to this RFC: > > > > * The bottom text line of page 29 says: > > > > " ... . Two point are worth reiterating:" > > ^^ > > It should say: > > > > " ... . Two points are worth reiterating:" > > > > * The first line of item 8 in Appendix A, on page 34, says: > > > > "... -- if the draft does not contains a verbatim copy ..." > > ^ > > It should say: > > > > "... -- if the draft does not contain a verbatim copy ..." > > RFC Editor: > > As document editor, I would like to request than an RFC Erratum be > created for RFC 4181 listing these errors. Thanks to Alfred HÎnes > for pointing them out. In addition to the above, I have noticed the following formatting error in the first bullet in Section 4.6.1.1 on p. 14. The text in the RFC looks like this: - For integer-valued enumerations: - INTEGER is REQUIRED; - Integer32, Unsigned32, and Gauge32 MUST NOT be used. and it should look like this: - For integer-valued enumerations: - INTEGER is REQUIRED; - Integer32, Unsigned32, and Gauge32 MUST NOT be used. I would appreciate it if you would include this item when you create the erratum for RFC 4181. Regards, Mike Heard From ah@tr-sys.de Tue Nov 8 09:16:04 2005 X-Unix-From: ah@tr-sys.de Tue Nov 8 09:16:04 2005 X-UIDL: BhR"!R@F!!B)j!!ga8!! Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id jA8H7G102957; Tue, 8 Nov 2005 09:07:16 -0800 (PST) Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA8H5OM01922 for ; Tue, 8 Nov 2005 09:05:30 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA112599477; Tue, 8 Nov 2005 18:04:37 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA14529; Tue, 8 Nov 2005 18:04:28 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200511081704.SAA14529@TR-Sys.de> Subject: RFC 4211 (CRMF) errata To: jimsch@exmsft.com Date: Tue, 8 Nov 2005 18:04:27 +0100 (MEZ) Cc: rfc-editor@rfc-editor.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=ham version=2.64 X-UID: 0000000005 Status: RO Content-Length: 11594 Lines: 348 Hello, after studying the recently published RFC 4211 authored by you I'd like to report a couple of textual issues I found there -- some of these are even legacy issues inherited from RFC 2511. Most issues covered below are simple typos the corrections of which are (nearly) obvious, but a few issues require your expertise to be corrected properly. Therefore, I would like to obtain your comments and consent before submitting a formal errata note to the RFC Editor. All items below are listed in the order of their appearance within the RFC text. To ease the recognition of the issues, I try to point to the offending text with up/down arrows in the form of '^^^' / 'vvv' tags contained in lines added to the text excerpts. (1) Section 4.1., Signature Key POP, in the upper half of page 8, in the explanation of the POPOSigningKey fields, says: vvv algorithmIdentifier identifiers the signature algorithm and an associated parameters used to produce the POP value. signature contains the POP value produce. ... ^^ It should say: algorithmIdentifier identifiers the signature algorithm and associated parameters used to produce the POP value. signature contains the POP value produced. ... (2) Section 4.2., Key Encipherment Keys, in the lower part of page 10, in the two (doubly indented) paragraphs explaining the components of 'agreeMAC', uses improper names for these components -- cf. the ASN.1 syntax for PKMACValue at the top of page 9. The RFC says: vvvvvv macAlg contains the algorithm identifying the method used to compute the MAC value. macValue contains the computed MAC value. ^^^^^^^^ It should say (I propose to make use of hierarchical subfield notation): agreeMAC.algID contains the algorithm identifying the method used to compute the MAC value. agreeMAC.value contains the computed MAC value. (3) Section 4.2.1, Private Key Info Content Type, in the last paragraph on page 11 says: identifier contains a name that the CA/RA can associate with the requestor. This will generally be either the DN of a certificate or a text token passed and known to both the requestor and the CA/RA. ... It should perhaps better say: identifier contains a name that the CA/RA can associate with the requestor. This will generally be either the DN of a certificate subject or a text token passed and known to both the requestor ^^^^^^^^ and the CA/RA. ... [Rationale: The (prospective) certificate does not have a DN, but its subject ...] (4) Section 4.4, Use of Password-Based MAC, the ASN.1 fragment at the bottom of page 14, says: PBMParameter ::= SEQUENCE { salt OCTET STRING, owf AlgorithmIdentifier, iterationCount INTEGER, mac AlgorithmIdentifier ) ^^^ It should say: PBMParameter ::= SEQUENCE { salt OCTET STRING, owf AlgorithmIdentifier, iterationCount INTEGER, mac AlgorithmIdentifier } (5) Section 4.4, Use of Password-Based MAC, in the first text line on page 15, says: The fields of PEMParameter have the following meaning: ^ It should say: v The fields of PBMParameter have the following meaning: [Rationale: an OCR problem???] (6) Section 6.1, Registration Token Control, in the first paragraph on page 19, refers to a wrong subsection; it says: The regToken control is used only for initialization of an end entity into the PKI, whereas the authenticator control (see section 7.2) can ^ be used for the initial as well as subsequent certification requests. It should say: The regToken control is used only for initialization of an end entity into the PKI, whereas the authenticator control (see section 6.2) can be used for the initial as well as subsequent certification requests. (7) Section 6.3, Publication Information Control, in the upper half of page 20, says: The fields of PKIPublicationInfo have the following meaning: action indicates whether or not the requestor wishes the CA/RA to publish the certificate. The values and their means are: ^^ It should say: The fields of PKIPublicationInfo have the following meaning: action indicates whether or not the requestor wishes the CA/RA to publish the certificate. The values and their meanings are: (8) Section 6.3, Publication Information Control, at the bottom of page 20, says: The fields of SinglePubInfo have the following meaning: pubMethod indicates the address type for the location at which the requestor desires the certificate to be placed by the CA/RA. dontCare indicates that the CA/RA can publish the certificate in whatever locations it chooses. If dontCare is used, the pubInfos field MUST be omitted. ^^^^^ (To make the full context visible, I have shown more text than would be necessary for the errata note.) >From the context, I strongly suspect that the RFC text should say: The fields of SinglePubInfo have the following meaning: pubMethod indicates the address type for the location at which the requestor desires the certificate to be placed by the CA/RA. dontCare indicates that the CA/RA can publish the certificate in whatever locations it chooses. If dontCare is used, the pubLocation field MUST be omitted. ^^^^^^^^ [Rationale: pubInfos is a "SEQUENCE SIZE (1..MAX) OF SinglePubInfo". I cannot imagine how a certain value of a SinglePubInfo instance subfield can ever imply a MUST to omit the full enclosing structure, pubInfos -- which would have removed this subfield as well :-) . Perhaps, the text has been cloned from the explanation of the 'dontPublish' value of the PKIPublicationInfo.action filed given just below the text excerpt reproduced under item (7) above without fully applying the proper changes.] (9) Section 6.4, Archive Options Control, at the bottom of page 22, says: The fields of EncryptedKey have the following meaning: encryptedValue is longer used. This field has been deprecated along with the EncryptedValue structure. It should say: The fields of EncryptedKey have the following meaning: vvvv encryptedValue is no longer used. This field has been deprecated along with the EncryptedValue structure. (10) The first paragraph of section 7.1, utf8Pairs, near the bottom of page 23, says: This control is used to convey text-based information from the Subject to an RA to a CA issuing a certificate. The OID for this structure is id-regInfo-utf8Paris and has a type of UTF8String. It should perhaps say: This control is used to convey text-based information from the Subject to an RA or to a CA issuing a certificate. The OID for ^^^^ vvvv this structure is id-regInfo-utf8Paris and it has a type of UTF8String. (11) Subsequently, near the top of page 24, the same section says: vvvvvvvvv The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%' (%25) if they are not being used for their reserved purpose. Names MUST NOT start with a numeric character. It should better say: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv The %xx mechanism of Section 2.1 of STD 66 [RFC3986] is used to encode '?' (%3f) and '%' (%25) if they are not being used for their reserved purpose. Names MUST NOT start with a numeric character. [Rationale: RFC 1738 has been obsoleted; the %-escaping method is now covered by the above mentioned section of that Internet Standard.] Accordingly, the Reference [RFC1738] needs to be updated -- see item (13) below. (12) Section 9, Security Considerations, in the first paragraph on page 26, contains the sentence: ... The user can claim that an item was signed by the entity that generated the key as well as any entity that might have seen the key value during transfer from the generator the to EE. ... ^^^^^^ It should say: ... The user can claim that an item was signed by the entity that generated the key as well as any entity that might have seen the key value during transfer from the generator to the EE. ... ^^^^^^ (13) Section 10.2, Informative References, on page 27, contains the following Ref. as its final entry: [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. According to item (11) above, this should be removed, and a new Ref. [RFC3986] added -- to be taken from rfc-ref.txt . Given the nature and context of the use of this Ref. in section 7.1 -- see item (11) above -- and the STD Status of RFC 3986, then perhaps it is advisable to place this new Ref. into Section 10.1, Normative References, not in section 10.2, Informative References. (14) Appendix A.2, in the last ASN.1 fragment on page 31, says: IP address (identifier "I"): ::= ^^^^^ I'm in serious doubt whether this is correct: I am not aware of a standard method to express an IP address (i.e. an IPv4 address or an IPv6 address) as an OID. If it *does* exist, indeed, a proper citation would be *very* helpful; otherwise (as I expect) the ASN.1 should be corrected. Perhaps, another would be appropriate, with details left to [RFC3986]. (15) Appendix B, near the middle of page 32, contains the following [commented out] ASN.1, and ASN.1 comment: -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING -- The contents of this type correspond to RFC 2279. ^^^^ RFC 2279 has been obsoleted by RFC 3629 == STD 63 "long" ago. I am aware of the fact that the UTF-8 definition in RFC 3629 syntactically and semantically by intention is a proper subset of the definition in RFC 2279 (restriction to possible Unicode codepoints with up to 24-bit representation). Thus, it might be true that the reference to RFC 2279 has been used intentionally in this ASN.1 comment, e.g., because RFC 3280 [PROFILE] (pre-3629!) referred to RFC 2279 in that context. But, regarding the STD status of RFC 3629, a standards track RFC like RFC 4211 should, in this case, present explicit arguments for the deviation from STD 63. (It doesn't.) Otherwise, the RFC should say: -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING -- The contents of this type correspond to RFC 3629. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From ah@tr-sys.de Tue Nov 22 06:25:02 2005 X-Unix-From: ah@tr-sys.de Tue Nov 22 06:25:02 2005 X-UIDL: _#-!!el3!!XXO"!O~J"! X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham version=3.1.0 Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id jAMEMLg26550; Tue, 22 Nov 2005 06:22:21 -0800 (PST) Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAMEKuE26193 for ; Tue, 22 Nov 2005 06:21:03 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA236559201; Tue, 22 Nov 2005 15:20:01 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA10991; Tue, 22 Nov 2005 14:50:18 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200511221350.OAA10991@TR-Sys.de> Subject: RFC 4141 errata To: toyoda.kiyoshi@jp.panasonic.com, dcrocker@bbiw.net, rfc-editor@rfc-editor.org Date: Tue, 22 Nov 2005 14:50:18 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-UID: 0000000008 Status: RO Content-Length: 7157 Lines: 223 Hello, I'd like to report a couple of flaws I found reading the recently published RFC 4141, "SMTP and MIME Extensions for Content Conversion", authored by you. I propose to post an errata note for this RFC according to the subsequently listed items (presented in text order). [Casually, I place change bars ('|') in column 1 to emphasize the location of the proposed correction.] (1) In Section 1.2, the last paragraph at the bottom of page 4 says: * three MIME Content header fields (Content-Convert, Content- Previous and * Content-Features) that specify appropriate content header fields and record conversions that have been performed. It should say: * three MIME Content header fields (Content-Convert, Content- | Previous and Content-Features) that specify appropriate content header fields and record conversions that have been performed. (2) In Section 3, the fourth paragraph on page 6 says: When CONPERM is used, conversions are performed by the first ESMTP host that can obtain both the originator's permission and information about the capabilities supported by the recipient. If a relay or client is unable to transmit the message to a next-hop that supports CONPERM or to perform appropriate conversion, then it terminates message transmission and returns a [DSNSMTP, DSNFMT, SYSCOD] to the originator, with status code 5.6.3 (Conversion required but not supported). It should say: When CONPERM is used, conversions are performed by the first ESMTP host that can obtain both the originator's permission and information about the capabilities supported by the recipient. If a relay or client is unable to transmit the message to a next-hop that supports CONPERM or to perform appropriate conversion, then it terminates | message transmission and returns a Delivery Status Notification (DSN) [DSNSMTP, DSNFMT, SYSCOD] to the originator, with status code 5.6.3 (Conversion required but not supported). Rationale: Probably, that triple of RFCs should not be sent :-) The proposed text change conforms to the current authoring style guides for I-Ds / RFCs, spelling out the abbreviation 'MDN' at its first occurrance in the text. (3) Similarly, the final NOTE in Section 3, on page 9, says: NOTE: An originator MAY validate any conversions that are made by requesting a positive [DSNSMTP]. ... where it should better say: NOTE: An originator MAY validate any conversions that are made | by requesting a positive DSN [DSNSMTP]. ... (4) The second item of the first enumerated list in Section 3.3, on page 12, contains a (visually hidden) word replication. The text says: 2) MUST return a DSN notification to the originator, with status code 5.6.3 (Conversion required but not supported). [DSNSMTP, DSNFMT, SYSCOD] It should say: | 2) MUST return a DSN to the originator, with status code 5.6.3 (Conversion required but not supported). [DSNSMTP, DSNFMT, SYSCOD] Rationale: The trailing "N" of "DSN" already stands for "notification". (5) To make the spelling of [E]SMTP keywords and verbs consistent within the text, the headline of Section 4.2 (on page 13), 4.2. CONPERM Parameter to Mail-From should better use uppercaes spelling as well, to read: 4.2. CONPERM Parameter to MAIL-FROM (6) The ABNF given in Section 7, on page 16, and Section 8, on page 17, does not fully conform to the contemporary (RFC 2822) style. The ABNF in Section 7 omits the explicit specification of white space usage that presumably has been intended. The ABNF in Section 8 inserts a paramount of CFWS. NOTE: - RFC 2822 has deprecated the use of white space between header field names and the subsequent ":" and, as far as I can see, comments have not been allowed at such places by RFC 822, and aren't by the "obsolete syntax" in RFC 2822. - RFC 2822 has carefully made [C]FWS an intrinsic part of many low-level syntactic constructs to improve readability of the high-level ABNF productions. Thus, CFWS should not be inserted again where it is (logically) already present. Furthermore, the spelling of ABNF production names should be self-consistent within a certain field. RFC 2822 makes use of lowercase production (rule) names for teh syntactic description of the Internet Message Format; therefore it seems preferrable to follow this style when defining IMF extensions. In the light of these explanations (and detailed inspection of RFC 2822), the ABNF productions in Section 7 : Convert = "Content-convert" ":" permitted Permitted = "ANY" / "NONE" / permitted-list should perhaps be re-written as : convert = "Content-convert:" [CFWS] permitted permitted = "ANY" / "NONE" / permitted-list and the ABNF productions in Section 8 : previous = "Content-Previous" [CFWS] ":" [CFWS] date by type date = "Date " [CFWS] date-time [CFWS] ";" [CFWS] by = "By " [CFWS] domain [CFWS] ";" [CFWS] should perhaps be re-written as : previous = "Content-Previous:" date by type date = "Date " [CFWS] date-time ";" [CFWS] by = "By " domain ";" [CFWS] or even (disallowing comments after "Date " - like RFC 2822 does): previous = "Content-Previous:" date by type date = "Date " date-time ";" [CFWS] by = "By " domain ";" [CFWS] (7) The examples in Section 9 contain improperly truncated references to MIME Content-Types. The following line that appears - in Section 9.1 in the 3rd text line on page 18, and - in Section 9.2 in the 10th text line : C: <#("! X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.0 Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id jB29VFY15196; Fri, 2 Dec 2005 01:31:15 -0800 (PST) Received: from av11-1-sn2.hy.skanova.net (av11-1-sn2.hy.skanova.net [81.228.8.183]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB29Uhr15168 for ; Fri, 2 Dec 2005 01:30:43 -0800 (PST) Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 041BE381EE; Fri, 2 Dec 2005 10:30:34 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id DE2D737F15; Fri, 2 Dec 2005 10:30:34 +0100 (CET) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id D065537E7E; Fri, 2 Dec 2005 10:30:31 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.54) id 1Ei7FP-0008N7-6a; Fri, 02 Dec 2005 10:30:31 +0100 Message-ID: <43901436.5060804@levkowetz.com> Date: Fri, 02 Dec 2005 10:30:30 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: RFC Editor Cc: Paul Hoffman , Bruce Schneier Subject: RFC 4270 Errata X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-UID: 0000000010 Status: RO Content-Length: 1283 Lines: 39 Hi, I just started reading the recently announced RFC 4270, and bounced a bit when reading section 1, paragraph 3. There are changes in this paragraph, when compared to draft-hoffman-hash-attacks-04, which to my mind are quite unfortunate: The RFC says: Hash algorithms are used by cryptographers in a variety of security protocols, for a variety of purposes, at all levels of the Internet protocol stack. They are used because they have two security properties: to be one way and collision free. Note the " one way and collision free." On the face of it, as plain English, this is nonsense. In cryptographic terminology, I believe the correct expression is " one-way and collision-free." The draft says: Hash algorithms are used by cryptographers in a variety of security protocols, for a variety of purposes, at all levels of the Internet protocol stack. They are used because they have two security properties: to be one-way and collision-free. I'd like an errata to be posted, correcting this back to the text in the draft. One of these errors re-occurs in paragraph 7 of section 2, and also should be corrected: RFC: Attacks against the "one way" property: Should be: Attacks against the "one-way" property: Regards, Henrik From alexey.melnikov@isode.com Sat Dec 31 02:34:22 2005 X-Unix-From: alexey.melnikov@isode.com Sat Dec 31 02:34:22 2005 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.1.0 Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id jBVAX8n11139; Sat, 31 Dec 2005 02:33:08 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBVAW5i10814 for ; Sat, 31 Dec 2005 02:32:06 -0800 (PST) Received: from [127.0.0.1] (natchern.atom.ru [194.67.244.30]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 31 Dec 2005 10:31:56 +0000 Message-ID: <43B65DD2.7060300@isode.com> Date: Sat, 31 Dec 2005 13:30:42 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rfc-editor@rfc-editor.org CC: Arnaud Taddei , Dave Cridland Subject: Errata for RFC 4314 (IMAP4 Access Control List (ACL) Extension) Content-Type: multipart/alternative; boundary="------------030202090409060206080201" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-UID: 0000000013 Status: RO Content-Length: 5095 Lines: 123 --------------030202090409060206080201 Content-type: text/plain; charset="us-ascii" <>Hi, <>The following errors were spotted by Arnaud Taddei : <> <>1). Section 2.1.1 (page 6) states: <> The client has specified the "d" right in the SETACL command above and it expands to "et" on the server: C: A002 getacl INBOX/Drafts S: * ACL INBOX Fred rwipslxcetda David lrswideta S: A002 OK Getacl complete It should say: The client has specified the "d" right in the SETACL command above and it expands to "et" on the server: C: A002 getacl INBOX/Drafts S: * ACL INBOX/Drafts Fred rwipslxcetda David lrswideta S: A002 OK Getacl complete i.e. the second line of the example contained an error. 2). Section 2.1.1 (page 6) states: Example: C: A003 Setacl INBOX/Drafts Byron lrswikda S: A001 OK Setacl complete C: A002 getAcl INBOX/Drafts S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta S: A002 OK Getacl complete It should say: Example: C: A003 Setacl INBOX/Drafts Byron lrswikda S: A003 OK Setacl complete C: A004 getAcl INBOX/Drafts S: * ACL INBOX/Drafts Fred rwipslxcetda Byron lrswikcdeta S: A004 OK Getacl complete 3). Section 3.5 states: The MYRIGHTS command returns the set of rights that the user has to mailbox in an untagged MYRIGHTS reply. It should say: The MYRIGHTS command returns the set of rights that the user has to the mailbox in an untagged MYRIGHTS reply. Thank you and Happy New Year! Alexey --------------030202090409060206080201 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit <>Hi,
<>The following errors were spotted by Arnaud Taddei <Arnaud.Taddei@Sun.COM>:
<>
<>1). Section 2.1.1 (page 6) states:
<>
   The client has specified the "d" right in the SETACL command above
   and it expands to "et" on the server:

               C: A002 getacl INBOX/Drafts
               S: * ACL INBOX Fred rwipslxcetda David lrswideta
               S: A002 OK Getacl complete

It should say:
   The client has specified the "d" right in the SETACL command above
   and it expands to "et" on the server:

               C: A002 getacl INBOX/Drafts
               S: * ACL INBOX/Drafts Fred rwipslxcetda David lrswideta
               S: A002 OK Getacl complete

i.e. the second line of the example contained an error.

2). Section 2.1.1 (page 6) states:

   Example:    C: A003 Setacl INBOX/Drafts Byron lrswikda
               S: A001 OK Setacl complete
               C: A002 getAcl INBOX/Drafts
               S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
               S: A002 OK Getacl complete

It should say:

   Example:    C: A003 Setacl INBOX/Drafts Byron lrswikda
               S: A003 OK Setacl complete
               C: A004 getAcl INBOX/Drafts
               S: * ACL INBOX/Drafts Fred rwipslxcetda Byron lrswikcdeta
               S: A004 OK Getacl complete

3). Section 3.5 states:

   The MYRIGHTS command returns the set of rights that the user has to
   mailbox in an untagged MYRIGHTS reply.

It should say:

   The MYRIGHTS command returns the set of rights that the user has to
   the mailbox in an untagged MYRIGHTS reply.

Thank you and Happy New Year!
Alexey

--------------030202090409060206080201-- From ah@tr-sys.de Thu Sep 22 03:00:33 2005 X-Unix-From: ah@tr-sys.de Thu Sep 22 03:00:33 2005 X-UIDL: J_?"!_*N"!%"5"!`YD!! Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id j8M9wpM24706; Thu, 22 Sep 2005 02:58:51 -0700 (PDT) Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8M9w7n24438 for ; Thu, 22 Sep 2005 02:58:13 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA287073050; Thu, 22 Sep 2005 11:57:30 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA10725; Thu, 22 Sep 2005 11:52:55 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200509220952.LAA10725@TR-Sys.de> Subject: RFC 4133 erratum To: ietf@andybierman.com, kzm@cisco.com, rfc-editor@rfc-editor.org Date: Thu, 22 Sep 2005 11:52:54 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=ham version=2.64 X-UID: 0000000021 Status: RO Content-Length: 2252 Lines: 67 Hello, in the recently published RFC 4133, a reference to another new RFC, (RFC 4152), unfortunately has been left in a boilerplate like form 'RFCYYYY' at 4 places within the text. I suggest to emit an errata note for RFC 4133 including the appropriate corrections: (1) In the bottom half of page 10, the RFC text says: For example, the entPhysicalUris object may be used to encode a URI containing a Common Language Equipment Identifier (CLEI) URN for the managed physical entity. The URN name space for CLEIs is defined in [RFCYYYY], and the CLEI format is defined in [T1.213][T1.213a]. For example, an entPhysicalUris instance may have the value of URN:CLEI:D4CE18B7AA [RFC3986] and [RFCYYYY] identify this as a URI in the CLEI URN name space. The specific CLEI code, D4CE18B7AA, is based on the example provided in [T1.213a]. It should say: For example, the entPhysicalUris object may be used to encode a URI containing a Common Language Equipment Identifier (CLEI) URN for the managed physical entity. The URN name space for CLEIs is defined in [RFC4152], and the CLEI format is defined in [T1.213][T1.213a]. For example, an entPhysicalUris instance may have the value of URN:CLEI:D4CE18B7AA [RFC3986] and [RFC4152] identify this as a URI in the CLEI URN name space. The specific CLEI code, D4CE18B7AA, is based on the example provided in [T1.213a]. (2) In the 3rd-to-last item of section 8.2., on page 60, the text says: [RFCYYYY] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the CLEI Code", RFC YYYY, August 2005. It shold say: [RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the CLEI Code", RFC 4152, August 2005. Best regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From ah@tr-sys.de Thu Oct 13 09:44:32 2005 X-Unix-From: ah@tr-sys.de Thu Oct 13 09:44:32 2005 X-UIDL: S=W"!M5K"!\e~!!6m+!! Received: (from rfc-ed@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id j9DGgrN29138; Thu, 13 Oct 2005 09:42:53 -0700 (PDT) Received: from WOTAN.TR-Sys.de (isdn01.tr-sys.de [212.9.168.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9DGg1L28857 for ; Thu, 13 Oct 2005 09:42:07 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA178761681; Thu, 13 Oct 2005 18:41:21 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA25255; Thu, 13 Oct 2005 18:41:20 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200510131641.SAA25255@TR-Sys.de> Subject: RFC 4234 errata - final, agreed-upon version To: rfc-editor@rfc-editor.org Date: Thu, 13 Oct 2005 18:41:19 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rfc-ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.64 X-UID: 0000000026 Status: RO Content-Length: 4025 Lines: 148 Hello, after some discussion with Dave Crocker (script of the final steps below), I hereby submit the final, agreed upon, version of the suggested Errata Note for RFC 4234. -- > On 12 Oct 2005 22:13:20 +0200 (MESZ), > "Alfred HÎnes" wrote to : > >> thanks again for your second response. Enclosed you'll find the >> compiled errata message I now intend to submit to the RFC-Ed. >> >> If you agree, I will send that message to the RFC-Ed. >> (This mail is not CC'ed to the RFC-Editor - only to Paul Overell.) -- On 13 Oct 2005 08:57:43 -0700, "Dave Crocker" wrote to : > very nicely written. go ahead and post it. thanks for you diligence! > > d/ -- ------ cut here ------ (1) In Section 3.10., RFC 4234 says: The various mechanisms described above have the following precedence, from highest (binding tightest) at the top, to lowest (loosest) at the bottom: Strings, Names formation Comment Value range Repetition Grouping, Optional Concatenation Alternative It should say: The various mechanisms described above have the following precedence, from highest (binding tightest) at the top, to lowest (loosest) at the bottom: Strings, Names formation Comment Value range | Grouping, Optional | | Repetition Concatenation Alternative This re-ordering aligns the table with the prose description and the meta-grammar in section 4. (2) The following clarifications apply to the meta-grammar in section 4. a) Near the bottom of page 10, the rule: repetition = [repeat] element should say: | repetition = ( [repeat] element ) / option At the top of page 11, the rule: element = rulename / group / option / char-val / num-val / prose-val should say: | element = rulename / group / char-val / num-val / prose-val These changes have the effect to formally disallow a element in front of an