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

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

Carl Kugler (kugler@us.ibm.com)
9 Jun 1998 22:12:51 -0000

> 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.

>
> 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.

>
>
> > -----Original Message-----
> > From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM]
> > Sent: Monday, June 08, 1998 1:24 PM
> > To: Paul Moore; 'Robert Herriot'; 'Carl Kugler'; ipp@pwg.org
> > Subject: RE: RE: IPP> Identifying jobs in requests
> >
> > Charset clearly needs to be at the beginning so that a receiving process
> > knows how to decode string fields before it encounters any of them.  The
> > charset field is a string field, but the names are all ASCII so the
> > decoding
> > need not be known for the class of encodings that IPP support. BTW, XML
> > puts
> > charset at the beginning for the same reason.
> >
> > Natural language is the next most important value because it specifies the
> >
> > language of any text or name field.  Processing is easier if the implicit
> > language is known at the time a text or name field is encountered. XML has
> >
> > similar rules for language.
> >
> > The printer-uri/job-uri/job-id should be easy to find if it not in the
> > enclosing layer.  For HTTP, the position of the target isn't important
> > because the target is redundant. The position would be important for a
> > transport where the target is specified only in IPP layer.
> >
> > So that's the reasoning. Do you agree?
> >
> > Bob Herriot
> >
> > At 11:42 AM 6/8/98 , Paul Moore wrote:
> > >I obviously missed this one. So 'special position' means that literally.
> > I
> > >thought it mean 'special purpose'.
> > >
> > >For my interest. Why are we putting things in special positions?
> > >
> > >> -----Original Message-----
> > >> From:        Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM]
> > >> Sent:        Friday, June 05, 1998 8:46 PM
> > >> To:  Paul Moore; 'Carl Kugler'; ipp@pwg.org
> > >> Subject:     RE: RE: IPP> Identifying jobs in requests
> > >>
> > >> We agreed recently that the following operation attributes would be
> > >> ordered.
> > >>     attributes-charset (always first for requests and responses)
> > >>     attributes-natural-language (always second for requests and
> > response)
> > >>     printer-uri or job-uri (always third for requests, though we are
> > >> discusses whether it should be present)
> > >>     job-id (always fourth for requests if present )
> > >>
> > >> At 05:00 PM 6/5/98 , Paul Moore wrote:
> > >> >       I think we are approaching group consensus on this.  I propose
> > >> that
> > >> >we remove "printer-uri" and "job-uri" as request Operation attributes,
> > >> but
> > >> >leave them in their special position in the protocol. 
> > >> >
> > >> >       [Paul Moore]  What 'special position'?
> > >> >
> > >>
> > >
> >
>
>