MIME-Version: 1.0
In-Reply-To: <51923CFB.8090702@isode.com>
References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com>
 <51923CFB.8090702@isode.com>
Date: Tue, 14 May 2013 09:11:32 -0700
Message-ID: <CAL0qLwbF3CUfChe9C2yASW_FaOtEQwVA7+vyrU2OKpXbdXzZyw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: multipart/alternative; boundary=f46d043893cd081ba004dcafe32d
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-00
Precedence: list

--f46d043893cd081ba004dcafe32d
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 14, 2013 at 6:32 AM, Alexey Melnikov
<alexey.melnikov@isode.com>wrote:

> In Section 2.2:
>
>    Where an SMTP command is being reported as a "property", the MAIL
>    FROM command MUST be represented by "mailfrom" and the RCPT TO
>    command MUST be represented by "rcptto".  All other SMTP commands
>    MUST be represented unchanged.
>
> This seems to say that the SMTP reference is Normative, because one need
> to be able to lookup list of SMTP commands in RFC 5321. But RFC 5321 is
> listed as Informative.
>

OK.


> In Section 2.5.4:
>
>  LDAP needs an Informative Reference.
>

Are we sure about that?  It's just an example of a related service that
might cause a temperror for SMTP AUTH.  I could change it to "a directory
service" to avoid having to make that reference.  LDAP's not important to
this specification in any way.  I'll do that, actually.

>
>
> 2.5.5.  Extension Result Codes
>
>    Additional result codes (extension results) might be defined in the
>    future by later revisions or extensions to this specification.
>    Result codes MUST be registered with the Internet Assigned Numbers
>    Authority (IANA) and preferably published in an RFC.  See Section 6
>    for further details.
>
>    Extension results MUST only be used within ADMDs that have explicitly
>    consented to use them.  These results and the parameters associated
>    with them are not formally documented.  Therefore, they are subject
>    to change at any time and not suitable for production use.  Any MTA,
>    MUA or downstream filter intended for production use SHOULD ignore or
>    delete any Authentication-Results header field that includes an
>    extension result.
>
> I am mostly curious to see some examples of such extensions.
>

You could make one up and imagine using it.  Barry likes "banana", so:

Authentication-Results: your.example.com; banana=foobar

-MSK

--f46d043893cd081ba004dcafe32d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, May 14, 2013 at 6:32 AM, Alexey Melnikov <span dir=
=3D"ltr">&lt;<a href=3D"mailto:alexey.melnikov@isode.com" target=3D"_blank"=
>alexey.melnikov@isode.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">In Section 2.2:<br>
<br>
=A0 =A0Where an SMTP command is being reported as a &quot;property&quot;, t=
he MAIL<br>
=A0 =A0FROM command MUST be represented by &quot;mailfrom&quot; and the RCP=
T TO<br>
=A0 =A0command MUST be represented by &quot;rcptto&quot;. =A0All other SMTP=
 commands<br>
=A0 =A0MUST be represented unchanged.<br>
<br>
This seems to say that the SMTP reference is Normative, because one need to=
 be able to lookup list of SMTP commands in RFC 5321. But RFC 5321 is liste=
d as Informative.<br></blockquote><div><br></div><div>OK.<br>=A0<br></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In Section 2.5.4:<br>
<br>
=A0LDAP needs an Informative Reference.<br></blockquote><div><br></div><div=
>Are we sure about that?=A0 It&#39;s just an example of a related service t=
hat might cause a temperror for SMTP AUTH.=A0 I could change it to &quot;a =
directory service&quot; to avoid having to make that reference.=A0 LDAP&#39=
;s not important to this specification in any way.=A0 I&#39;ll do that, act=
ually.<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<br>
<br>
2.5.5. =A0Extension Result Codes<br>
<br>
=A0 =A0Additional result codes (extension results) might be defined in the<=
br>
=A0 =A0future by later revisions or extensions to this specification.<br>
=A0 =A0Result codes MUST be registered with the Internet Assigned Numbers<b=
r>
=A0 =A0Authority (IANA) and preferably published in an RFC. =A0See Section =
6<br>
=A0 =A0for further details.<br>
<br>
=A0 =A0Extension results MUST only be used within ADMDs that have explicitl=
y<br>
=A0 =A0consented to use them. =A0These results and the parameters associate=
d<br>
=A0 =A0with them are not formally documented. =A0Therefore, they are subjec=
t<br>
=A0 =A0to change at any time and not suitable for production use. =A0Any MT=
A,<br>
=A0 =A0MUA or downstream filter intended for production use SHOULD ignore o=
r<br>
=A0 =A0delete any Authentication-Results header field that includes an<br>
=A0 =A0extension result.<br>
<br>
I am mostly curious to see some examples of such extensions.<br></blockquot=
e><div><br></div><div>You could make one up and imagine using it.=A0 Barry =
likes &quot;banana&quot;, so:<br><br>Authentication-Results: <a href=3D"htt=
p://your.example.com">your.example.com</a>; banana=3Dfoobar<br>
<br></div><div>-MSK<br></div></div></div></div>

--f46d043893cd081ba004dcafe32d--