IPP Mail Archive: RE: IPP> notification methods

RE: IPP> notification methods

From: Carl-Uno Manros (carl@manros.com)
Date: Wed Jul 26 2000 - 10:57:32 EDT

  • Next message: harryl@us.ibm.com: "Re: IPP> notification methods"

    Don,

    I fully agree with your statement. I think we have now reached a time where
    it is crusial to get the firewall people to develop product solutions that
    will allow IPP traffic, and INDP traffic through firewalls. The basic
    philosophy for all firewalls is to stop anything they don't understand. So
    let us start serious discussions with the firewall vendors and major
    organizations that use firewalls about HOW to do it, instead of assuming
    that they never will do it. NO new protocol can succeed if we just stay
    inactive.

    Carl-Uno

    > -----Original Message-----
    > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of
    > don@lexmark.com
    > Sent: Wednesday, July 26, 2000 4:01 AM
    > To: harryl@us.ibm.com
    > Cc: pmoore@peerless.com; ipp@pwg.org
    > Subject: Re: IPP> notification methods
    >
    >
    > I fail to see the reason to ASSUME that every implementation of
    > IPP NOTIFICATION
    > will occur behind a firewall that is NOT configured to allow INDP
    > notifications
    > to pass through it. Any attempt to associate "mailto" or "indp"
    > EXCLUSIVELY
    > with either INTERnets or INTRAnets is flawed. If we would have used this
    > argument for IPP in the beginning we would have made statements like:
    >
    > 1. If a device is configured to print across the Internet it IS
    > OUT OF LUCK.
    > 2. If a device is configured to print in the context of an
    > Intranet it MUST
    > support IPP.
    >
    > Let's separate the issue of the INTERNET vs INTRANET context of
    > these delivery
    > services. When a customer decides they want these services, they
    > will configure
    > their firewalls (if present) to make it happen.
    >
    > **********************************************
    > * Don Wright don@lexmark.com *
    > * Chair, Printer Working Group *
    > * Chair, IEEE MSC *
    > * *
    > * Director, Strategic & Technical Alliances *
    > * Lexmark International *
    > * 740 New Circle Rd *
    > * Lexington, Ky 40550 *
    > * 859-232-4808 (phone) 859-232-6740 (fax) *
    > * (Former area code until 10/1 was 606) *
    > **********************************************
    >
    >
    >
    >
    >
    >
    > harryl%us.ibm.com@interlock.lexmark.com on 07/26/2000 01:00:41 AM
    >
    > To: pmoore%peerless.com@interlock.lexmark.com
    > cc: ipp%pwg.org@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
    > Subject: Re: IPP> notification methods
    >
    >
    >
    >
    >
    >
    > I feel a more accurate way of looking at it is:
    >
    > 1. If a device is configured to provide event notification across the
    > Internet it MUST support mailto
    > 2. If a device is configured to provide event notification in the context
    > of an Intranet it SHOULD support INDP
    >
    > We could live with the proposal to bind human/mail vs. machine/indp.
    > However, this ignores the fact that INDP also handles human readable.
    >
    > Harry Lewis
    > IBM Printing Systems
    >
    >
    >
    >
    > pmoore@peerless.com
    > Sent by: owner-ipp@pwg.org
    > 07/20/2000 09:31 AM
    >
    >
    > To: ipp@pwg.org
    > cc:
    > Subject: IPP> notification methods
    >
    >
    > Following the SF meeting I would like to formally propose the following.
    >
    > 1. If a device wants to expose human readable events then it MUST support
    > the
    > mailto method
    >
    > 2. If a device wants to expose machine readable events then it MUST
    > support the
    > INDP method
    >
    > But we do not UNCONDITIONALLY require either.
    >
    > (Now dons flame-proof clothing and awaits flaming)
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >



    This archive was generated by hypermail 2b29 : Wed Jul 26 2000 - 11:03:07 EDT