IPP Mail Archive: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs?

Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs?

Tom Hastings (hastings@cp10.es.xerox.com)
Tue, 9 Sep 1997 18:23:53 PDT

At 14:10 09/09/97 PDT, Robert Herriot wrote:
>
>> From walker@dazel.com Tue Sep 9 13:53:49 1997
>>
>> > Can you give a few details? Do you maintain a mapping table? If so,
>> > what triggers the removal of entries? Or do you use an extended attribute
>> > in the print job to hold the mapping?
>>
>> Uhhh... I believe that I will leave it as an exercise for the user.
>> Let's just say that there is a variety of ways that one might do it;
>> certainly either of the solutions that you hint to above might work.
>> I could even imagine one or two more.
>>
>> I do not mean to be too mysterious, but it seems sufficient to me
>> that there are implementations in the field today that solve a
>> similar problem.
>>
>
>I ask these questions because the two most obvious solutions that I cite
>above have problems in the IPP context.
>
>The gateway cannot use some extended attribute to store the LPD Job-Id in
>because an IPP server would discard attributes it doesn't support.

Well, we certainly could add a "job-client-id" attribute to IPP, so that
gateways would have a place to store an opaque "handle" in an IPP job.
That seems a simple solution to help gateways and is something we
have in DPA as the "job-client-id" and the Job MIB as the jobSubmissionID
table which is a map from the client's id to the server's jmJobIndex.

>
>The gateway has difficulty using a mapping table because the IPP
>notification is weak (email only). A gateway would have to resort to
>polling in order to determine what jobs can be removed from its mapping
>table. This works, but its not a nice solution, and it doesn't scale
>well.

The current Model document has more than 'mailto' scheme. It has 'http'
and 'ftp'. (Where is SENSE when we need it?). I agree that polling isn't
a nice solution, but lets make notification work.

>
>I assume that DAZEL doesn't have these restrictions.
>
>Bob Herriot
>
>