Tom
At 11:25 05/21/97 PDT, Scott Isaacson wrote:
>
> 4. Reminder that the Model document still includes concepts
> that are not to be implemented in v1.0 of the protocol.
What concepts are these?
Shouldn't they either be labeled as beyound V1.0 or removed?
> 14. All "name", "text", and "fileName" attributes are
> defined as characters in the Model document. This leaves
> open the option of Unicode or other DBCS in the actual
> protocol.
Why can't we specify UTF8 (not Unicode) in the Model document as the
coded character set for values? Then we avoid a lot of messy coded
character set mapping rules in the encoding and protocol documents.
Believe me coded character set mapping is very hard! Most character sets
don't have all the same characters, and/or have over lapping characters.
Lets avoid character set mapping altogether in our documents.
We specify USASCII for the attribute name keywords in the model document,
why not specify UTF8 as well (and follow the recommendations of the IETF here).
>
> 15. Reaffirmed that keywords must start with a character (no
> digits)
You mean no leading digits; embeded digits are ok, correct?
So need to change the values for the "sides" attribute which are: '1-sided',
'2-sided-long-edge', and '2-sided-short-edge'.
How about 'one-sided', 'two-sided-long-edge', and 'two-sided-short-edge'.
Also the values of the "number-up" attribute which are: '1', '2', and '4'.
Two alternative: 'one-up', 'two-up', 'four-up'.
Or actual integers, but the number-up-supported would be a setOf Integer.
Then there would be no need to register additional values.
Perhaps we'd need to introduce a new datatype: integerMember for the job
attribute, so that we could continue an algorithmic mapping from the data
type of the job attribute to the data type of the xxx-supported, which in this
case would be integerMember to 1SetOf Integer.
> 17. We had a 3 hour discussion on best-effort. The final
> proposal was to do away with any notion of "substitute"
> values when there is a conflict between what is requested
> and what is supported. The expectation is that if a client
> specifies something and it is not supported, return an error
> so that the client can query what is supported. best-effort
> will now apply to only conflicts between IPP attributes and
> what is in the document stream (PDL) itself. Proposed
> values are: SHALL_HONOR_IPP_ATTR (IPP attribute values take
> precedence over PDL instructions), SHOULD_HONOR_IPP_ATTR
> (same as SHALL with no guarantees), and
> NEED_NOT_HONOR_IPP_ATTR (PDL takes precedence over IPP
> attributes).
Just a nit, but so far keywords have been all lower case with hyphens, except
for acronyms, so here too. Also we have been using full words, so how about:
'shall-honor-IPP-attributes', 'should-honor-IPP-attributes',
'need-not-honor-IPPP-attributes'?
> 18. Clarified that defaults are not overrides. What does a
> user intend when the user does not specify an attribute:
> either 1) They want the admin default, 2) They want the
> PDL default. In either case, they really don't know or
> care, they really care if they specify the value. The idea
> of "default behavior" will be removed from the Model
> document. It is not possible to specify a consistent
> default behavior for features that are not implemented or
> for extensions that are yet to be added.
>
> 19. When a Job object is created only supplied attributes
> will be copied from the request into the Job object. In
> order to determine the defaults that will be applied, query
> the Printer Job Template attributes to get defaults.
We need to clarify in the above that:
The Printer object applies the default values when there is no value supplied by
either the client in the IPP protocol or by the document in the PDL.
Presumably when the Printer object applies the defaults is implementation
dependent. Some implementations for some attributes may scan the PDL at job
submission time, shortly thereafter, or just before processing. Some
implementations may wait until during interpretation of the PDL. Some
implementations may set the output device to the default values just prior
to sending the document PDL to the output device. If the PDL changes the
output device, the PDL overrode the defaults.
> 24. Moved to make all time related attributes relative to
> job submission (not absolute time). That is "job-sumission-
> time" moves to "time-since-submitted". There was also a
> discussion about having "time-since-xxx" attributes for each
> of the Job state transitions (pending to processing,
> processing to completed). I did not capture the final
> decision on this. These are mandatory
Processing to completed is what we already have in the "completion-time"
attribute, so its not new.
I think that we did not agree to add "time-since-processing" on the grounds
that that is an attribute in the Job Monitoring MIB for accounting and
system utilization, so we didn't need to add it to IPP, since IPP isn't
for accounting and utilization analysis.
I think we agreed to change the "completion-time" attribute to
"time-since-completion" to follow the "submission-time" change to
"time-since-submission".
This gets rid of the difficult dateTime data type.
My notes said the units were milliseconds. But wouldn't seconds be
sufficient?
Nit: should they both be "time-since-submitted" and "time-since-completed" or
"time-since-submision" and "time-since-completion"?
[The attribute table that I sent you had the latter]
> 27. We had a discussion on using MIME registered types as
> document-format values. I didn't capture a final decision
> on this issue.
My recollection was that we decided to go with MIME registered types,
insted of the Printer MIB and Job Monitoring MIB Interpreter Language
Family enums. However, this means that our Printer MIB and Job Monitoring
MIB are different from IPP (so there may be other members of PWG that
disagree with this decision made in the Modeling sub-group of IPP).
> 7. Define SHALL and SHOULD get rid of NEED_NOT
> Who: Scott
Why get rid of "need not"? It needed when the standard has to say that an
implementor does not need to do something. Its too confusing to say
"may not", since it sounds like a prohibition, rather than a relaxation
of requirements. POSIX and ISO standards are quite clear on this terminology.
You even have the value for best-effort with the 'need-not'
value?
On the other hand, when you find the RFC for IETF conformance
terminology, they may have covered this point.
> 8. Create a table of attributes
> Who: Tom
Done and sent to Scott, 5/20/97. Scott said he'd post after reviewing
it for accuracy and comparison with his notes.