[IPP] IPP Scan question.

[IPP] IPP Scan question.

[IPP] IPP Scan question.

Michael Sweet msweet at apple.com
Wed Sep 17 13:29:53 UTC 2014


Works for me.

On Sep 17, 2014, at 8:47 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:

> Small edit on number 7.  If this is acceptable, I’ll post an update for Formal Vote.
>  
> 1.    Follow the PWG Semantic Model for the Network Scan Service.
> 1.    Follow the naming conventions defined in IPP/1.1: Model and Semantics [RFC2911], including keyword value case (lower) and hyphenation requirements
> 2.    Re-use existing IPP operations, attributes, and values when possible.
> 3.    Define IPP attributes, values, and operations necessary for Push Scan.
> 4.    Define IPP attributes, values, and operations necessary for Pull Scan.
> 5.    Define a minimum set of required document formats for interoperability.
> 6.    Define security requirements necessary to support privacy, integrity, and auditing policies
> 7.    Define sections to register all attributes, values, and operations with IANA and PWG Semantic Model
> 8.    Support one or more destinations for Push Scan.
> 9.    Support monitoring of the status of transmission to each destination.
> 10.  Support streaming of basic page-based raster data.
> 11.  Support identification of the Imaging Device.
>  
>  
> Peter Zehler
> 
> PARC, A Xerox Company
> 800 Phillips Rd, 128-27E
> Webster NY, 14580-9701
> Email: Peter.Zehler at Xerox.com
> Office: +1 (585) 265-8755
> Mobile: +1 (585) 329-9508
> FAX: +1 (585) 265-7441
>  
> From: Michael Sweet [mailto:msweet at apple.com] 
> Sent: Wednesday, September 17, 2014 7:50 AM
> To: Zehler, Peter
> Cc: Ira McDonald; Manchala, Daniel; ipp at pwg.org
> Subject: Re: [IPP] IPP Scan question.
>  
> Pete,
>  
> On Sep 17, 2014, at 7:25 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
> Daniel,
>  
> I agree with Ira.  Section 3.5 are design requirements.  Also note that no conformance terminology is used in the design requirements.  My preference would be to leave the specification as currently written.   
>  
> If it must be changed, perhaps the “Push Scan and Pull Scan are required” could be changed to “Push Scan and Pull Scan must be included in the definition”.
>  
> I think some editorial changes to remove conformance-like words would be appropriate and useful. In the process we can normalize the text so that is reads consistently, e.g.:
>  
>     The design requirements for this specification are:
>  
>     1. Follow the PWG Semantic Model for the Network Scan Service.
>     2. Follow the naming conventions defined in IPP/1.1: Model and Semantics [RFC2911], including keyword value case (lower) and hyphenation requirements
>     3. Re-use existing IPP operations, attributes, and values when possible.
>     4. Define IPP attributes, values, and operations necessary for Push Scan.
>     5. Define IPP attributes, values, and operations necessary for Pull Scan.
>     6. Define a minimum set of required document formats for interoperability.
>     7. Define security requirements necessary to support privacy, integrity, and auditing policies
>     8. Define sections to register all attributes, values, and operations with IANA
>  
>     (not sure if these are "design requirements" or just "functional requirements driven by use cases")
>  
>     9. Support one or more destinations for Push Scan.
>     10. Support monitoring of the status of transmission to each destination.
>     11. Support streaming of basic page-based raster data.
>     12. Support identification of the Imaging Device.
> 
> 
> Pete
>  
> Peter Zehler
> 
> PARC, A Xerox Company
> 800 Phillips Rd, 128-27E
> Webster NY, 14580-9701
> Email: Peter.Zehler at Xerox.com
> Office: +1 (585) 265-8755
> Mobile: +1 (585) 329-9508
> FAX: +1 (585) 265-7441
>  
> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Ira McDonald
> Sent: Tuesday, September 16, 2014 9:16 PM
> To: Manchala, Daniel; Ira McDonald
> Cc: ipp at pwg.org
> Subject: Re: [IPP] IPP Scan question.
>  
> Hi Daniel,
> 
> I'll try to answer this one.  Mike and Pete can chime in of course.
> 
> Section 3.5 Design Requirements simply requires that the *spec*
> defines methods and attributes for both Push and Pull scan - NOT
> that any Printer or Client has to implement them.
> 
> Sections 8.x are correct that Push Scan is OPTIONAL - this was
> always intended.
> 
> The old section 11.1 requirement (SHOULD) was redundant and
> removed in the clarification of sections 11.x in general.
> 
> Does that help?
> 
> Cheers,
> - Ira
>  
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic at gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
>  
> On Tue, Sep 16, 2014 at 8:41 PM, Manchala, Daniel <Daniel.Manchala at xerox.com> wrote:
> Section 3.5 (Design Requirements) Item 3. says:
> 
> * Push Scan and Pull Scan are required.
> 
>  
> 
> This statement (...are required...) states that the Push Scan is required.
> 
>  
> 
> However, Section 8.2 Job Template attributes: destination-uris says:
> 
>  
> 
> * Scan Services that support Push Scanning MUST support this attribute.
> 
>  
> 
> This statement (...that support ...) states that the Push Scan is optional.
> 
>  
> Again, Section 8.3.2 destination-uri-schemes-supported says:
> 
>  
> 
> * Scan Services that support Push Scan MUST support this attribute.
> 
>  
> 
> This statement (...that support ...) states that the Push Scan is optional.
> 
>  
> 
> Section 11.1 mentioned "Scan Services MUST support Pull Scan and SHOULD support Push Scan" in an older version of the document (20140725), but the current version does not mention that.
> 
>  
> 
> Can you clarify this?
> 
>  
> 
> Thanks,
> 
> Daniel.
> 
>  
> 
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
> 
>  
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>  
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>  

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140917/21707e7c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140917/21707e7c/attachment.p7s>


More information about the ipp mailing list