FYI
I had promised to get the new model document done by today, Friday (1/9),
however, as has been pointed out by these messages from Tom and Bob, there
is more extensive editing here (more than I thought). I will be delayed by
a few days.....
Which just goes to show that a little tweek can take up a lot of time these
days...
Scott
>>> Robert Herriot <Robert.Herriot at Eng.Sun.COM> 01/09 3:51 PM >>>
You email reminds me of another ambiguously defined attribute.
If a printer has several URI's, we have already said that the job
attribute containing printer should be the printer uri that is "useful"
for the client and may be different from the one to which the job was
submitted.
But with GetJobs, what is printer-uri part of the job-uri for each job
if the job-uri consists of the printer uri and a job-identifier? Is
the printer-uri part the original printer-uri to which the job was
submitted or the one that would come back with 'containing-printer". I
favor the latter.
Bob Herriot
> From ipp-owner at pwg.org Fri Jan 9 08:51:59 1998
>> At the telecon last Wednesday, we agreed to change the Printer object's
> single-valued "printer-uri" attribute to a multi-valued
> "printer-uri-supported" attribute. And keep the single-valued
"printer-uri"
> operation attribute for use in operation requests and responses.
>> This note looks at the first section affected by this change to show
> the impact. I think this is a good change, but it does require a lot
> of careful re-work of the wording. Here is an attempt:
>> Now Printer objects can be identified by one or more URIs, but jobs remain
> with a single URI. However, each Printer object is still uniquely
> identified by each of its URIs, if it has more than one URI.
>> We also need to be careful to distinguish between the concept of a Printer
URI
> and the "printer-uri" operation attribute. The former is always two
> separate words (with Printer and URI capitalized) and the latter is
> a single hyphenated word with double quotes and all lower case.
>> We need to fix section 2.4 and other parts of the document accordingly.
>> Also we have to be careful, since the Printer object now has the renamed
> multi-valued: "printer-uri-supported" attribute. It no longer has the
> same name as the single-valued "printer-uri" operation attribute. So we
have
> to be careful to update the document each time we mention "printer-uri"
> to make sure that is is refering to the "printer-uri" operation attribute
> or the "printer-uri-supported" Printer object attribute. In some places,
> we might be even talking about both, and so need to change the single
> mention of "printer-uri" attribute to "printer-uri" operation attribute
> and "printer-uri-supported" Printer attribute.
>> For example of the changes, here is section 2.4 on object identity
> with possible changes (we can't talk about the "printer-uri" operation
> attribute yet, since operations are described later):
>> >2.4 Object Identity
> >
> >All Printer and Job objects are identified by an identifier so that they
> >can be persistently and unambiguously referenced. The IPP/1.0 model
> >requires that these identifiers be Uniform Resource Identifiers (URIs)
> >[RFC1630]. Often, the URI is a URL [RFC1738] [RFC1808].
>> I suggest adding to the end of the paragraph above:
>> A Printer object MAY have one or more identifies that uniquely identify
> the Printer object, depending on implementation. These Printer URIs
> are contained in the Printer object's potentially multi-valued
> "printer-uri-supported" attribute. Job objects SHALL have
> only one unique identifier. This Job URI is contained in the Job object's
> "job-uri" attribute.
>> >
> >IPP/1.0 does not specify how the URI is obtained, but it is RECOMMENDED
> >that a Printer object is registered in a directory service which end
users
> >and programs can interrogate. Section 16 defines a generic schema for
> >Printer object entries in the directory service.
> >
> >Allowing Job objects to have URIs allows for flexibility and scalability.
> >In some implementations, the Printer object might create Jobs that are
> >processed in the same local environment as the Printer object itself. In
> >this case, the Job URI might just be a composition of the Printer's URI
and
> >some unique component for the Job object, such as the unique 32-bit
> >positive integer mentioned later in this paragraph. In other
> >implementations, the Printer object might be a central clearing-house for
> >validating all Job object creation requests, and the Job object itself
> >might be created in some environment that is remote from the Printer
> >object. In this case, the Job object's URI may have no relationship at
all
> >to the Printer object's URI. However, many existing printing systems have
> >local models or interface constraints that force Job objects to be
> >identified using only a 32-bit positive integer rather than a URI. This
> >numeric Job ID is only unique within the context of the Printer object to
> >which the create request was originally submitted. In order to allow
both
> >types of client access to Jobs (either by Job URI or by numeric Job ID),
> >when the Printer object successfully processes a create request and
creates
> >a new Job, the Printer object SHALL generate both a Job URI and a Job ID
> >for the new Job object. This requirement allows all clients to access
> >Printer objects and Job objects no matter the local constraints imposed
on
> >the client implementation.
>> In order to fix the paragraph above, we need to introduce the concept that
> a create operation specifies a single Printer URI, without introducing the
> concept of operation attributes yet. I suggest adding a preceding
paragraph:
>> When a job is submitted to the Printer object, the client MUST supply a
> single Printer URI which is one of the URIs that uniquely identify that
> Printer object and is one of the values in that Printer object's
> "printer-uri-supported" attribute.
>> Then the long paragraph above can be fixed by replacing
> "Printer's URI" and "Printer object's URI" with "Printer URI supplied
> by the client when submitting the job" yielding:
>> Allowing Job objects to have URIs allows for flexibility and scalability.
> In some implementations, the Printer object might create Jobs that are
> processed in the same local environment as the Printer object itself. In
> this case, the Job URI might just be a composition of the
> Printer URI supplied by the client when submitting the job
> and some unique component for the Job object, such as the unique 32-bit
> positive integer mentioned later in this paragraph. In other
> implementations, the Printer object might be a central clearing-house for
> validating all Job object creation requests, and the Job object itself
> might be created in some environment that is remote from the Printer
> object. In this case, the Job object's URI may have no relationship at
all
> to the
> Printer URI supplied by the client when submitting the job.
> However, many existing printing systems have
> local models or interface constraints that force Job objects to be
> identified using only a 32-bit positive integer rather than a URI. This
> numeric Job ID is only unique within the context of the Printer object to
> which the create request was originally submitted. In order to allow both
> types of client access to Jobs (either by Job URI or by numeric Job ID),
> when the Printer object successfully processes a create request and
creates
> a new Job, the Printer object SHALL generate both a Job URI and a Job ID
> for the new Job object. This requirement allows all clients to access
> Printer objects and Job objects no matter the local constraints imposed on
> the client implementation.
>>> >
> >In addition to a unique identifier, Printer objects and Job objects have
> >names. An object name need not be unique across all instances of all
> >objects. A Printer object's name is chosen and set by an administrator
> >through some mechanism outside the scope of IPP/1.0. A Job object's name
> >is optionally chosen and supplied by the IPP client submitting the job.
If
> >the client does not supply a Job object name, the Printer object
generates
> >a name for the new Job object. In all cases, the name only has local
> >meaning; the name is not constrained to be unique.
>> Probably just replace "a unique identifier" with "unique identifiers"
> in the first sentence in the paragraph above.
>> >
> >To summarize:
> >
> >- Each Printer object is uniquely identified with a URI. The Printer's
> >"printer-uri" attribute contains the URI.
>> Change the paragraph to:
>> - Each Printer object is identified by one or more unique URIs. The
> Printer's multi-valued "printer-uri-supported" attribute contains these
URIs.
>> >
> >- Each Job object is uniquely identified with a URI. The Job's "job-uri"
> >attribute contains the URI.
> >
> >- Each Job object is also uniquely identified with a combination of the
URI
> >of the Printer object to which the create request was originally
submitted
> >along with a Job ID (a 32-bit, positive integer) that is unique within
the
> >context of that Printer object. The Printer object's "printer-uri"
> >contains the Printer URI. The Job object's "job-id" attribute contains
the
> >numeric Job ID.
>> In order to fix this paragraph, we need to introduce the concept that
> a create operation specifies a single Printer URI, without introducing the
> concept of operation attributes yet. Also we can introduce the
> "containing-printer-uri" attribute, since it is a connection between
> the Job object and the Printer object. I suggest re-writing the paragraph
> as:
>> - When a job is submitted, the client MUST supply a single Printer URI
> which is one of the URIs that uniquely identify the Printer object and
> is one of the values in the Printer's "printer-uri-supported" attribute.
> Each Job object is also uniquely identified with a combination of the
> Printer URI supplied in the original create request along with a Job ID
> (a 32-bit, positive integer) that is unique within the context of that
> Printer object. The Printer object's "containing-printer-uri" contains
> the Printer URI supplied in the create request. The Job object's "job-id"
> attribute contains the numeric Job ID.
>>> >
> >- Each Printer object has a name (which is not necessarily unique). The
> >administrator chooses and sets this name through some mechanism outside
the
> >scope of IPP/1.0 itself. The Printer object's "printer-name" attribute
> >contains the name.
> >
> >- Each Job object has a name (which is not necessarily unique). The
client
> >optionally supplies this name in the create request. If the client does
> >not supply this name, the Printer object generates a name for the Job
> >object. The Job object's "job-name" attribute contains the name.
> >
>>