Ira,
I agree with most of your comments. However, I have push back on the
following 2 comments C and D:
C) Comment on ISSUE 07:
The Printer MUST scale to support our (nearly equal) choice media size.
The Printer MUST NOT truncate (for IPPFAX). Your issue is invalid.
REQUIRING an IPPFAX Receiver (or any IPP Printer) that supports one of the
new choice "media" keywords to scale, seems to be a high burden on the
Printer and for little gain.
If the choice keywords are restricted to be for sizes that are close
together, such as na_letter and iso_a4 (or iso_b4 and jis_b4) and we follow
the existing FAX practice of the Sender formatting document content so that
it fits on either size, then the Printer doesn't have to scale.
Only if the Printer chooses to scale MUST the Printer do so with isomorphic
scaling to preserve the aspect ratio.
This is an important ISSUE for the IPPFAX WG to discuss for use with PDF/is
(where scaling may not be a burden).
But for general use with any PDL, requiring scaling seems to be a high
burden.
I think that we also went wild in the telecon with the suggestion that a
choice keyword value could have quite disparate sizes, such as A4 and B4,
where scaling would be necessary in order to be useful. I think allowing
such disparate sizes would be a serious mistake and undermine the
interoperability for the really important use cases of very similar sizes.
D) Comment on ISSUE 09:
No - in IETF and W3C terms we are NOT "revising" or "updating" 5100.4.
We are "obsoleting" 5100.4 (much stronger than "deprecating"). The
previous text of 5100.4 will be abandoned. An implementation CANNOT
claim conformance to a non-standards-track former document. The
future Candidate Standard 5100.4 will define DIFFERENT attributes with
fundamentally DIFFERENT semantics. That is NOT "revision" in the
terms of any of your cited standards bodies.
That is exactly why the soon-to-be-published RFC of Printer MIB v2
will state that it "obsoletes" the Printer MIB v1 (RFC 1759), because
there are actual semantic differences (corrections) between some of
the common attributes in the two MIBs.
Our goals are the same, its just the terminology. Also you are missing my
point that the IETF never *revise* an RFC, they just publish a new RFC with
a new number, and then say whether that new RFC updates or obsoletes the
older RFC.
But other standards bodies, like ANSI, ISO, IEEE, etc, actually revise their
existing standards keeping the *same* number. When the revision is
approved they just change the year that is part of the designation.
That is why I think that the PWG is revising IEEE-ISTO Trial Use
5100.4:2001. We'll have an appendix that indicates that we've removed
"document-overrides" and replaced "page-overrides" with "overrides". Also
we can say in that Appendix that "pages-per-subset" has been moved to
[ippjobx].
Tom
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Monday, June 02, 2003 09:06
To: 'Hastings, Tom N'; ipp@pwg.org
Subject: RE: IFX> Updated JOBX spec for Wed, June 4, 1-3 PM PDT (4-6 PM
ED T) teleco n (10 ISSUES)
Hi Tom,
I made this comment before, but I see it got lost in the latest version.
A) Comment on ISSUE 02 and ISSUE 03:
The correct name of "output-device-requested-supported" should be
"output-device-supported". Both "-requested" and "-assigned" are
suffixes (just like "charset-configured"). We have "charset-supported",
not "charset-configured-supported".
Please remember that "output-device-supported" has always been needed
for the existing "output-device-assigned" Job attribute. It is the
list of "friendly" device names (not URLs, unfortunately) that the
IPP Printer object supports.
The future IPP Device object (output of the WBMM project and Semantic
Model extensions) should have a KEY Device Description attribute called
"device-name" (to disambiguate the locality of reference), which MUST
be one of values of the "output-device-supported" attribute.
B) Comment on ISSUE 05:
The datatype of "pages-per-subset-supported" MUST NOT be changed from
a previous version (PWG Trial Use 5100.4) unless the NAMES of these
attributes (BOTH "pages-per-subset" and "pages-per-subset-supported")
are also changed.
If the datatype OR the semantics change, then the old attribute MUST
be abandoned and replaced with a new attribute with a new name.
C) Comment on ISSUE 07:
The Printer MUST scale to support our (nearly equal) choice media size.
The Printer MUST NOT truncate (for IPPFAX). Your issue is invalid.
D) Comment on ISSUE 09:
No - in IETF and W3C terms we are NOT "revising" or "updating" 5100.4.
We are "obsoleting" 5100.4 (much stronger than "deprecating"). The
previous text of 5100.4 will be abandoned. An implementation CANNOT
claim conformance to a non-standards-track former document. The
future Candidate Standard 5100.4 will define DIFFERENT attributes with
fundamentally DIFFERENT semantics. That is NOT "revision" in the
terms of any of your cited standards bodies.
That is exactly why the soon-to-be-published RFC of Printer MIB v2
will state that it "obsoletes" the Printer MIB v1 (RFC 1759), because
there are actual semantic differences (corrections) between some of
the common attributes in the two MIBs.
Cheers,
- Ira
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Monday, June 02, 2003 2:28 AM
To: ipp@pwg.org
Cc: ifx@pwg.org
Subject: IFX> Updated JOBX spec for Wed, June 4, 1-3 PM PDT (4-6 PM EDT)
teleco n (10 ISSUES)
I've uploaded the updated version of the Job Extension spec for review
Wednesday, 1-3 PM PDT (4-6 PM EDT):
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530.pdf.zip
(572KB)
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530.doc.zip
(125KB)
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530-rev.pdf
(262KB)
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030530-rev.doc.zip
(142KB)
Please send any comments to the ipp@pwg.org DL only!
> Rick Seeler has invited you to a MeetingPlace voice conference.
>
> Date/Time: June 04, 2003, 01:00 PM America/Los_Angeles
> Meeting ID: 123123
> Password:
> Frequency: Once
>
> MeetingPlace Phone Numbers:
> Local: 408-536-9900
Here is the webex info -
Name: IFX
Date: 6/4/2003
Time: 1:00PM, (GMT -07:00) Pacific Time, USA & Canada (DayLight Time)
Meeting Number: 29378444 Meeting Password: pwgifx
Here are the changes from the last version we reviewed at the May 28
telecon:
Version 0.3, 30 May 2003:
Agreements reaches at the May 28, 2003 telecon:
1. Moved the Close-Job operation to the futures specification.
2. Added the "pages-per-subset" Job Template from [pwg5100.4].
See Appendix B section 17 for the minor differences.
3. Added the terms: "Best Effort, Finished Document, Page, Page
Subset, and Sheet.
4. Clarified the conformance relationships between "xxx"
Operation attributes and their corresponding "xxx-default" and
"xxx-supported" Printer attributes.
5. Added rationale for each missing "xxx-default" and
"xxx-supported" attribute.
6. Added 'errors-detected' and 'warnings-detected'
"job-state-reasons" values.
7. Added the new 'choice_iso_a4_210x297mm_na_letter_8.5x11in'
"media" attribute value which is a choice of two approximately equal media.
8. Added the requirements for choice media keyword values for
inclusion in a revision of the PWG IEEE-ISTO 5101.1.
9. Changed the "document-format-implemented" member attribute
from 1setOf mimeMediaType to mimeMediaType since it is the key attribute
value.
10. Added another "document-format-implemented" example.
11. Updated the IANA section to agree with the additions.
The following 10 issues are highlighted in the document:
ISSUE 01: OK that the "job-mandatory-attributes" Operation attribute has
nothing to do with guaranteeing (that the attribute will supersede the PDL),
but only with whether the Printer will accept the job with unsupported
attributes requested - TNH
ISSUE 02: From DMC: It seems like it might be possible, for certain
implementations, to have a default output-device. The problem is that
normally the "xxx-default" is REQUIRED [TH: not for operation attributes, so
we say a Printer MAY support the "output-device-default"], whereas my idea
would be more to allow a Printer to advertise a default only if it matched
its actual implementation.
3.1.3.1 Why there is no "output-device-requested-default" attribute
ISSUE 02 (repeat): From DMC: Should we add an
"output-device-requested-default" Printer Description attribute that a
Printer MAY support when it supports the "output-device-requested" Operation
attribute?
ISSUE 03: (Thought up while writing up the reason for no default):
[rfc2911] does have the concept of attribute coloring that causes the values
of Printer attributes to depend on the "document-format". Thus, we could
have "document-format-version-default" whose value depends on the value of
the "document-format". Do we want to have
"document-format-version-default", which, if supported, the Printer MUST
color the value depending on the "document-format" Operation attribute
supplied in the Get-Printer-Attributes request?
All part of ISSUE 04:
If the client supplies more integer values for the "pages-per-subset"
attribute than the Printer supports, the Printer MUST treat the remaining
values as Unsupported Attribute values as follows (see [rfc2911] section
3.1.7):
If the client supplies the "attribute-fidelity" Operation
attribute with a 'false' value (see section 3.1.1) or omits the attribute
altogether, the Printer MUST (1) otherwise accept the Job, (2) return the
'successful-ok-attributes-ignored-or-substituted' status code, and (3)
return in the Unsupported Attribute Group the additional values not
supported.
If the client supplies either the "attribute-fidelity"
Operation attribute with a 'true' value or the "job-mandatory-attributes"
Operation attribute with the 'pages-per-subset' keyword value (see section
3.1.2), the Printer MUST reject the job.
ISSUE 04: PWG 5100.4 was silent on whether a Printer MUST support any
number of integer values for "pages-per-subset" or whether the number was
implementation dependent. Is supporting only a single value considered a
conforming implementation so that the above error handling is sufficient?
ISSUE 05: PWG 5100.4 had the "pages-per-subset-supported" attribute
specified as a boolean. MUST a Printer support any number of integer values
for the "pages-per-subset" (1setOf integer(1:MAX)) Job Template attribute?
If supporting a maximum number, even as low as '1', is considered
conforming, should we change the attribute syntax of the
"pages-per-subset-supported" to integer(1:MAX) to indicate the maximum
number of values supported by the Printer? Or is it sufficient for the
Printer to return in the Unsupported Attributes group the remaining values
of the "pages-per-subset" (integer(1:MAX)) attribute that aren't supported?
ISSUE 06: What about the maximum number of pages in a Page Subset? MUST a
Printer support any number up to MAX in any Page Subset?
Part of ISSUE 07:
The Printer MAY scale the image to fit, but any scaling MUST be isomorphic
scaling and without image content loss.
ISSUE 07: Why even allow the Printer to scale? Lets simplify this choice
concept to sizes that are approximately the same, such as A4 and na-letter,
rather than allowing a choice, of, say, A4 or A3 which would require
scaling. That makes interoperability more difficult.
ISSUE 08: Who needs the "document-format-details-implemented" attribute?
Does PSI? We assume yes. However, if PSI does support Capabilities, then
we shouldn't define "document-format-details-implemented" in this spec,
since "document-format-details-implemented" is a poor man's capability
mechanism. ACTION ITEM (Tom): Ask PSI whether they intend to use
"document-format-details-implemented"? If not, should
"document-format-details-implemented" be moved to the IPP Futures document,
or just deleted and wait for someone to request it?
Document Color Separation (DCS), version 2.0. ISSUE 10: Need a reference
All part of ISSUE 09:
[pwg5100.4]
Herriot, R., Ocke, K., "Internet Printing Protocol (IPP): Override
Attributes for Documents and Pages", IEEE-ISTO 5100.4-2001, February 7,
2001, ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.4.pdf. - being obsoleted
by (1) a new Page Overrides specification which removes the
"document-overrides" Job Template attribute and Operation attribute in favor
of using the Document Object [ippdoc] and (2) this specification [ippjobx]
definition of "pages-per-subset" Job Template attribute.
ISSUE 09: The IETF process never revises an RFC, but just updates or
obsoletes one with another RFC. On the other hand most other standards
organizations, such as ANSI, ISO, (IEEE?), and POSIX, require that standards
be reviewed and if necessary be "revised". I think that we are "revising"
PWG IEEE-ISTO 5100.4, not "obsoleting" it. This is just a terminology
question.
The second paragraph of the PWG process section 4.2 says:
"Working Drafts and Candidate Standards correspond
to a specific version of the Standard they are defining. Unless the working
group is engaged in an effort to revise an existing PWG Standard, the
Working Drafts and Candidate Standards are always defining PWG Standard
Version 1.0."
and section 4.4.1 says:
"Although the maturity level will not appear on PWG
Candidate Standards or PWG Standards, if a Candidate Standard needs to be
revised, any resulting PWG Working Drafts will have a maturity level
indicated on their title page."
This archive was generated by hypermail 2b29 : Mon Jun 02 2003 - 13:42:26 EDT