By the way, concerning Paul's earlier comment about proxies being the
issue, I'm assuming that if we make NO changes to the current specs, that
proxies are NOT an issue. Proxies rang the warning bell when it was
suggested we mandate other port numbers and/or HTTP methods. Is this not
the case?
Randy
----------
> From: Carl Kugler <kugler@us.ibm.com>
> To: ipp@pwg.org
> Subject: Re: IPP> Identifying jobs in requests
> Date: Tuesday, June 02, 1998 4:50 PM
>
> I agreee with Scott in "URLs within IPP operations",
> http://www.findmail.com/list/ipp/3695.html
> that it as a bad idea to embed "printer-uri" in the ipp message body. I
went back through the archives to see why "printer-uri" was added to IPP in
the first place.
>
> > I think that we are finally getting to the heart of this issue, namely
> > that the protocol currently puts the URI of the operation's target
object
> > in the Request-Line of the HTTP operation, and it is not in the
> > application/ipp message body.
> >
> > I think that I am hearing both Randy and Paul say that they think that
> > the target job or printer URI should be a parameter in the
application/ipp
> > message body. Am I right in my understanding?
> >
> > Bob Herriot
>
> I think this is actually a bit of a jump from the original proposal in
> "Identifying jobs in requests",
> http://www.findmail.com/list/ipp/1700.html
> which only asked for an embedded Job identifier, not an embedded Printer
identifier, with the rationale that in some implementations a Job is not
directly addressable and must be accessed through its containing Printer.
>
> If we accept that Printers are always directly addressable, then there's
no reason to put the target printer-uri in the application/ipp message
body.
>
> -Carl
>
> >
> > > From rturner@sharplabs.com Thu Jul 17 17:35:23 1997
> > >
> > > Paul Moore wrote:
> > >
> > > > Not the issue. I do not object to using URI as job identifiers - I
> > > > object to not giving the job identifier in a job specifc request.
> > > >
> > > > To restate - when I do a canceljob operation I do not supply a job
> > > > identifier - the target job is implicit in the transport endpoint -
> > > > this
> > > > ties us to a transport.
> > >
> > > Ok, I think we're in violent agreement here....I agree that the
> > > operandsof an IPP operation should not be implied by any
transport-level
> > > information;
> > > especially if we plan on moving IPP to other transports...
> > >
> > > Randy
> > >
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Randy Turner [SMTP:rturner@sharplabs.com]
> > > > > Sent: Thursday, July 17, 1997 5:05 PM
> > > > > To: Paul Moore
> > > > > Cc: 'JK Martin'; ipp@pwg.org
> > > > > Subject: Re: IPP> Identifying jobs in requests
> > > > >
> > > > > Paul Moore wrote:
> > > > >
> > > > > > I mean that not using jobids at all (which is what we do at
> > > > present)
> > > > > > ties us to HTTP.
> > > > >
> > > > > In the model document, job identifiers are URLs. If we have
pushed
> > > > > URLs
> > > > > out of themain body of the protocol up into the transport layer,
> > > > then
> > > > > this is a mistake. Job identifiers
> > > > > belong within the application/ipp body, and, according to the
model
> > > > > document, object
> > > > > identifiers are in URL format. Also, the use of URL/URI strings
as
> > > > > object identifiers in
> > > > > and of itself does not tie us to any one transport mechanism.
> > > > >
> > > > > Randy
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > In the current model a cancel job is done by posting a cancel
> > > > > > operation
> > > > > > to the job URL. No job id is sent, it is implied in the
transport
> > > > > > endpoint.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: JK Martin [SMTP:jkm@underscore.com]
> > > > > > > Sent: Thursday, July 17, 1997 1:45 PM
> > > > > > > To: Paul Moore
> > > > > > > Cc: ipp@pwg.org
> > > > > > > Subject: RE: IPP> Identifying jobs in requests
> > > > > > >
> > > > > > > > also using URLs to imply the job id means that we are tied
to
> > > > a
> > > > > > > specific
> > > > > > > > transport - something we tried to avoid. If we were to use
,
> > > > > say,
> > > > > > > raw IP
> > > > > > > > then you would need to assign an IP port to each job or
> > > > > something
> > > > > > > like
> > > > > > > > that.
> > > > > > >
> > > > > > >
> > > > > > > Is this really true? Do you mean we would be tying ourselves
to
> > > >
> > > > > > HTTP
> > > > > > > by using a URL as a job ID?
> > > > > > >
> > > > > > > It would seem that just because we choose the use the syntax
and
> > > >
> > > > > > > semantics of a URL doesn't mean we necessarily tie ourselves
to
> > > > > > HTTP,
> > > > > > > right?
> > > > > > >
> > > > > > > ...jay
> > > > >
> > > > >
> > >
> > >
> > >
> > >
> >
> >
> > ----- End Included Message -----
> >
> >
> >