At 14:51 01/09/1998 PST, Robert Herriot wrote:
>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.
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 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.
>> >
>>>>>>