[IPP] Microsoft has reviewed the IPP Everywhere specification and has comments

[IPP] Microsoft has reviewed the IPP Everywhere specification and has comments

Justin Hutchings justhu at microsoft.com
Mon Aug 20 18:00:01 UTC 2012


Hi all,
Please see comments below.

Thanks
Justin

[BONJOUR] does not exist in either the normative or informative references. Is this intentional? We need to reference it properly or remove it entirely.
Line 290: We should reference the underlying standards for OPC and XML in the references.
Line 304: Are we being overly descriptive about what a printer is considering it is already defined as being either a logical or physical device?
Line 353: I think we need to tighten this up. If we're talking about proximity, then that indicates that a proximity based technology is used to facilitate the discovery directly. If we're merely coloring the results of a directory service, cloud service or discovery protocol based discovery, then we should say so.
Line 380: The parenthetical is unnecessary.
Line 415: Based on discussion at the last face to face, I think we need to be more plain that in this scenario, the accounting program paginates the content appropriately for the check media.
Line 444: We shouldn't use a company name to indicate a generic concept. Can we remove "follow me" and describe the concept more functionally? In the IPP Everywhere context, are we considering "late binding" part of this scenario (like Cloud does)? Eg, I print to a service, and then go to one of several printers where I authenticate and the job is printed only after I've released it at a particular printer.
Line 583: CUPS and CUPSIPP are not referenced properly as normative or informative references.
Line 613: Is it acceptable to specify new versions of TLS as they come along, even if IPP Everywhere isn't advanced? What restrictions do we want to impose here.
Line 628: Do we have requirements (that the IPPtool validates) which blocks use of any GUID value appearing in this spec?
Line 994: We should make it clear that truncation should happen only after a key/value pair has been completed. In other words, don't leave malformed values, or keys without values.
Line 1127: Clients should not be made to support DNS/SD. They may support any discovery protocol described, and clients are generally not purchased based on what protocols they support. Devices, on the other hand, are. We should let the market drive this area.
Line 1134: Clients should not be made to support any particular document formats. If they do not support a format that the printer supports, then they can always opt-out of using IPP Everywhere and use Port 9100 or something else. We should let the market drive this area.

Justin Hutchings | Program Manager | Windows\DNT\DeviceConnectivity::Printing and Imaging


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20120820/dae79694/attachment-0001.html>


More information about the ipp mailing list