Henrik and I put together a mailto notification delivery scheme for
discussion tomorrow at the IPP WG meeting. Send any comments to the mailing
list.
The files are at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000209.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000209.pdf
Here is the Abstract:
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
'ipp-notify-mailto' event notification delivery method. For this delivery
method, the IPP Printer uses SMTP mail to send Human Consumable and/or
Machine Consumable Notifications to Notification Recipients. 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" 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 9 issues:
ISSUE 01 - What should we say about any mailto parameters? For example, if
you want to send over secure mail, etc.
1.1 notify-events (1setOf type2 keyword)
This REQUIRED READ-ONLY Subscription object attribute identifies the job
and/or printer events that are to be delivered to the Notification Recipient
as Notifications as defined in [ipp-ntfy] section 7.
Note: Some rapid events, such as page events, are not appropriate to use
with this delivery method.
ISSUE 02 - Should we disallow page events with the 'mailto:' delivery
method?
1.2 notify-human-consumable-format (mimeMediaType)
ISSUE 03 - Ok to change the name of "notify-text-format" to
"notify-human-consumable-format" since it can contain pictures and/or sound?
Also it becomes more parallel with the proposed new
"notify-machine-consumable-format" attribute.
1.1 notify-machine-consumable-format (mimeMediaType) - new
This REQUIRED READ-ONLY Subscription object attribute indicates the type of
Machine Consumable format content that is to be sent in the Notifications.
If this attribute is not supplied, the Printer supplies the
'application/ipp' value by default. If the out-of-band 'none' [ipp-col] is
supplied, the Printer MUST NOT send the Machine Consumable form in the
Notification.
ISSUE 04 - We think that the subscriber should be able to specify whether or
not to include the Machine Consumable form and what that machine consumable
format is, such as 'application/ipp', or XML format.
1.2 subscriber-user-data (octetString(63))
This REQUIRED READ-ONLY Subscription object attribute holds an SMTP mail
address value that the Printer copies to the "From:" and "Sender:" SMTP
fields (see section 5).
ISSUE 05 - Ok to use the "subscriber-user-data" attribute to hold the SMTP
"From:" and "Sender:" mail addresses in case the Notification Recipient
replies to the notification mail message or the mail system sends a failure
to deliver message, respectively?
If this attribute is not supplied, the Printer SHOULD fill in some mail
address to which replies or non-delivery messages can be sent, in case the
Printer is not able to receive mail messages. Otherwise, the mail system
will send non-delivery messages to the Printer.
ISSUE 06 - Should we add a Printer Description attribute that the
Administrator can configure to be the "bit bucket" for non-delivery messages
and Notification Recipient replies when the Subscriber does not supply the
"subscriber-user-data"?
ISSUE 07 - Need a Printer Description attribute that the system
administrator can configure to be the DNS or IP address of the SMTP relaying
mail server (see [rfc822]) that it is to use for the 'mailto:' delivery
method.
ISSUE 08 - Ok to prohibit the mailto: scheme from using the
"human-readable-report" attribute in the Machine Consumable form, since it
can send both forms in one Notification content?
ISSUE 09 - 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?