Roger K Debry wrote:
>> Classification:
> Prologue:
> Epilogue: Roger K deBry
> Senior Techncial Staff Member
> Architecture and Technology
> IBM Printing Systems
> email: rdebry at us.ibm.com> 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 agree. So far, I don't see admin extensions as a problem.
>> 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.
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.
>> 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???
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
> ---------------------- 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 at internet> cc:
> Subject: Re: IPP> HTTP transport for IPP
>> > From harryl at us.ibm.com 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
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com