ietf-smtp
[Top] [All Lists]

Re: revised draft-malamud-no-soliciting-05

2004-02-01 10:16:36


----- Original Message ----- 
From: "Carl Malamud" <carl(_at_)media(_dot_)org>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Saturday, January 31, 2004 1:37 PM
Subject: revised draft-malamud-no-soliciting-05



Hi -

Based on comments received, I've put a new draft at:

http://trusted.resource.org/no-solicit/

It has also been resubmitted to the i-d queue.  Thanks
for everybody for your comments.  Please feel free to
send additional comments to this list, to me, to the
iesg, or to the forum of your choice.

Regards,

Carl




A few minor comments.  Please take these from the viewpoint of an
experienced developer, technical document writer, reviewer, etc, as if I was
going to use this specification for the first time to implement, i.e.,  it
was endorsed,  I found it on the net and I was going to use the spec for the
first time.  Mostly about wording.

| 2. The No-Soliciting SMTP Service Extension
|
|   Per [RFC2821], a "NO-SOLICITING" SMTP service extension is defined..

This sentence made me pause for a second wondering if this means the
"NO-SOLICITING" extension is actually defined in RFC2821.  Don't laugh but
just to make sure I actually went ahead and double checked. <g>   It also
made me think that maybe it might mean it was something planned for a new
RFC2821.

I think it should be paraphrased, maybe like so:

    Per EHLO specification  [RFC2821],  a new "NO-SOLICITING" EHLO service
extension is defined.

A similar statement in:

| 2.5 Solicitation Mail Header
|
|  Per [RFC2822], a new "Solicitation:" header field is defined which
|   contains one or more solicitation class keywords.

This sounds like the header is defined in the '2822' document or that your
document is augmented with planned changes to the 2822 document.  Again,
don't laugh!  I definitely double checked 2822 to see if there was a new
"Solicitation:" header defined.   Made me think I had missed something in
basic 2822 mail support! <g>

To rephrase this sentence, do you really need to say "Per [RFC2822]?"
Maybe a rewording can be:

    Following RFC2822 for creating and formatting network control headers,
this specification defines a new "Solicitation:"
    header field which contains one or more solicitation class keywords.

| 2.1 The EHLO Exchange

Possibly a note should be made the NO-SOLICITING extension support "does
not" | "should not"  imply current servers a similar no solicitating tag or
message in the greeting is now deprecated.    I see your historical note
about Levine/Hoffman and the greeting tag and bandwidth consideration.   In
my view,  it is only a  (small) consideration now  when both are used.  It
is not when one or the other is used.   So it should be discussed as to what
you recommend as there will be implementations already using a greeting tag.
In other words,  "What should they do? if anything.  What do you recommend?"

In the same vain, unless I missed it,  a comment about minimal support?
for clients and servers?

For Clients, I see 3 things:

       solicitation: header
       detecting EHLO No Soliciting
       using /MAIL FROM

You might clients might want to simply add the solicitation header only or
they might just want to look fo "NO SOLICITING" in the ehlo.

For servers:

       Using EHLO No Soliciting
       Adding a policy to support SOLICIT=
       Adding a policy to support Solicitation:

I hope these comments are useful and not redundant.

--- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com






<Prev in Thread] Current Thread [Next in Thread>
  • Re: revised draft-malamud-no-soliciting-05, Hector Santos <=