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