IPP Mail Archive: RE: IPP> NOT - Few minor remaining issues

IPP Mail Archive: RE: IPP> NOT - Few minor remaining issues

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

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Mar 08 2000 - 12:47:19 EST

  • Next message: Hastings, Tom N: "RE: IPP>NOT latest notify-poll document [time window NOT = lease time]"

    Bob,

    I forgot about what we said for a Printer Description attribute that is NOT
    defined to be READ-ONLY, but an implementation only supports one value. For
    example, a simplex printer only supports the 'one-sided' value for
    "sides-supported". I'm looking through the Set spec, but can't find it.

    Did we agree that the implementation could let the "sides-supported" be
    settable, but only to that one value, or the implementation could support
    "sides-supported" as not-settable, depending on implementation, correct?

    Then maybe my statement about "persistent-jobs-supported" isn't quite
    correct either:

    If the Printer supports this attribute as settable, then its value MUST
    control whether or not the Printer keeps Jobs persistently as per the rules
    in [ipp-set]).

    How about if I change it to something like:

    As with any settable attribute, if the Printer supports setting this
    attribute to more than one value, then the value being set MUST control
    whether or not the Printer keeps Jobs persistently as per the rules in
    [ipp-set]). As with any settable attribute, if the Printer only supports
    one value, it MAY support this attribute either (1) as settable to that one
    value, or as not-settable, depending on implementation.

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, March 07, 2000 18:30
    To: McDonald, Ira
    Cc: ipp
    Subject: RE: IPP> NOT - Few minor remaining issues in IPP Notification
    Spe c

    Ira,

    Thanks for replying.

    See my comments preceded by TH>

    Maybe we can resolve all of these issues quickly!

    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Tuesday, March 07, 2000 15:09
    To: 'Hastings, Tom N'; ipp
    Subject: RE: IPP> NOT - Few minor remaining issues in IPP Notification
    Spe c

    Hi Tom,

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

    Cheers,
    - Ira

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@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).

    TH> Does that mean we have to register the scheme as well?
    I like snmpnotify, ok? When should we change your document?

    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.

    TH> What do others think? Maybe we can agree on this issue too.

    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.

    TH> If it can't support persistent jobs, the value is 'false' and isn't
    settable.

    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.

    TH> If it can't support persistent jobs, the value is 'false' and isn't
    settable.

    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.

    TH> I agree with your assertions about SNMP. But what about some other
    delivery method, such as 'indp:' or 'mailto:'? Is it ok for a Notification
    Sender to include a collection attribute as an extension? If so, does that
    answer depend on our having a way in the encoding not to confuse IPP/1.1
    recipients that don't know about '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'.

    TH> So its ok that the "notify-charset" and "notify-natural-language"
    member attributes are validated against the existing Printer's
    "charset-supported" and
    "generated-natural-language-supported", respectively? There are no
    "notify-charset-supported" and "notify-natural-language-supported" Printer
    attributes defined.

    Thanks,
    Tom



    This archive was generated by hypermail 2b29 : Wed Mar 08 2000 - 12:53:27 EST