IFX Mail Archive: RE: IFX> IPP Fax meeting #4 [my comments o

IFX Mail Archive: RE: IFX> IPP Fax meeting #4 [my comments o

RE: IFX> IPP Fax meeting #4 [my comments on the UIF and IFX docum ents]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jan 26 2001 - 03:02:21 EST

  • Next message: MAEDA toru: "IFX> Legal Requirements on Clasic fax"

    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