david nicol wrote:
On Fri, 2003-09-26 at 00:20, Yakov Shafranovich wrote:
How would you suggest that recipients would go about granting and
denying permissions (or consent) if there are no standards in place? Are
you suggesting that the receiver simply chooses not to receive certain
kinds of email and that email starts to bounce? If so, there is still a
need to have some form of a format or standard in place that the
receiver can use to communicate his consent decisions to his MUA, MTA or
ISP.
Yakov
Why does the standard need to precede the implementation? That happens
to be contrary to IETF practices as I understand them. If we are talking
about a communication between an end-user to a provider of service
to that end-user, we don't need a standard until there is at least
one implementation. Current standards in presentation and gathering
are sufficient. Pay2send uses a clumsy web page to allow account
holders to edit their opt-in lists, but it will be made into a less
clumsy interface, and also a purely-e-mail interface will be provided,
before the pay2send SMTP daemon package version 1 is called complete.
First of all, I meant standards in general, not in the IETF lingo. IETF
requires at least two interoperable implementations in order for the a
proposed standard to become an accepted standard. HOWEVER,
implementations are not required in order to propose a standard as per
the case with the CRI proposal.
rfc821 Appendix E Reply Code (rfc 2821 sec 4.2.1) protocol
is so rich that there is
room for 5yz codes that would indicate "not wanted due to sender's
absence from receiver's opt-in list and lack of sender being
listed with the appropriate postage stamp authority"
No such code is defined in 2821.4.2.1 but one will have to be
provided as the reply in the pay2send smtp server. I am planning,
(with approval from my local Perl Mongers chapter) to use
"402 payment required" as the reply code in such a case, after
the defined "402" from HTTP.
You might also want to take a look at RFC 3463 which defines a set of
extended code. In general it is not a good idea to cross over codes from
one protocol to another such HTTP to SMTP.
Although adding funds to a postage account would seem to be
a user-correctable-only action under 821's guidelines for
selection of a 5yz reply code, it is hoped that a future mail
system will be able to take care of identifying and transferring
appropriate funds, if possible, without requiring user intervention.
The exact nature of the fund transfer does not need to be part of the
mail transfer protocol.
How would a MUA communicate with a MTA in e-postage system such as
Pay2Second? Whichever system you suggest or define, still needs to be
published or covered in some document, which might as well be an ID or RFC.
Once we are establishing a standard for communication between a MUA and
a MTA, we might as well generalize it as a standard for MUA to
communicate consent to MTAs. This way other systems beside e-postage can
be covered such as digital certificates, hashcash, etc. The whole point
of such consent exchange protocol is so it is general enough not to
cover a specific implementation, and thus can be used in many types of
implementations.
Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg