Ok, so we have these actual document attributes that we could admittedly move
into "job document attributes" just to save us the work this time of actually doing
the work to support document attributes. This might be
problematic for future implementations that actually *DO* the
document attribute model correctly, having to be backward-compatible
with our "hacked" version of document attributes of IPP 1.0.
I thought maybe we could allow a placeholder in the model/protocol for
V 1.0 for document attributes, so that we could easily integrate this in
the future with very little work.
Concerning the "job-document-attribute" proposal...
I'm assuming that the send-document operation allows these "job-document"
attributes to be included (I can't remember the send-document specifics from the
Ira Mcdonald x10962 wrote:
> Hi Randy,
>> I think we agreed that JOBs could have descriptive attributes
> (either single- or multi-valued??) about the associated
> document(s), which apply unless (in a future version of IPP)
> they are overridden at the (future) DOCUMENT object level.
>> I speculate that the following JOB level attributes are
> necessary or desirable in IPP 1.0:
> [job]document-URI (to support Send-URI)
> - Ira McDonald (outside consultant at Xerox)
> High North In