I agree. In other words, the "job-uri" attribute that comes back in any
response is one that the client receiving the response could use in
a Get-Job-Attributes operation, i.e., it has the same security URI
capabilities as the one that the client supplied in the request that is
returning the "job-uri" (if the implementation uses different URI schemes
for different security access).
This same statement needs to be made for the "containing-printer-uri"
job attribute as well. In other words, the "containing-printer-uri"
attribute that comes back in any response is one that the client
receiving the response could use in a Get-Printer-Attributes operation,
i.e., it has the same security URI capabilities as the one that the client
supplied in the request that is returning the "job-uri" (if the
implementation uses different URI schemes for different security access).
NOTE: All this discussion makes it even more desirable for an IPP object
implementor to use the same URI for TLS and non-TLS, to avoid having
to generate URIs on the fly for a response for the "job-uri" and
"containing-printer-uri".
BTW, this above detail may be too much detail to put into section
2.4 on object identity. It may best be put into the description
of the "job-uri" and "containing-printer-uri" attributes.
Tom
>
>Bob Herriot
>> From ipp-owner@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.
>> >
>>
>>
>
>