IPP Mail Archive: Re: RE: RE: RE: IPP> Identifying jobs in requests

Re: RE: RE: RE: IPP> Identifying jobs in requests

Carl Kugler (kugler@us.ibm.com)
9 Jun 1998 23:44:31 -0000

Paul Moore wrote:
>
> >
> > > I think that there is a difference between meta-level things like
> > charset
> > > and language and real attributes like job-id.
> > >
> > > I think we should pull all URIs from the IPP model. The only place they
> > > should appear in in the (non-existant) 'IPP on HTTP implementation
> > rules'.
> >
> > That's a bigger change that what I'm proposing. I'm for leaving them in
> > responses, to indicate printer-uri-supported, uri-security-supported,
> > job-uri, job-printer-uri, and for print by reference. In a response
> > you're supplying a reference to be used as a target in future operations.
> > That's different than telling the target what the target is, which is what
> > happens when we embed targets in requests.
> [Paul Moore] Actually telling the target what the target is not the
> main issue (it is , I agree, redundant). In fact my understanding is that
> the printer-URI is not sent as an attribute in , say, a createjob request.

Currently, "printer-uri" is a MANDATORY Operation Attribute of the Create-Job operation (see section 15.3.4.3 Validate the presence of a single occurrence of required Operation attributes).

> Rather the URI is implicit in the request (since the command arrives at the
> right place). The real issue is that the reference generated by the printer
> (job-URI) must make sense in the address space of the client (so that it can
> use it). This works well for some adressing schemes but not for others.
> > >
> > > This is the only way we can make transport independance work
> >
> > Uniform Resource Identifiers (URI) can be used on many different
> > transports (though not all transports). But IPP is the Internet Printing
> > Protocol, so I think identifying resources by network location (URL) is
> > reasonable.
> [Paul Moore] Aha - so you are in the 'let there be IPP for Internet
> and something else for other scenarios' camp. There is also, I am sure you
> are aware, the 'IPP is just a convenient name, lets use it on all
> transports' camp.

Well, there's also the PWG's Server to Device Protocol (SDP) to cover another class of transports.

> > >
>
>