All,
I've done some research (mainly going back through the MFD Scan and Model documents) and both define the ColorEntry job ticket element to control the corollary of print-color-mode for scanning. So, for purposes of IPP Scan I would opt to use color-entry and the corresponding mapped keywords from the MFD Scan/Model specs.
In general I think we can stick with the existing names. If something new applies to multiple services and doesn't have a logical prefix of its own, add "imaging-" to the front. If something is service-specific, put the service name on the front..
All that said, here is another wrinkle: copy, which has input and output job ticket elements... I'm thinking we just use collections, but we have time to discuss the actual binding...
On Apr 19, 2011, at 11:59 AM, Mitchell, Andrew (Solutions Architect) wrote:
> OK, my 2¢.
>> We need to decide if naming a NEW attribute that applies to more then just print with the print- prefix makes sense. A agree that renaming existing attributes does not make sense, and using the print- attributes in scan (and fax) rather then renaming them is logical. But if we are going to say attributes that are originally defined in Scan (or Fax) start with imaging- while if they first show up in IPP Everywhere (or some other doc like JPS3) we name them print- that doesn't seam quite right. My preference would be either:
>>> 1. Call everything that is not scan (or fax) specific print-, no matter where it is first defined. For scan or fax specific, call them scan- and fax-.
> 2. Start using the imaging- prefix everywhere that the term is NOT print specific.
>> We are going to expand the model which is heavily rooted in print to other services, I'd just like to have a consistent naming convention for how we move forward. 1 seems more confusing to me since it means keeping the print- name moving forward, and we'll have to maintain the table as to what is print specific and what isn't, but 1 also seems more true to the roots of IPP. I however personally vote for 2 since it clearly implies our broader scope of the protocol moving forward.
>> As for just dropping the print- prefix, while it works for color-mode, I think we need to take a harder look to make sure it makes sense everywhere. Note that I view this as simply a different way of naming option 2. If we pick option 2 we need to then pick the naming convention.
>> OK, so that was a bit more the 2¢ worth.
>> Andrew
>> From: Tom Hastings <tom.hastings at verizon.net<mailto:tom.hastings at verizon.net>>
> Reply-To: "tom.hastings at alum.mit.edu<mailto:tom.hastings at alum.mit.edu>" <tom.hastings at alum.mit.edu<mailto:tom.hastings at alum.mit.edu>>
> Date: Tue, 19 Apr 2011 18:45:45 +0000
> To: 'Ira McDonald' <blueroofmusic at gmail.com<mailto:blueroofmusic at gmail.com>>, 'Michael Sweet' <msweet at apple.com<mailto:msweet at apple.com>>
> Cc: "ipp at pwg.org<mailto:ipp at pwg.org>" <ipp at pwg.org<mailto:ipp at pwg.org>>
> Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
>> I agree with Ira. On the other hand, one other alternative for the name would just to drop the "print-" prefix and call it "color-mode".
>> Tom
>> ________________________________
> From: ipp-bounces at pwg.org<mailto:ipp-bounces at pwg.org> [mailto:ipp-bounces at pwg.org] On Behalf Of Ira McDonald
> Sent: Monday, April 18, 2011 15:35
> To: Michael Sweet; Ira McDonald
> Cc: ipp at pwg.org<mailto:ipp at pwg.org>
> Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
>> Hi Mike,
>> My two cents.
>> No - let's keep the name "print-color-mode" to cohere with the
> zillion other print-xxx or printer-xxx attributes.
>> In the new IPP Scanner and Fax objects lets just globally apply
> most/many existing IPP Printer attributes in big table(s) with
> a rationale for why some attributes are not applicable to the
> other multifunction objects.
>> Unless almost all Printer attributes *are* applicable, which I begin
> to suspect is the case (and have a short table of the exceptions).
>> I think we should reserve use of he "imaging-" prefix for only new
> attributes defined first for Scanner, Fax, etc. objects for IPP
> Everywhere Second Edition.
>> Cheers,
> - Ira
>>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy 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<mailto:blueroofmusic at gmail.com>
> Christmas through April:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> May to Christmas:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>>> On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet <msweet at apple.com<mailto:msweet at apple.com>> wrote:
> All,
>> If we consider scanning and printing of forms, the "bi-level" (threshold) mode makes sense for both. Do we want to rename "print-color-mode" to "imaging-color-mode" in anticipation of using is for other MFD services in IPP?
>> ________________________________________________________________________
> 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
>ipp at pwg.org<mailto:ipp at pwg.org>
>https://www.pwg.org/mailman/listinfo/ipp>>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner<http://www.mailscanner.info/>, and is
> believed to be clean.
>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner<http://www.mailscanner.info/>, and is
> believed to be clean.
________________________________________________________________________
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.