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 ESM