IPP> NOT - Few minor remaining issues in IPP Notification Spe c

IPP> NOT - Few minor remaining issues in IPP Notification Spe c

McDonald, Ira imcdonald at sharplabs.com
Tue Mar 7 18:08:35 EST 2000


Hi Tom,

My comments are below, prefixed by '> (ira)'.

Cheers,
- Ira


-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Tuesday, March 07, 2000 2:48 PM
To: ipp
Subject: IPP> NOT - Few minor remaining issues in IPP Notification Spec
Importance: High


I'm just about ready to publish the Notification Spec again, and have found
the following issues.  If we could resolve them (except Issue 02) on the
mailing list and discuss at tomorrow's IPP telecon, I can update before
making the Internet-Draft that we want to send out for IPP WG Last Call:

ISSUE 01 - Ok to include the notification delivery scheme names 'ipp:',
'indp:', 'mailto:', and 'snmp:' that are in progress as example values of
the "notify-recipient" (uri) attribute?

> (ira)
> As Ron Bergman pointed out, 'snmpnotify:' (or 'snmpnot:') must be used
> because 'snmp:' would name an SNMP Agent endpoint (command receiver
> and notification generator) rather than an SNMP Manager endpoint
> (command generator and notification receiver).

ISSUE 02 -  Once a number of delivery solutions have been developed and
evaluated, we may want to make one or several of them REQUIRED for
implementation to ensure a minimum set of interoperability.  Which one or
ones should be REQUIRED?

> (ira)
> Only 'ipp:' (in-band back channel), because it doesn't require new
> protocols to be supported.

ISSUE 03:  OK to allow the "persistent-jobs-supported" (boolean) Printer
Description attribute to be settable?

> (ira)
> Maybe - what if the implementation CAN'T support persistent jobs.

ISSUE 04:  OK to allow the "persistent-subscriptions-supported" (boolean)
Printer Description attribute to be settable?

> (ira)
> Maybe - what if the implementation CAN'T support persistent subscriptions.

ISSUE 05 - Can an implementation extend the Notification Content to include
an attribute that uses the 'collection' attribute syntax?  If so, should we
REQUIRE that Notification Recipients that can accept Machine Consumable
Notifications, be able to accept the 'collection' attribute syntax?

> (ira)
> SNMP notifications are machine consumable (they're certainly not human
> readable) and they CAN'T convey 'collection' attribute syntax.

ISSUE 06:  Ok that "notify-charset" and "notify-natural-language" member
attributes don't follow the "xxx-supported" rule for collection member
attributes, since the "xxx-supported" attributes are "charset-supported" and
"generated-natural-language-supported", respectively, instead of
"notify-charset-supported" and "notify-natural-language-supported"?

> (ira)
> OK by me - I would NOT like to see different 'notify-xxx-supported'
> than 'xxx-supported' for 'charset' and 'natural-language'.

Thanks,
Tom



More information about the Ipp mailing list