> Reading draft-ietf-ipp-model-v11-0201.txt, section 3.2.2, "Print-URI
> Operation", it looks like it's an implementation decision whether to pull
> the data from the document-uri at job submission time or at job
processing
> time. Say I decide to pull the data at job submission time. Say I get
> some kind of error doing so, like no-route-to-host, or HTTP 404.
Shouldn't
> I return some kind of error status? Currently, it looks like I have to
> return successful-ok as long as the "document-uri" uses a scheme I
support,
> regardless of whether or not I can actually get the document data.
>> -Carl
>
Let's consider the flip side and say I don't try to pull the document data
until job processing time (could be hours or days after job submission
time). Again, suppose I encounter some problem like unknown-hostname,
no-route-to-host, or HTTP 404. What are the appropriate "job-state" and
"job-state-reasons"? From section 4.3.7, it looks like the answer is
'aborted', 'aborted-by-system', which doesn't give the client much to go on
for understanding why the job failed. Even the "job-state-message"
attribute is restricted from containing additional information not
contained in the "job-state" and "job-state-reasons" attributes.
-Carl