I've posted the "Internet Printing Protocol (IPP): The 'mailto:'
Notification Delivery Method" that Henrik and I collaborated on. It is
ready for Carl-Uno to send to the IETF as a first Internet-Draft.
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-notify-mailto-00.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000309.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000309.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000309.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000309-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000309-rev.pdf
Here is the Abstract:
The IPP notification specification [ipp-ntfy] is an OPTIONAL extension to
IPP/1.0 and IPP/1.1 that requires the definition of one or more delivery
methods for dispatching event notification reports to Notification
Recipients. This document describes the semantics and syntax of the
'mailto:' event notification delivery method. For this delivery method, the
IPP Printer uses the SMTP mail protocol to send (push) Human Consumable
and/or Machine Consumable Notifications to Notification Recipients. The
Subscriber specifies the mail address using the mailto: URL. This mail
address can be any user or can be any of the mail services defined to
perform such notification using parameters in the URL, such as paging. The
Subscriber can specify the MIME media type of both the Human Consumable and
Machine Consumable Notifications. The Subscriber can also specify a mail
address in the "subscriber-user-data" Subscription attribute to which the
Notification Recipient can reply and to which the mail system delivers
undeliverable mail messages. That mail address is usually the Subscribers
mail address, but can be any mail address.
The mail messages appear to come from the Printer, so that mail agents can
sort and filter on the From: field. Also the beginning of the Subject line
starts with the localized "Printer message: " prefix, so that mail agents
can filter from any Printer.
There are 7 ISSUES called out in the text.
We would like the SMTP folks to help us with some of the issues. The issues
are:
Notification Sources that implement the 'mailto:' event notification
delivery method will need to include an SMTP mail agent while Notification
Recipients that implement this delivery method will need to support an SMTP
server. ISSUE 01: Is this SMTP terminology correct?
ISSUE 02: Is it a good idea to list each Subscription object attribute in
this spec with the applicability to this delivery method? If yes, should
all delivery method specs also do it this way? Section 5 defines how the
IPP Printer populates the SMTP fields in the mail message.
ISSUE 03 - What should we say about any mailto parameters, if any? For
example, if you want to send over secure mail, etc.
ISSUE 04 - Do we want to define any IPP-specific mailto parameters to this
document?
ISSUE 05: Ok that we made "subscriber-user-name" be REQUIRED for the
Printer to support and indicate that the client MUST supply the
"requester-user-name" operation attribute when the delivery method is
'mailto:', in case the Printer does not have a more authenticated printable
name?
ISSUE 06: What if "notify-format" is 'text/plain; charset=utf-8', does that
have to be sent as a mail attachment, since it isn't 'text/plain' which
assumes charset=us-ascii, or can it be sent as the body of the mail message
properly identified as 'text/plain; charset=us-ascii'?
ISSUE 07 - Is there any way that a Notification Recipient could reply to the
message in such a way as to cancel the subscription and thereby solve the
spam problem?
Send comments to the mailing list.
Thanks,
Tom
This archive was generated by hypermail 2b29 : Thu Mar 09 2000 - 19:29:10 EST