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.
>