Paul,
Good start! Here are my comments for the meeting. Sorry I'm not there.
UIF (Universal Image Format) comments:
1. Page2/Line 19-20. Editorial: I assume that a Printer that supports UIF
MUST support the REQUIRED parts of the TIFF-F specification and MAY support
the OPTIONAL parts of the TIFF-F specification. This sentence may be a
better way to make this clear.
2. Page2/Line 24: IPP attribute names are all lower case, so change
"UIF-conneg" to "uif-conneg". Or maybe a more descriptive names, such as
"uif-image-capabilities".
3. Page2/Line 25 and Page4/Line 18: IPP max length is 1023, not 1024.
4. Page3/Line 18: The name was changed from page level exceptions to Page
Overrides.
5. Page 4/Lines 17-19 (Issue 2): I suggest that long strings be handled by
array of strings, i.e., the attribute would be "uif-image-capabilities"
(1setOf text(MAX)) where MAX is 1023.
IFX (IPP FAX) comments:
Several comments are labeled as ISSUE and need discussion/debate at the
meeting. I hope the other comments can be reviewed too.
1. Line 11: Isn't there also a goals document for QUALDOCS that is now an
expired Internet-Draft? Should it be resurrected/re-issued and cited?
2. Line 72: the prefix for attribute names should be all lower case to agree
with IPP attribute naming conventions. So the prefix is "ifx-".
3. Line 99: The sender can only send one document with Print-Job (or were
you going to allow multi-part/related to be a way to send multiple
documents?), so change "scans the documents" to "scans the document".
4. Line 99: Since the sender doesn't have to scan (see line 68), how about
replacing the sentence:
> The sender scans the documents and converts them into an acceptable
data format - see 'data formats'.
with:
> The sender either (1) scans the document and converts them into an
acceptable data format, if the sender scans document or (2) generates an
acceptable data format from an electronic representation - see 'data
formats'.
5. Line 104: The term "delivered" is ambiguous. It could mean when the bits
are delivered to the IPP Printer or when the sheets of medium are delivered
to the output bin. Which do you mean? The former happens when the receiver
finishes receiving the data part of the Print-Job and returns the successful
response - no notification is needed. The latter happens when the job
completes and the last sheet is delivered to the output bin - does require
notification.
6. Line 118: The "ifx-receiver" (boolean) not only needs to be supported,
but needs the value 'true'. An IPP implementation might be configurable to
be an ifx Printer, but currently isn't, so the value could be 'false' (or
the attribute not present at all).
7. Line 138: The best methods to determine the document format supported is
for the sender to query the Printer's "document-format-supported" (1setOf
mimeMediaType) Printer Description attribute, as in IPP.
8. Line 148 and 308: I suggest that the sender MUST (not SHOULD) send the
"ifx-sending-user-identity", in addition to the "ifx-sender-identity".
Doesn't that help with spam?
9. Line 151 and 328: I suggest that the send MUST (not SHOULD) include the
"ifx-receiving-user-identity, in addition to the "ifx-receiver-identity".
Though a case could be made to keep it at SHOULD for the case where the
sending user knows that the receiving user is right at the receiving device
(perhaps because they are on the telephone). However, because the receiver
could have received multiple jobs, it still seems to be more reliable and
high quality if each job has the intended receiving user always supplied.
10. Line 158-159: In order for IPP FAX to have the same protection under
law for exchange of documents that FAX has, don't we need to specify
something stronger for the sending device identify than "SHOULD be a value
that can reasonably be expected to uniquely identify the device"?
11. Line 172: The sender (IPP client) cannot send "job description"
attributes. Job Description attributes are read-only Job attributes
returned by the IPP Printer in responses. The sender can only send
"Operation Attributes" or "Job Template attributes" (and Subscription
Template attributes, if subscribing to event notification) in a Print-Job
request.
ISSUE: There are 5 attributes in the spec that are indicated to be of type
"job description". This must be changed to either "Operation Attribute"
and/or "Job Template attribute". The "ifx-sending-user-identity",
"ifx-receiving-user-identity", "ifx-sender-identity", "ifx-destination-uri"
and "ifx-return-address" are similar to the IPP/1.1 "job-name" attribute
which we first has as a Job Template attribute. But it had neither
"job-name-default" nor "job-name-supported", so we changed it to be an
Operation Attribute in the Print-Job request. But since it was also useful
to be able to query on the Job and the Printer needed to remember the data,
we also made "job-name" be a (READ-ONLY) Job Description attribute which the
Printer populates from the "job-name" Operation Attribute supplied by the
client in the request.
I suggest that the 5 ifx attributes (lines 303, 324, 332, 351, and 363) be
handled just like "job-name" in IPP. So just change the type from "Job
Description" to "Operation and Job Description" with the explanation that
the Printer populates the Job Description attributes with the values
supplied by the client as Operation attribute. The Printer returns the Job
Description attributes in Get-Job-Attributes responses as Job Description
attributes to appropriate users.
12. ISSUE: Section 5.4 Notification: while we could use the new 'ippget'
notification method where the client polls for the job completion event, why
not have the client simply poll using the Get-Job-Attributes operation? If
we used Get-Job-Attributes, we would need to REQUIRE printers to keep the
job in the Job History for some length of time (the same as the window for
ippget), so that a client wouldn't miss the job completing before the job
disappeared completed.
13. Line 192: IPP doesn't have a "job-description" attribute. How about
using the IPP/1.1 REQUIRED "job-name" attribute to convey the Subject?
14. Lines 198-199 say: The receiver MUST place the sender's identity at the
top of at least the first page of the received [tiff/fx] document. But if
the Printer is generating the cover page from the VCARD info supplied by the
client, would the Printer meet the requirement by placing the sender's
identify at the top of the cover page? Or does the Printer have to corrupt
the first actual page of the tiff/fx document, rather than the generated
cover page?
15. Line 208: For the Combined Device the value sent for the
"ifx-return-address" MUST be the same as the value supplied by some other
sender sending to this Combined Device for what attribute? The
"printer-uri"?
15a. Line 208 and 361: If the "ifx-return-address" is the URI of the
Combined Device, I suggest change its name to "fix-return-uri", as we have
done for all other IPP attributes whose attribute syntax is 'uri'.
16. Line 251: How does an IFX receiver identify a sending user as "an IPP
administrator"? Or is this done by means outside the scope of this
specification?
17. Sections 8.1 and 8.2 On-ramp and Off-ramp. I had thought that the sense
of these were the opposite. I though that an off-ramp would be when the
sender uses IFX to send the document to an IFX Printer but specifies the
ifx-destination-uri" in addition for the IFX Printer to send the document
further, say with mailto or some other delivery scheme as specified in the
"ifx-destination-uri" attribute that the sender also supplies.
18. Lines 302, 323: Why not make "ifx-sending-user-identity" and
"ifx-receiving-user-identity" be 'text(MAX)', instead of 'octetString(MAX)'
(where MAX is 1023 in both cases)? The value seems to be text. What about
the character set used in VCARD? Can it be any other charset than ASCII?
UTF-8?
19. Lines 331 and 338: The "ifx-sender-identity" and "ifx-receiver-identity"
have the 'name(MAX)' (MAX = 225) attribute syntax. Since the MAC address is
a recommended value, don't we need to say that it is the printable form of
MAC address?
20. Line 367: A Combined Device MUST (not SHOULD) send the
"ifx-return-address" (see line 208) and the value MUST be the same as
another sender would use in a "ifx-receiver-identity" in sending to the
Combined Device.
21. After Line 368: Need a conformance section which lists which attributes
and operations an IFX Printer MUST support and which are optional. Like we
have in RFC 2911 section 5. Probably need to indicate an Off Ramp option
(or as you call an On Ramp) which, if implemented, the Printer MUST support
additional attributes, such as "ifx-destination-uri". See line 355. Also
the Combined Sender/Receiver option in which the "ifx-return-address" value
MUST be the same as the receiver would use for the "ifx-receiver-identity"
to send a document back to the sender.
Thanks,
Tom
-----Original Message-----
From: pmoore@netreon.com [mailto:pmoore@netreon.com]
Sent: Thursday, January 18, 2001 14:13
To: ifx@pwg.org
Subject: IFX> IPP Fax meeting #4
Dear IPP Faxers,
The next IPP fax meeting in is Maui on 1/26/01. We will run from 8.30am to
5pm
unless we run out of things to talk about.
Details are at http://pwg.org/chair/maui01.html.
I have posted some real meat for us to get our teeth into.
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-01.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-01.pdf
The first is the (short) spec for UIF - TIFF-FX over IPP
The second is the spec for IPP Fax transport (IFX)
These will be the only items on the Maui agenda unless there are other
pressing
matters.
I look forward to seeing you all.
Paul Moore
Netreon Inc
This archive was generated by hypermail 2b29 : Fri Jan 26 2001 - 03:02:33 EST