ISSUE 1
I agree that this operation is not mandatory, so I think it's a MAY.
ISSUE 2
Yes
ISSUE 3
Yes
ISSUE 4
I think there should be a new notification event, for moving a job. Just imagine
if you submit a job on one printer, wouldn't you like to know if the
administrator
has moved your job to another printer.
ISSUE 5
I think it should be in the 'Set Job and Printer' spec. I don't like to split it
up to
more documents. It's confusing for the implementers when we add more and more
documents.
Henrik
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 22-03-2000 03:02:00
To: ipp <ipp@pwg.org>
cc: (bcc: Henrik Holst/INT)
Subject: IPP> FW: Thoughts on the new Move-Job operation
Michael, Ira, Bob, and I have been exchanging email on the Move-Job
operation as a result of last week's IPP telecon. We have a few issues
left. But here is where we are for tomorrow's IPP telecon, 3/22.
The issues are listed.
Tom
-----Original Message-----
From: Hastings, Tom N
Sent: Friday, March 17, 2000 11:51
To: Sweet, Michael
Cc: 'Hastings, Tom'; Herriot, Bob; Zehler, Peter; Shepherd, Michael;
'McDonald, Ira at Sharp'; Manros, Carl-Uno B
Subject: Thoughts on the new Move-Job operation
Michael,
I'd like to add a few more semantics to the IPP Move-Job operation from you
starting point in your email below and wanted to get your reaction. If we
all agree, I'll crank out a complete proposal this Monday for this
Wednesday's telecon:
(As a comment, lets also agree that we can also have a fancy Resubmit-Job
operation sometime in the future, which causes a Printer to act like a
client and submit the job to any other Printer. So anyone who wants that
fancy stuff will NOT try to get it into our simple Move-Job operation, ok?
Then we can keep Move-Job simple.)
1. We need to agree for which job states the Move-Job MUST be accepted,
which ones it MAY be accepted and which states it MUST be rejected. I
propose:
'pending-held', 'pending' - MUST be accepted
'processing', 'completed', 'aborted', 'canceled' - MUST be rejected.
ISSUE 01: There is some debate as to whether to ALLOW the Move-Job
operation to be supported when the job is in the 'processing' state. If it
is allowed, it would be a MAY, not a MUST, because some systems will have
problems with accounting if the same job-id is reused for the job again if
some resources had been consumed.
2. In case the Printer defaults are different for the new Printer, we need
to specify that the new Printer's defaults will be used when the job is
processed, even if they differ from the defaults of the old Printer.
3. If the new Printer would reject the job, then the move returns an error
and the job remains unchanged on the old Printer.
4. Make the Move-Job operation request be as much like a Create-Job request
as possible, with the exception that the client MUST supply the "job-id"&old
"printer-uri" (or old "job-uri") and the new "printer-uri".
5. Which brings up the question of "ipp-attribute-fidelity". If an operator
moves the job, it would be good if the original fidelity were preserved. In
other words, if the user has submitted with fidelity 'true', the operator
should perform the move with 'true'. If the user has submitted the job with
fidelity 'false', then the operator should do the same. If the
"ipp-attribute-fidelity" is omitted in the Move-Job request, the Job's
original "ipp-attribute-fidelity" supplied in the Job Creation operation is
used. The Move-Job operation does not update the Job's
"ipp-attribute-fidelity" (in case another Move-Job operation is done, so
that the user's original intent is preserved).
ISSUE 02: Ok to REQUIRE that the "ipp-attribute-fidelity" operation
attribute be copied to the Job object, if the Move-Job operation is
supported?
6. Finally, do we want to make Move-Job be like the Job Creation operations
and specify that the Move-Job response MUST be the same as the Print-Job
response:
- MUST include the "job-uri", "job-id", "job-state" and "job-state-reasons"
- If supported, MUST include the "job-state-message" and
"number-of-intervening-jobs"
I suggest for consistency, that we make the Move-Job response be identical
to the Print-Job response. Ok?
7. Clarify that the implementation MAY change the "job-id" and/or the
"job-uri" and REQUIRE the "job-id" and "job-uri" to be returned in the
response, in case the implementation changes it. Always returning the
"job-id" makes it more like the Job Creation operations.
8. Add to the Notification Specification: Any Per-Job Subscriptions move
with the job. If the implementation does change the "job-id", then the
Subscription object is changed automatically.
ISSUE 03: Ok that Per-Job Subscriptions are automatically updated to be for
the new job (whether the job-id changes or not)?
9. Probably need to add a new Job event to the Notification Specification:
'job-moved' which has both the old and new job-ids in the notification
content, in case they are different.
ISSUE 04: Should there be a new 'job-moved' event or is moving a job, just
another operation that generates the 'job-created' (along with Print-Job,
Print-URI, and Create-Job)?
10. ISSUE 05: For all of us to consider:
Should we add this operation to the Set Job and Printer Spec (because it is
similar to scope and usage to the Set-Job-Attributes and
Set-Printer-Attribute spec), add it to the Administrative Set2 spec, or keep
it as a separate spec?
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-job-printer-set-ops-000308.pdf
We should add it if we are roughly in agreement, because we want the Set
spec to go out for last call soon (as soon as we agree on the collection
syntax encoding). On the other hand, if we are far from agreement on
Move-Job, we should keep it separate from the Set spec (and the Set2 spec).
Thanks,
Tom
-----Original Message-----
From: Manros, Carl-Uno B
Sent: Friday, March 17, 2000 11:09
To: Hastings, Tom; McDonald, Ira at Sharp
Subject: FW: Your Set-Printer-Attributes operation
FYI,
Carl-Uno
-----Original Message-----
From: Michael Sweet [mailto:mike@easysw.com]
Sent: Friday, March 17, 2000 11:00 AM
To: Manros, Carl-Uno B
Subject: Re: Your Set-Printer-Attributes operation
[geez, I need to clone myself or something... I *did* plan on
calling in for the phone conf. but was called away at the last
minute...]
"Manros, Carl-Uno B" wrote:
> ...
> Everybody on the call agreed that it was too much of a hack to let
> the modification of the Printer-URI have the side effects associated
> with moving the job to another printer, and were agreed to try to
> convince you that it is a bad idea.
:)
> As an alternative, if we helped you to quickly spec up a new
> operation to achieve what you need, in what we consider a more
> professional way, would you be willing and able to change your
> implementation?
Yes. My main concerns were that a) there wasn't any alternate in the
works, and b) we didn't want to create yet another CUPS-specific
extension if we didn't have to.
> This is not a new problem to several members of the group, so we
> should be able to put together a new better solution in a matter of
> weeks (even though it will take a lot longer to get it through the
> whole formal IETF process afterwards).
>
> Would you be open to solving the problem that way?
Sure. In the meantime I'll be updating our IPP implementation
document for a new "CUPS-Move-Job" operation, and then maybe we
can wrap that operation in the appropriate IETF language/format
for the formal extension proposal.
Quick outline of the new operation:
CUPS-Move-Job Request
attributes-charset
attributes-natural-language
job-uri *or* printer-uri + job-id
requesting-user-name (optional, "SHOULD")
job-printer-uri
CUPS-Move-Job Response
attributes-charset
attributes-natural-language
Possible errors: successful-ok, client-error-not-found,
client-error-not-possible,
client-error-forbidden
Of course, there are things such as unsupported attributes or
document formats we need to deal with for the general IPP
implementation (not generally an issue for CUPS), but that's
what we're planning on implementing for CUPS...
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Wed Mar 22 2000 - 03:55:38 EST