There are many cases where new protocols are approved when they offer
improvements over existing ones.
**********************************************
* 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 606 works until 10/1) *
**********************************************
imcdonald%sharplabs.com@interlock.lexmark.com on 07/26/2000 12:47:06 PM
To: harryl%us.ibm.com@interlock.lexmark.com, Don_Wright/Lex/Lexmark@LEXMARK
cc: ipp%pwg.org@interlock.lexmark.com,
pmoore%peerless.com@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
Subject: RE: IPP> notification methods
Hi Harry and Don,
Right - the IETF won't approve a new notification protocol
(INDP) over an existing and DEPLOYED one (SMTP).
Cheers,
- Ira
-----Original Message-----
From: harryl@us.ibm.com [mailto:harryl@us.ibm.com]
Sent: Wednesday, July 26, 2000 8:11 AM
To: don@lexmark.com
Cc: ipp@pwg.org; pmoore@peerless.com
Subject: Re: IPP> notification methods
Agree. But this has no bearing on the question of what to mandate. If
anything, it points to mandating only mailto under the observation
(assumption) that (at least in the beginning) mailto enabled clients will
be more pervasive than indp enabled clients.
Harry Lewis
IBM Printing Systems
don@lexmark.com
Sent by: owner-ipp@pwg.org
07/26/2000 08:59 AM
To: Harry Lewis/Boulder/IBM@IBMUS
cc: ipp@pwg.org, pmoore@peerless.com
Subject: Re: IPP> notification methods
The real difference between the use of mailto versus INDP is that mailto
is for
a receipient who does not have an IPP/INDP enabled client or does not have
it
running at the time the notification is to be received.
**********************************************
* 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 10:54:23 AM
To: Don_Wright/Lex/Lexmark@LEXMARK
cc: ipp%pwg.org@interlock.lexmark.com,
pmoore%peerless.com@interlock.lexmark.com (bcc: Don
Wright/Lex/Lexmark)
Subject: Re: IPP> notification methods
I accept that INDP may "work" in the Internet if properly configured. But,
in this case, you wouldn't necessarily need to mandate mailto for human
readable. So either association (mail/human - indp/machine OR mail/inter
- indp/intra) is equally flawed.
Then... the only thing certain is that mailto is NOT intended for machine
readable. Why don't we just state that?
Peter Z. has a suggestion for helping to determine what is supported.
> a notification... sent out at INDP registration... (that) allows a...
> recipient to determine if the infrastructure supports INDP...
Harry Lewis
IBM Printing Systems
don@lexmark.com
Sent by: owner-ipp@pwg.org
07/26/2000 05:01 AM
To: Harry Lewis/Boulder/IBM@IBMUS
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 - 23:24:08 EDT