What if we had a way for the client to indicate "it's OK to maintain the
connection established during this IPP print job and continue to send me
job status notifications until the job is complete"? Isn't this the
desirable behavior for Qualdocs?
Harry Lewis
IBM Printing Systems
pmoore@peerless.com
Sent by: owner-ipp@pwg.org
08/21/2000 05:29 PM
To: Harry Lewis/Boulder/IBM@IBMUS
cc: pmoore@peerless.com, bwagner@digprod.com, ipp@pwg.org, "Herriot, Robert"
<Robert.Herriot@pahv.xerox.com>, Carl Kugler/Boulder/IBM@IBMUS
Subject: RE: IPP> machine readable etc. - why Harry is right
Welcome back from vacation,
Dont despair - I think we can still consider doing things. Nothing is cast
in
concrete yet and there is still violent disagreement about what we
currently
have.
There are two workable possibilities - one is ipp-get. This already exists
but
is polling - and people have a visceral dislike of polling to say the
least!
The other alternative is a tweak to indp. Instead of the client sending in
a url
and the printer connecting to that URL we could have a client-opened
connection.
i.e. the client opens the connection
it subscribes on the 'normal' operation url,
in the subsription the notification url is 'indp:'
the lack of an address in the url causes the printer to use the exisitng
connection rather than open a new one.
The only question I see is what is the URL that the client must connect
to?
We could have a printer attribute.
Alternatively we could reverse the order of the client opening the
connection
and the subscribe. In this case the subscribe operation returns the
connection
point address.
Note that this would be in additon to the indp:<heres my url> mechanism.
"Harry Lewis/Boulder/IBM" <harryl@us.ibm.com> on 08/21/2000 04:01:01 PM
To: pmoore@peerless.com
cc: bwagner@digprod.com, ipp@pwg.org, "Herriot, Robert"
<Robert.Herriot@pahv.xerox.com>, "Carl Kugler/Boulder/IBM"
<kugler@us.ibm.com> (bcc: Paul Moore/AUCO/US)
Subject: RE: IPP> machine readable etc. - why Harry is right
What could be finer than to take a few day vacation, forget to read your
mail and return to a long string of "why is Harry right" messages? ;-).
1. The proposal was joint between Carl Kugler and I
2. We clearly indicated that ours was a simple, native IPP notification
proposal... not intended to solve all the (complex) notification
requirements such as 3rd party notification.
3. We cited QualDocs as a scenario that warrants simple, inband IPP
notifications.
4. We were "shot down" because
- Attempts to articulate the difference between "Server Directed
Polling" and "Real Time Notifications" and how they could be combined
into an overall solution failed. Enough people heard the word "poll" and
stopped reading at that point (I guess).
- Our use of MIME Multipart/mixed over a sustained connection was
considered to be fraught with pitfalls of proxy buffering and/or lost
connections.
5. There were other issues as mentioned (He wanted to change the response
of operations, such as Print-Job so that the operation
would last as long as the job and would contain the existing response plus
a stream of Event Notifications.). I guess if we had tried to work this
out as long as we've debated firewall issues for other proposals... we may
have gotten somewhere by now.
6. We were told we should "demonstrate" the feasibility of our solution to
warrant further discussion and didn't have the bandwidth to do so at the
time. Other solutions seem to have moved forward, in light of firewall
issues etc. with no such demonstration. Not sure what that's all about.
7. We ultimately feel interoperability is best served by limiting the
number of choices to accomplish the same thing. With this in mind and in
the context described, above, after some time, we decided not to continue
pursuing the proposal.
Perhaps Qualdocs is the appropriate forum to reconsider a truly native IPP
notification protocol?
Harry Lewis
IBM Printing Systems
pmoore@peerless.com
08/18/2000 03:23 PM
To: "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>
cc: "Wagner,William" <bwagner@digprod.com>,
"'pmoore@peerless.com'"
<pmoore@peerless.com>, Harry Lewis/Boulder/IBM@IBMUS, ipp@pwg.org
Subject: RE: IPP> machine readable etc. - why Harry is
right
OK - I was refering to ipp-get when I said 'harry is right'. The lingering
print-job is not the right thing to do.
"Herriot, Robert" <Robert.Herriot@pahv.xerox.com> on 08/18/2000 01:53:33
PM
To: "Wagner,William" <bwagner@digprod.com>, "'pmoore@peerless.com'"
<pmoore@peerless.com>
cc: "'Harry Lewis/Boulder/IBM'" <harryl@us.ibm.com>, ipp@pwg.org (bcc:
Paul
Moore/AUCO/US)
Subject: RE: IPP> machine readable etc. - why Harry is right
As I remember there were other issues with Harry's proposal. He wanted to
change the response of operations, such as Print-Job so that the operation
would last as long as the job and would contain the existing response plus
a
stream of Event Notifications.
The 'ipp-get' Delivery Method was attempt to put the Event Notifications
in
a separate operation and to get some of what Harry wanted. It avoided
legacy
issues of changing existing operations and it allowed an entity other than
the initiator of the operation to listen for Event Notifications. But it
missed some of what Harry wanted because it is a polling operation --
returning accumulated Event Notifications
If someone wanted to do the work, that person could define something
closer
to what Harry wants. It could be like 'ipp-get' where a Get-Notifications
operation gets all Event Notifications whose leases haven't expired, but
unlike 'ipp-get' the Printer could keep sending Event Notifications in the
response as new ones occur. With this solution the client would receive
Event Notification as they occur (what Harry wants) and would receive
Event
Notifications from the recent past in order to get those Event
Notifications
that occur between the Printer-Job operation and a new Get-Notifications
operation and between successive Get-Notification operation whenever a
Get-Notification operation terminates for whatever reason.
Bob Herriot
> -----Original Message-----
> From: Wagner,William [mailto:bwagner@digprod.com]
> Sent: Thursday, August 17, 2000 10:07 AM
> To: 'pmoore@peerless.com'
> Cc: 'Harry Lewis/Boulder/IBM'; ipp@pwg.org
> Subject: RE: IPP> machine readable etc. - why Harry is right
>
>
> If I recall correctly, Harry's approach was morphed into the
> not equivalent
> Get because it did not address the established "requirement" that IPP
> notification allow notification of recipients other that the client
> submitting the job and at the time that the client was
> submitting the job.
> The argument that third party notification and notification
> subscriptions
> were not necessary was not accepted for IPP in general, but
> may be quite
> valid for QualDocs. As such, this may be pursued in
> conjunction with the
> QualDocs definition.
>
> As suggested, the indicated objections to mail-to can be
> addressed, but I
> think this is a separate matter.
>
> William A. Wagner (Bill Wagner)
> Director of Technology
> Imaging Division
> NETsilicon, Inc.
> 781-398-4588
>
>
> -----Original Message-----
> From: pmoore@peerless.com [mailto:pmoore@peerless.com]
> Sent: Thursday, August 17, 2000 12:47 PM
> To: McDonald, Ira
> Cc: 'jkm@underscore.com'; McDonald, Ira; 'Harry Lewis/Boulder/IBM';
> ipp@pwg.org
> Subject: IPP> machine readable etc. - why Harry is right
>
>
>
>
> The more I listen to this debate the more Harry's proposal
> makes sense.
>
> INDP will have issues with firewalls; I dont beleive email is
> practical for
> a
> real solution (see footnote), this leaves Harry's 'honest its
> not polling'
> mechanism. The objection to Harry's mechanism (I apologize to
> the other
> authors
> but Harry is the one that sticks in my mind) that connections
> will close is
> not
> valid in most cases. instant messenger systems are based on long lived
> connections and proxies dont chop them off (mine certainly doesnt)
>
>
> PS
>
> Why isnt email practical.
>
> 1. Who will set up the mailbox for the client? Every client
> will need to
> have
> its own mailbox as well as the normal one for the human user.
> This doesnt
> seem
> like a 'drop in ' solution transparent to the net admins. It
> merely moves
> the
> hassle from the proxy admin to the email admin. The client
> cant have its own
> SMTP server since we are presupposing aggressive firewalls.
>
> 2. Email systems do not promise to deliver messages a) in
> order b) in a
> timely
> fashion. An email message that arrives 1 hour late is normal,
> what will a
> client
> do if it doesnt receive notification after 1 hour of success
> or failure?
>
> 3. Many people now use hotmail / yahoo style email systems
> where they read
> messages on a central server and never down load them. It is
> simply not
> possible
> to set up an email mailbox for these users that their client can read
> programmatically
>
> 4. Many home users have restricted email accounts from their
> ISPs. It costs
> money to get extra ones
>
> I am sure each objection could be addressed, but the point is
> that machine
> readable email is not a slam dunk. Sure we can put machine
> readable content
> in
> email messages but I am not sure that this will produce the
> solution we are
> looking for.
>
>
>
>
>
>
> "McDonald, Ira" <imcdonald@sharplabs.com> on 08/17/2000 09:20:20 AM
>
> To: "'jkm@underscore.com'" <jkm@underscore.com>, "McDonald, Ira"
> <imcdonald@sharplabs.com>
> cc: "'Harry Lewis/Boulder/IBM'" <harryl@us.ibm.com>,
> ipp@pwg.org (bcc:
> Paul
> Moore/AUCO/US)
>
> Subject: RE: IPP>NOT mailto feature from IETF meeting (RE:
> IPP> ADM - The
> IPP
> Notification I-Ds will now go the IESG)
>
>
>
> Hi Jay,
>
> PRIOR to Bob Herriot's latest proposal, ALL previous
> texts of the 'mailto:' delivery method for IPP
> Notifications have permitted the IPP Printer (or
> other notification generator) to insert machine-readable
> content at will - please read the documents.
>
> There has never been any concensus to completely
> remove the ability to send machine-readable with
> 'mailto:' and it's never been documented in any
> version of the working spec.
>
> Note that Adobe Acrobat Reader is NOT built by MS,
> Netscape or any other browser manufacturer. It's
> just a simple application reader utility. Among
> other useful goals, the current IPP Open Source
> Client activity could quite easily produce and
> freely distribute (like Acrobat Reader) this app.
>
> NOTHING at all has to be done by a browser
> manufacturer to enable this - it's just a new
> MIME type that is connected to a well-known app in
> the end user's environment when the end user
> installs the reader app.
>
> By the way, QualDocs is going to very badly need
> machine-readable IPP notifications over email or
> it's never going to work gracefully to extend the
> current IETF Internet Fax standards - they're all
> based on email notifications.
>
> Cheers,
> - Ira
>
> -----Original Message-----
> From: Jay Martin [mailto:jkm@underscore.com]
> Sent: Wednesday, August 16, 2000 1:31 PM
> To: McDonald, Ira
> Cc: 'Harry Lewis/Boulder/IBM'; ipp@pwg.org
> Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
> The IPP Notification I-Ds will now go the IESG)
>
>
> Ira,
>
> I find it quite discouraging to see that you continually side-step
> the issue of the likely lack of available client-side software to
> make this thing truly useful on a mass scale.
>
> Who's going to provide the client-side software? Microsoft?
> Netscape?
>
> Do you honestly believe this kind of capability is going to shoot
> adreneline through these major infrastructure component companies
> such that they're going to quickly add integrated support to their
> mail products?
>
> Recall that a very early premise of using HTTP for IPP was the
> significant expectation that Netscape would be there with the PWG,
> side-by-side, such that Netscape's products would have integrated
> support for IPP right in the browser. Well, that just didn't happen.
>
> How is this situation any different? Do you expect a company like
> Xerox or Sharp to bestow a free capability to the world to make the
> feature usable? Perhaps you expect this capability to represent some
> sort of "market builder" concept in which many companies will rush
> several competing products to market?
>
> The PWG always prided itself on being more business-oriented than
> other pure standards organizations (eg, the IETF, with all
> due respect).
> A standards effort is started because a concensus declares market
> viability. Moreover, the effort is scoped so that resulting products
> (free or otherwise) are developmentally possible within a reasonable
> period of time. And, above all, there is a clear and present benefit
> by delivering products that build on the standard.
>
> I (and others) have repeatedly stated that this is NOT the case with
> machine-readable notifications within email messages. Just because
> you CAN do something doesn't mean you SHOULD. (Deja vu all
> over again.)
>
>
> Please don't misunderstand me here. If someone wants to go off and
> submit a paper to the IETF and publish UNDER HIS/HER/THEIR names as
> an "Informational" protocol (or whatever the term that's used to
> denote a private research project), I have absolutely no problem with
> that (and, in fact, would encourage it).
>
> What I (and others) do NOT want is yet another long,
> drawn-out standards
> effort that gets fatter and Fatter and FATTER as time goes
> on, one that
> sucks up precious cycles from the PWG membership.
>
> And with that, I shall refrain from further responses on this subject
> unless explicitly asked (or targeted).
>
> ...jay
>
> PS: In spite of this discord, I hope you and Nancy are enjoying a fine
> Grand Marais summer! I wish Nancy the best with her
> gardening efforts.
>
>
> "McDonald, Ira" wrote:
> >
> > Hi Harry and Jay,
> >
> > I agree with MOST of Harry's points below - as I
> > never attended any of the PWG monthly meetings
> > (which, for a variety of procedural reasons are
> > NOT qualified as official meetings of the IETF IPP WG)
> > I wasn't around for this elusive decision to force
> > machine-readable out of email notifications.
> >
> > The utility of machine-readable has NO RELATIONSHIP
> > to whether notification is real-time or store/forward.
> > There is MUCH more usable content in machine-readable
> > for any client application. Doing printer-side
> > localization of more attributes in the human-readable
> > encoding just worsens interoperability. We (IPP WG)
> > don't standardize the translations of the thousands
> > of attribute names and attribute keyword and enum
> > tag values, do we?
> >
> > For what it's worth, I've got several implementation
> > teams interested in IPP notifications via SNMP using
> > the Job Mon MIB and all of them want to do email.
> > I haven't got any implementors interested in INDP,
> > because it causes so many headaches with security
> > policies on customer sites.
> >
> > Cheers,
> > - Ira McDonald
> >
> > -----Original Message-----
> > From: Harry Lewis/Boulder/IBM [mailto:harryl@us.ibm.com]
> > Sent: Wednesday, August 16, 2000 8:01 AM
> > To: jkm@underscore.com
> > Cc: imcdonald@sharplabs.com; ipp@pwg.org
> > Subject: Re: IPP>NOT mailto feature from IETF meeting (RE:
> IPP> ADM -
> > The IPP Notification I-Ds will now go the IESG)
> >
> > Jay asked for discussion.
> >
> > 1. This is a VERY old topic.
> > 2. I thought we agreed LONG ago the e-mail notification was
> for human
> > readable (only)
> > 3. I thought we agreed LONG ago that real time notification
> to a client or
> > "notification manager" application (i.e. machine readable)
> is desirable
> > 4. I've argued (and proposed) a LONG time ago that,
> fundamentally, we need
> > a simple, NATIVE machine readable method (i.e. works using
> the exact same
> > infrastructure, no more, no less, as IPP).
> > 5. Several additional machine readable methods have been
> proposed (INDP,
> > SNMP, ...).
> > 6. As diversity and choice are great in many context but
> not so great in
> > "standards"... a litany of events, discussions, meetings,
> phone calls and
> > e-mail have resulted in INDP as the recommended machine
> readable protocol.
> >
> > We currently just the Job MIB with SNMP notification
> (private - as the JMP
> > team would not allow the definition of Job Traps... now
> they are defined
> > for IPP... Odd!). Works fine. Yes, it's shown to be useful
> and desirable
> > when facilitating rich end-user job progress and status information.
> >
> > Harry Lewis
> > IBM Printing Systems
>
>
>
This archive was generated by hypermail 2b29 : Tue Aug 22 2000 - 01:03:12 EDT