Thanks for editing the IPP model and semantics spec and your response.
My response noted inline as KC>>
Keith
To: Keith Carter
cc:
From: DELEGATE @ AUSVMR
Date: 02-20-97 08:23:52 PM
Subject: RE: IPP> MOD - COMMENTS ON VERSION 1.3 OF MODEL AND SEMANTICS
SPE
To: KCARTER --AUSNOTES
From: DELEGATE
Subject: RE: IPP> MOD - COMMENTS ON VERSION 1.3 OF MODEL AND SEMANTICS SPE
+--------------------------------------------------------------------------+
H The following note is being forwarded from KCARTER at AUSVMR. H
H DO NOT USE the F6 REPLY function to reply to this note. You must H
H contact the sender directly if you wish to reply, and not DELEGATE. H
+--------------------------------------------------------------------------+
---------------------------- Note: -------------------------------------
Received: from lists.underscore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with
Thu, 20 Feb 97 21:21:04 EST
Received: from localhost (daemon@localhost) by lists.underscore.com
(8.7.5/8.7
Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Feb 1997 21:19:34 -0500
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id
VAA
Date: Thu, 20 Feb 1997 18:17:04 -0800
From: Robert.Herriot@Eng.Sun.COM (Robert Herriot)
Message-Id: <199702210217.SAA16024@woden.eng.sun.com>
To: ipp@pwg.org, Keith_Carter@aussmtp.austin.ibm.com
Subject: Re: IPP> MOD - Comments on version 1.3 of Model and Semantics spec
X-Sun-Charset: US-ASCII
Sender: ipp-owner@pwg.org
I have incorporate most of your comments, as well as those from
Roger and Tom. I will put a new version 1.31 out on the Web tonight.
But here are comments for ones I didn't put in the new version.
> From Keith_Carter@aussmtp.austin.ibm.com Thu Feb 20 13:41:02 1997
>
> 8. Section 5.3.2.1. notification-events. Page 22. Line
> 690.
>
> Here is an idea. It is possible that an end-user's job
> might be held or resubmitted outside the context of IPP
> 1.0. The spec could add support for "job-held" and
> "job-resubmitted" notification events or else indicate
> that these are implicit ala "job-cancelled". Opinions?
I see job-held as a job-state-reasons and not a job-state value.
It is not currently in the document because there is no way to
change its value. We have not specified whether there is a job-held
attribute or a hold/release operation.
We have not addressed whether such events are covered under an
existing event, such as job-problems, or some new event.
KC>> It sounds like we should postpone this until IPP 2.0.
KC>> There are LAN printing solutions that post events
KC>> to end-users when their job is held or resubmitted because
KC>> the end-user might not always have a Printer icon open on
KC> their desktop to view their job's status.
>
> 10. Section 5.3.3.2. job-retention-period. Page 24. Line
> 774-775.
>
> Add to the NOTE: "The requester may also specify this
> job attribute using the input parameter to the Print
> operation." Correct?
No, the job-retention-period is an attribute that accompanies a job
in the Job and Document Attributes parameter.
KC>> I understand and agree.
>
> 12. Section 5.3.5.2. medium. Page 30. Line 896.
>
> I recommend an additional input-tray of "automatic"
> since some printers automatically select the input tray
> based on the media requested by the end-user.
I think that "automatic" is the same as "as-is", in that it says
to use whatever is in the document data which may be nothing. So the
issue is whether to call the value "automatic" or "as is"
KC>> Agreed. I think "automatic" is clearer but "as-is" is fine if
KC>> we state its meaning in the spec. I didn't see "as-is" nor
KC>> "automatic" in version 1.3.1 of the spec.
>
> 13. Section 5.3.6.1. document-format. Page 34. Line 975.
>
> The list of document-formats should be referenced in
> this section. Possibly include the formats in an
> appendix or reference another spec.
>
> >
> 16. Section 5.3.7.14. content-orientation. Page 36. Line
> 1046.
>
> In my opinion, content-orientation should be a Document
> Production attribute. This attribute may apply to all
> types of print jobs - not just text jobs - including
> jobs that are converted by an IPP print driver from a
> graphics API (e.g. Gpi or GDI) to a device datastream
> such as Postscript or PCL.
Please say more. I have assume that a graphics API (e.g. GDI) includes
the content orientation and for that matter the page layout, so it
doesn't make sense to specify content-orientation, which in my view
specifies the first level of page layout.
KC>> You're correct. My mistake - too many margaritas.
KC>> Let's leave content-orientation asis.
>
> 17. Section 5.3.9. Number of Documents. Page 37. Line
> 1079.
>
> Nit. How does a Printer specify there is no limit on
> the number of documents per job? By using an "*"
> (asterisk) as the upper number of the range? A large
> number?
We haven't yet specified how one end of a range is open.
But if the syntax is 'a:b', then either 'a:' or 'a:*' could mean
that the range has no upper bound.
KC>> Ok. The spec should specify the syntax. We should decide this
KC>> very quickly at our telecon today. I vote for 'a:*'.
>
> 26. Section 5.5.1. printer-name. Page 43. Line 1215.
>
> In my opinion, the spec should keep the "printer-name"
> attribute so an Administrator can provide a meaningful
> name to the Printer.
>
The printer-name attribute was renamed 'name' and moved to the common
attributes section which also contains URL.
KC>> I understand and agree. Thanks.
> 27. Section 5.5.2.2. printer-type. Page 44. Line 1221.
>
> Is printer-type necessary in IPP 1.0? How does this
> help the end-user?
I agree.
KC>> Sounds like we both tend to agree this isn't necessary for
KC>> IPP 1.0. Let's discuss at the telecon today.
>
>>>> DO NOT REPLY TO THIS NOTE <<<<