FW: IESG comments on NOTARY drafts
"Glenn Parsons" <[email protected]> Wed, 24 Jul 2002 17:51:18 -0400
| Newsgroups | gmane.ietf.vpim |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2335C.056CBB98 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2335C.056CBB98" ------_=_NextPart_001_01C2335C.056CBB98 Content-Type: text/plain; charset="iso-8859-1" FYI. The authors are revising the DSN documents based on these comments. Cheers, Glenn. > ---------- > From: [email protected] > Sent: Tuesday, July 23, 2002 9:53 PM > To: [email protected]; [email protected]; [email protected] > Cc: [email protected]; [email protected]; Parsons, Glenn > [CAR:6L81:EXCH]; [email protected]; [email protected] > Subject: IESG comments on NOTARY drafts > > <<ATT597280.txt>> > Attached below is feedback from the IESG about these drafts. Everything > but the final note is editorial in nature. > > Ned > > ------_=_NextPart_001_01C2335C.056CBB98 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2655.35"> <TITLE>FW: IESG comments on NOTARY drafts</TITLE> </HEAD> <BODY> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">FYI.</FONT> </P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The authors are = revising the DSN documents based on these comments.</FONT> </P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers,</FONT> <BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Glenn.</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">----------</FONT> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:</FONT></B> <FONT = SIZE=3D2 FACE=3D"Arial">[email protected]</FONT> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:</FONT></B> <FONT = SIZE=3D2 FACE=3D"Arial">Tuesday, July 23, 2002 9:53 PM</FONT> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">To:</FONT></B> = <FONT SIZE=3D2 FACE=3D"Arial">[email protected]; [email protected]; = [email protected]</FONT> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">Cc:</FONT></B> = <FONT SIZE=3D2 FACE=3D"Arial">[email protected]; [email protected]; = Parsons, Glenn [CAR:6L81:EXCH]; [email protected]; = [email protected]</FONT></P> <P><B><FONT SIZE=3D2 FACE=3D"Arial">Subject:</FONT></B> = <FONT SIZE=3D2 FACE=3D"Arial">IESG = comments on NOTARY drafts</FONT> </P> <P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> = <<ATT597280.txt>> </FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">Attached below is feedback from the = IESG about these drafts. Everything</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">but the final note is editorial in = nature.</FONT> </P> <P> = = = <FONT SIZE=3D2 = FACE=3D"Monaco">Ned</FONT> </P> <BR> </BODY> </HTML> ------_=_NextPart_001_01C2335C.056CBB98-- ------_=_NextPart_000_01C2335C.056CBB98 Content-Type: text/plain; name="ATT597280.txt" Content-Disposition: attachment; filename="ATT597280.txt" draft-moore-rfc1891bis-00.txt (1) Needs a table of contents (> 15 pages). (2) Split references into normative & non-normative. (3) The doc does not clearly say if it updates/obsoletes 1891. (An Obsoletes: RFC 1891 needs to be added at the beginning.) (4) MUST (etc) used w/o definition. (5) In subfield MUST NOT be "dns". A MTA-name-type subfield value of "- x-local-hostname" is suggested. The extra dash at the end of the line is wrong; it needs to go and the quote should be moved to the following line. (6) The text introducing section 10 (Appendix) is broken where RFC 1891 has backslashes. NOTE: Formatting rules for RFCs require that no line be longer than 72 characters. Therefore, in the following examples, some SMTP commands longer than 72 characters are printed on two lines, with the first line ending in " command would be sent as a single line (i.e. with no embedded CRLFs), and without the " Both of those single '"'s are '"\"' and have more text after them in RFC 1891. draft-vaudreuil-1892bis-01.txt (1) The doc does not clearly say if it updates/obsoletes 1892. (An Obsoletes: RFC 1892 needs to be added at the beginning.) (2) Split references into normative & non-normative. (I believe all of them are normative, so saying that is sufficient.) (3) The [DRPT] reference needs to be changed to refer to draft-moore-rfc1891bis-01.txt. draft-vaudreuil-1893bis-01.txt (1) The doc does not clearly say if it updates/obsoletes 1893. (An Obsoletes: RFC 1893 needs to be added at the beginning.) (2) Split references into normative & non-normative. (3) The [SMTP-CODES] reference makes no sense in this document and should be removed. (Nothing refers to it.) (4) The [DSN] reference needs to refer to draft-vaudreuil-1894bis-01.txt. draft-vaudreuil-1894bis-01.txt (1) The doc does not clearly say if it updates/obsoletes 1894. (An Obsoletes: RFC 1894 needs to be added at the beginning.) (2) Split references into normative & non-normative. (3) The ABNF in section 2.2.3 is broken. It should read: dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name (4) The field value suggested in section 2.2.3 has changed from "smtp" to "dns", which is a valid correction, but this change isn't noted in the change history. Finally, there's the issue I described in an earlier message regarding the ENVID and ORCPT parameters. Specifically, draft-moore-rfc1891bis-00.txt is quite clear that these fields can contain stuff other than ASCII characters: The syntax for "esmtp-value" in [4] does not allow SP, "=", control characters, or characters outside the traditional ASCII range of 1-127 decimal to be transmitted in an esmtp-value. Because the ENVID and ORCPT parameters may need to convey values outside this range, the esmtp-values for these parameters are encoded as "xtext". However, the corresponding Original-Envelope-Id and Original-Recipient fields defined in draft-vaudreuil-1894bis-01.txt are simply *text. This means some encoding must be allowed for. Absent a specification of the encoding to be used there's no way to insure interoperability. There are two ways to solve this: (1) State that ENVID and ORCPT can only contain ASCII text. (2) State that when ENVID and ORCPT values are placed in a DSN they should be encoded. The obvious encoding to use is xtext. FWIW, my own implementation in PMDF does (2). That's it! ------_=_NextPart_000_01C2335C.056CBB98-- ---------------------------------------------------------- This message was sent to you, since you are subscribed to [email protected]. You can manage your subscription at http://www.neystadt.org/cgi-bin/majordomo