Subject: Re: IPP> HTTP transport for IPP

From: Roger K Debry <[email-masked]>
Date: Fri, 11 Apr 1997 10:11:25 -0400

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

I also prefer one URL!

Although admin functions are not part of the current version of IPP, we clearly
should not do something now that would make admin functions added later more
difficult.

I think that an end user ought to see and think about TWO objects, the printer
and the print job.  That's simple and easy to understand. Presenting the user
with multiple URLs  ( the underlying client system can't be guaranteed to
completely hide these from the user -- especially in the browser case) seems
absolutely wrong to me.

It ssems to me that Randy indicated that scalability was the main reason for
returning 3 URLs, but this seems an artifact of using HTTP and the way that a
web server works.  If we did not use HTTP, would this still be Randy's
solution???
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 04/11/97 07:49
AM ---------------------------

        ipp-owner @ pwg.org
        04/10/97 01:20 PM

To: Harry Lewis/Boulder/IBM, ipp @ pwg.org@internet
cc:
Subject: Re: IPP> HTTP transport for IPP

> From [email-masked] Wed Apr  9 15:45:34 1997

> 1. The idea of returning 3 URL (Data, Status, Modify) upon job submission is
an > excellent means of facilitating end-user job status and ability to cancel
one's > job. However, sometimes there may be an administrative application that
wants > to modify jobs. Unless this application had also received the Modify
URL, it > would be unable to cancel or modify jobs in the "IPP queue". > > I
think this might be accomplished by a QUERY to the "root" IPP service URL >
which would return a list of currently active and pending print jobs. It would >
be crucial that, included with this list would be the Modify URLs. Note there >
may need to be some authentication regarding who gets these. > >

I think that I understand the reasons for having 3 URLs returned, but
I still keep thinking that 1 job URL would be better and simpler.

Harry's example above reminds me of this problem when he mentions that
the list of jobs returned should include at least two job URLs for each job
(i.e. the query url and the modify url).

We may also decide to add more URLs later and have different URLs for
cancel and for modify, giving us 4 job urls.

Does anyone else think that we should strive for one job URL, and have
the operation specified in the message, or am I alone?

Bob Herriot

---

From: Randy Turner <[email-masked]>
Date: Fri, 11 Apr 1997 09:33:06 -0700

> should not do something now that would make admin functions added later more

I agree. So far, I don't see admin extensions as a problem.

> completely hide these from the user -- especially in the browser case) seems

Actually, in a true client situation, the end-user never sees URLs, in
fact, he
doesn't even have to know the term 'URL'. And in the browser case, using 
multiple URL strings with CGI parameters as HTTP POST targets is the
natural
way to encode IPP operations. 

> web server works.  If we did not use HTTP, would this still be Randy's

Yes, my solution for returning multiple URLs is predicated on the fact
that we
are using URLs as object identifiers. According to the model document,
we have
decided to use URLs independent of the underlying transport layer. I
would
propose the same solution for any transport.

In my opinion, funneling everything through 1 URL is too monolithic a
solution
when we have the flexibility of URLs as object identifiers.

By the way, when people talk about 1 URL, are you talking about 1 URL in
the
directory service for each printer? and that all IPP operations for this
printer are to be directed towards this URL?

Randy

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
[email-masked]