IPP Mail Archive: RE: IPP> RE: Mandatory Delivery Method for

IPP Mail Archive: RE: IPP> RE: Mandatory Delivery Method for

RE: IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15

From: Dennis Carney (dcarney@us.ibm.com)
Date: Wed Apr 17 2002 - 00:16:46 EDT

  • Next message: Carl: "IPP> RE: Mandatory Delivery Method for Notifications - Comments by April 15"

    (BTW, I have absolutely no intention of writing a client that only does
    email notifications--I personally like ippget much more than email
    notifications.)

    Tom (and Carl), you say the hypothetical product discussed below isn't
    going to have a "black mark" because it doesn't do ippget notifications,
    but then you point out that customers might not buy the product if it can't
    claim compliance. That is probably the ultimate black mark--lost sales.

    If "ippget" and "mailto" notifications were really two different ways to do
    more or less the same thing, I wouldn't mind making one mandatory. But
    ippget makes sense for programs to use and mailto makes sense for humans to
    use. For some products, mailto makes sense and ippget doesn't. Those
    products can know that ippget is the only one guaranteed to be supported by
    the printer, but if programmatic notifications aren't useful to them in the
    first place, they don't get more useful just because many printers can
    supply them.

    So, I've said my two cent's worth (yeah, I know I probably stretched your
    patience and got 4 or 5 cent's worth! ;-) on this subject. Thanks for
    listening.

    Dennis

                                                                                                                                     
                          "Hastings, Tom N"
                          <hastings@cp10.es To: Dennis Carney/Boulder/IBM@IBMUS, ipp@pwg.org
                          .xerox.com> cc: Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N"
                          Sent by: <hastings@cp10.es.xerox.com>, "McDonald, Ira" <imcdonald@sharplabs.com>
                          owner-ipp@pwg.org Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications - Commen
                                                    ts by April 15
                                                                                                                                     
                          04/16/02 12:40 AM
                                                                                                                                     
                                                                                                                                     

    Dennis,

    Your example is a client whose implementor has decided not to conform to
    the
    Notification specification (when it only supports email). Don't feel bad!
    The IPP Police aren't going to come and get you. Your product isn't going
    to have a black mark. It just can't advertise that it conforms to the IPP
    Notification specification. Its ok not to conform. The idea of client
    conformance is that if a client conforms, then it can interoperate with a
    conforming Printer.

    Since this is a conditional conformance requirement for both client and
    Printer, a Notifications conforming client and a Notifications conforming
    Printer will be able to interoperate notifications.

    Think of a customer who is buying a client and a Printer. If both say they
    conform to the IPP Notifications, then that customer know that these two
    products will be able to exchange notifications (at least IPPGET).

    In you example, the customer wouldn't be mis-led into buying your client
    (which doesn't claim to conform to IPP Notifications) and a Printer which
    does conform to IPP Notifications, and then discover that they don't
    interoperate (say, the conforming Printer doesn't support mailto, but only
    IPPGET).

    OK?

    Tom

    -----Original Message-----
    From: Dennis Carney [mailto:dcarney@us.ibm.com]
    Sent: Monday, April 15, 2002 18:53
    To: ipp@pwg.org
    Cc: 'Harry Lewis'; Hastings, Tom N; McDonald, Ira
    Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    Commen ts by April 15

    So, let's say I have an IPP client that does not have a status GUI (job
    submitter only); or an IPP client that implements status, but does it by
    polling.

    Then I see the notifications drafts and I think that a nice option to allow
    my users is that if the printer supports e-mail notifications, I will allow
    them to give me their email address and I will register them for email
    notifications.

    However, my client cannot claim to be an "IPP notifications compliant"
    client because it hasn't implemented ippget. So to become compliant, I
    must "implement"/"support" ippget, *even if* my client is not going to use
    it? Hmmm, so since I'm not going to use it, I guess I don't have to test
    my implementation very hard. But come to think of it, if I'm not going to
    use it, no one can actually tell (by sniffing or any other method) whether
    I have implemented it correctly (they can tell I didn't use it, but can't
    tell whether my unused implementation code works or not). So I guess I can
    just claim I support ippget--no one can prove me wrong!

    This is what I'm trying to get at when I wonder what it means to force a
    client to support something. Each client uses the interfaces necessary for
    it to get its job done. Forcing it to issue ippget calls then simply throw
    out the results, just so it can be compliant and have the buzzwords on its
    marketing material, seems to be a mistake to me.

    Dennis Carney
    IBM Printing Systems

                          "Hastings, Tom N"

                          <hastings@cp10.es To: "McDonald, Ira"
    <imcdonald@sharplabs.com>, Harry
                          .xerox.com> Lewis/Boulder/IBM@IBMUS,
    "Hastings, Tom N" <hastings@cp10.es.xerox.com>
                          Sent by: cc: Dennis
    Carney/Boulder/IBM@IBMUS, ipp@pwg.org
                          owner-ipp@pwg.org Subject: RE: IPP> RE:
    Mandatory Delivery Method for Notifications - Commen
                                                    ts by April 15

                          04/15/02 12:26 PM

    Harry,

    I agree with Ira. Furthermore, the advantage of having the client
    conformance requirements (as well as the Printer conformance requirements),
    is that a client implementor knows that his/her conforming notifications
    implementation will interoperate with any Printer that is also a conforming
    notifications implementation.

    BTW, the reason that we didn't have client conformance requirements in the
    original Notifications and Subscriptions spec, is because we didn't have
    agreement on any REQUIRED Delivery Method for the Printer when it supports
    Notification. So now that we have agreement for the Printer, we can add
    that requirement for the client (conditional on the client supporting
    notifications at all).

    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Monday, April 15, 2002 10:51
    To: 'Harry Lewis'; Hastings, Tom N
    Cc: Dennis Carney; ipp@pwg.org
    Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    Commen ts by April 15

    Hi Harry,

    To prove interoperability in protocols, the IESG always requires
    conformance requirements for both Client and Server (Printer, in
    our case).

    But the requirement will be conditional:

    If an IPP Printer supports notifications, then it MUST support
    the 'ippget' in-band delivery method.

    If an IPP Client supports notifications, then it MUST support
    the 'ippget' in-band delivery method.

    OK?

    Cheers,
    - Ira McDonald
      High North Inc

    -----Original Message-----
    From: Harry Lewis [mailto:harryl@us.ibm.com]
    Sent: Thursday, April 11, 2002 4:04 PM
    To: Hastings, Tom N
    Cc: Dennis Carney; ipp@pwg.org
    Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    Commen ts by April 15

    I support mandating IPPGET for IPP notification but I believe the mandate
    should apply to the printer not the client.

    Architecturally, mandating support (for IPPGET) at the printer is
    sufficient to support complete interoperability. It is overkill to mandate
    both ends. For IPPFAX (a specific application of IPP) I agree we want to
    lock down the specification for every node.

    Are you are saying that someone can build a client with (ex.) mailto
    notification support (only)... but they just can't claim it is an IPP
    client that supports notification? If someone chooses to do this, of
    course they run the risk of reduced interoperability. That is a conscious
    choice. The architecture and specifications still fully support complete
    interoperability.
    ----------------------------------------------
    Harry Lewis
    IBM Printing Systems
    ----------------------------------------------

    "Hastings, Tom N" <hastings@cp10.es.xerox.com>
    Sent by: owner-ipp@pwg.org
    04/10/2002 06:08 PM

            To: Dennis Carney/Boulder/IBM@IBMUS
            cc: ipp@pwg.org
            Subject: RE: IPP> RE: Mandatory Delivery Method for
    Notifications - Commen ts
    by April 15

    Dennis,

    Yes, I was adding to Carl-Uno's proposal, because in order to get
    interoperability between a client and a Printer you need to have
    conformance
    requirements for both the client and Printer, not just the Printer. The
    reason we left out client conformance in the Notification spec was because
    we didn't have any Delivery Method REQUIRED for the Printer, if
    Notifications were supported. But now the proposal is for the
    Notification
    spec to REQUIRE the Printer to support (implement) the IPPGET Delivery
    Method, if the Printer supports Notification.

    However, I don't think that there is the problem that you think for adding
    this client requirement. My entire statement was:

    2. REQUIRE that a client support the IPPGET Delivery Method, if it
    supports
    IPP Notifications.

    The "if ..." doesn't require clients to support (implement) Notifications.
    But if a client does support (implement) IPP Notifications, then it MUST
    support (implement) IPPGET Delivery Method and MAY support (implement)
    others. Then such a conforming client can interoperate with a conforming
    Printer, including Notifications. None of these statement require the
    client to actually *use* Notifications, if the user doesn't want to.

    OK?

    Tom

    -----Original Message-----
    From: Dennis Carney [mailto:dcarney@us.ibm.com]
    Sent: Wednesday, April 10, 2002 08:54
    To: ipp@pwg.org
    Cc: Hastings, Tom N
    Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    Commen ts by April 15

    Tom,

    I see a way in which your comments added a new wrinkle, although I may be
    mistaken. I didn't get the impression in the previous messages that we
    were discussing mandating that a *client* support IPPGET if it supports
    any
    notification mechanisms--I read Carl's "notification implementations" as
    discussing IPP servers only.

    What does it mean that a client "support" a mandatory notification
    mechanism? If the client has no interest in actually using that
    mechanism,
    it doesn't make sense to force the client to implement it anyway, then
    just
    not use it. Am I missing something?

    Dennis Carney
    IBM Printing Systems

                          "Hastings, Tom N"

                          <hastings@cp10.es To: Carl
    <carl@manros.com>

                          .xerox.com> cc: ipp@pwg.org

                          Sent by: Subject: RE: IPP> RE:
    Mandatory Delivery Method for Notifications - Commen ts by April 15
                          owner-ipp@pwg.org

                          04/09/02 07:32 PM

    Carl-Uno,

    I support the proposal to REQUIRE a Notification Delivery Method so that
    interoperability between a conforming client and a conforming Printer is
    enhanced for Notifications.

    I also support the proposal to make IPPGET be that REQUIRED Delivery
    Method
    by changing the IPP Notifications and Subscriptions document (which is an
    OPTIONAL IPP extension document) in the following ways:

    1. REQUIRE that a Printer support the IPPGET Delivery Method, if the
    Printer
    supports IPP Notifications.

    2. REQUIRE that a client support the IPPGET Delivery Method, if it
    supports
    IPP Notifications.

    3. RFC 2910 already RECOMMENDs that a Printer support TLS, so saying the
    same thing in the Notifications and Subscriptions document would be
    redundant, but we could still do that.

    Compared to our other two Delivery Methods (MAILTO and INDP), the IPPGET
    Delivery Method has the following advantages:

    a. it is the easiest Delivery Method to support
    b. it is in-band so it doesn't create any additional firewall problems
    c. it is also useful for LAN job submission (with no firewall)
    d. it doesn't create any more administrative problems
    e. it is REQUIRED for IPPFAX conformance.
    f. and doesn't have any SPAM problems (since the job submitter is polling
    and/or keeping a channel open for notification events).

    The IPPGET spec also should be changed:

    4. We should also change the IPPGET spec itself from its current
    "RECOMMENDED" to "REQUIRED" as a Delivery Method for an IPP Printer to
    support.

    Tom

    -----Original Message-----
    From: Carl [mailto:carl@manros.com]
    Sent: Saturday, March 30, 2002 13:30
    To: Carl; ipp@pwg.org
    Subject: IPP> RE: Mandatory Delivery Method for Notifications - Comments
    by April 15

    Resend, with spelling corrected etc. The earlier message slipped away
    before
    I had finished it.

    All,

    Ned Freed communicated in an earlier message to the IPP WG, that the IESG
    found it unacceptable that we had not choosen ONE mandatory delivery
    method
    for notifications. They would also like to see that delivery method
    mandate
    the use of security.

    As those of you who were around about two years ago remember, we could not
    reach agreement about mandating any of the delivery methods.

    However, in the meantime the members of the IPPFAX project in the Printer
    Working Group has reached an agreement that they will require all IPPFAX
    implementions to implement the 'ippget' delivery method, and it also
    requires support for TLS security.

    Hence, I would like to put up the following strawman proposal to the IPP
    WG
    members to satisfy the IESG comments:

    1) Change the main Notifiction document to require that 'ippget' delivery
    MUST be included for all notification implementations, but any of the
    other
    two methods can also be implemented as an option.
    <draft-ietf-ipp-not-spec-08.txt>

    2) Put that rule also into the three delivery method documents, so it is
    crystal clear what the rule is.
    <draft-ietf-ipp-notify-get-06.txt>
    <draft-ietf-ipp-notify-mailto-04.txt>
    <draft-ietf-ipp-indp-method-06.txt>

    3) Further, in the 'ippget' delivery document, we specify that TLS
    security
    MUST be supported.
    <draft-ietf-ipp-notify-get-06.txt>

    If we can reach agreement on this, I will instruct the IPP editor to
    implement these changes.

    I would like to get your reactions back on this proposal no later than
    April
    15, 2002.

    Carl-Uno Manros
    Chair of IETF IPP WG

    10701 S Eastern Ave #1117
    Henderson, NV 89052, USA
    Tel +1-702-617-9414
    Fax +1-702-617-9417
    Mob +1-310-251-7103
    Email carl@manros.com



    This archive was generated by hypermail 2b29 : Wed Apr 17 2002 - 00:18:57 EDT