Subject: Re: [IPP] IPP FaxOut Issues from Canon

From: Michael Sweet <[email-masked]>
Date: Tue, 08 Jan 2013 09:49:44 -0500

Rick,

Thanks for the feedback.  See my responses inline below.

On Dec 28, 2012, at 2:43 PM, "Yardumian, Rick" <[email-masked]> wrote:
> Hi,
> 
> Canon has the following issues with the current IPP FaxOut specification "wd-ippfaxout10-20121128-rev.pdf".
> 
> 1. We think that cover page in section 3.4 Design Requirements should be generated not by the printer but the client.  We think that it is not preferable for users that each vendor has different cover page formats.  If the client generates the cover page, it is unnecessary to have a language font on the printer.  Requiring the printer to generate cover sheets means the printer must do localization which is a big burden for low cost MFDs. Therefore we would like printer generated cover sheets to be optional.

Based on our discussions at the F2F, I think we have consensus to make printer-generated cover pages conditionally required when the printer supports PDF or OpenXPS (which provide the necessary font support and resources for generating the cover pages...

> 2. For 6.1.2.7 to (text(255)) we should follow each country's rule where the printer is located.  For example, in USA, 40 valid characters from the beginning is required.  So, we would like to take (text(the maximum number of valid characters from the beginning)) instead of (text(255)) for this requirement.  Is that OK?

At the protocol level we need to set a maximum, but I can add wording about country-specific limits.

However, this is the cover page and not the header added to each page of the output - do country-specific limits even apply to cover pages?

And how do we get/set the sender text that is part of this header (configuration of the MFD, not a job attribute)?

> 3. Can we ignore 6.1.3.4 t33-subaddress (integer(0:MAX)) for a printer that cannot use this information?

t33-subaddress is optional.  I will add some text about all of the optional fields, a new "destination-uri-supported (1setOf type2 keyword)" Printer attribute that lists the supported collection member attributes, and some text about what a printer does if member attributes are specified but not supported (i.e. successful-ok-ignored-or-substituted-attributes or client-error-attributes-or-values-not-supported depending on ipp-attribute-fidelity, job-mandatory-attributes, and the destination-uri scheme)

> 4. 6.1.4 number-of-retries (integer(0:MAX)) and 6.1.5 retry-interval (integer(1:MAX)) might sometimes be ignored by following each country rule where the printer is located.  Is that OK?

There are several reasons why this might be ignored, but the printer needs to reflect the supported values in the corresponding xxx-supported values.  I will add wording about this, along with a reminder of what to do with an out-of-range value (see previous comments).

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp