[Printing-architecture] [Printing-summit] OPS Preparationminutes (28 March 2012)

[Ira McDonald]

Hi Glen,

Right - my concern is that JTAPI reference implementation should
normatively reference the source job ticket specification(s).

MJT is dead-in-the-water as a PWG effort - but is copyrighted by
PWG - therefore, not suitable for a normative reference.

Also MJT does NOT address any of the post-IPP/1.1 (RFC 2911)
properties in the PWG Print Job Ticket (i.e., the vast majority of
the content in PWG PJT) - neither does the original JTAPI spec.

I suggest a testing-only serialization of the internal JTAPI JT
would be best for the OP JTAPI reference implementation.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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 Mon, Apr 9, 2012 at 10:46 AM, Petrie, Glen <glen.petrie at eitc.epson.com>wrote:

> ** ** ** ** ** **
>
> Ira,****
>
> ** **
>
> What exactly is your concern?   That the MJT is not official? Not
> complete? Copyrighted? ****
>
> ** **
>
> Why are you under the impression that OP would copy the PWG:MJT
> specification to an OP:MJT specification.  Maybe I missed something in one
> of the emails.  The only intent is use the PWG:MJT for the first JTAPI
> implementation.  ****
>
> ** **
>
> Maybe it would be better not to use MJT.   JTAPI (its objects, elements,
> attributes and values), in itself, is a job ticket.   If the JTAPI project
> uses a JTAPI JT, then it can test all the features in JTAPI.****
>
> ** **
>
> I will examine the JTAPI documentation and code to create a JTAPI JT
> specification.   ****
>
> ** **
>
> Glen****
>
> ** **
>
> ** **
>
> ** **
>  ------------------------------
>
> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com]
> *Sent:* Tuesday, April 03, 2012 12:44 PM
>
> *To:* Petrie, Glen; Ira McDonald
> *Cc:* Daniel Dressler; printing-architecture at lists.linux-foundation.org;
> printing-summit at lists.linux-foundation.org
> *Subject:* Re: [Printing-summit] [Printing-architecture] OPS
> Preparationminutes (28 March 2012)****
>
>  ** **
>
> Hi,
>
> The MJT is a *first* draft whitepaper in the PWG - NOT a standard
> or even a working draft in a chartered PWG working group.
>
> Nonetheless, that whitepaper carries a PWG copyright (it was a
> public submission by me, the sole author).  So *I* can submit an
> updated draft whitepaper to the PWG at any time.
>
> But the MJT spec can't just be copied into an Open Printing document
> format and reissued as an OP working draft without a written copyright
> release from PWG.
>
> MJT covers the most common Job attributes - specifically the subset
> originally defined in IPP/1.0 (RFC 2566 - now obsoleted by RFC 2911).
>
> Cheers,
> - Ira
>
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - TCG Embedded Systems Hardcopy SG
> 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 Mon, Apr 2, 2012 at 5:37 PM, Petrie, Glen <glen.petrie at eitc.epson.com>
> wrote:****
>
> The issue with the MJT is if we want to change something, then we need to
> go back to the PWG.   But, unless Ira disagrees, I see no reason to change
> the MJT for this phase of the JTAPI development.    Perhaps, the MJT will
> not exercise all of the functionality of the JTAPI; in that case, we will
> add a “vendor extension” which would actually be a good thing, because
> JTAPI must handle vendor extension at some point.****
>
>  ****
>
> Glen****
>
>  ****
>
>  ****
>  ------------------------------
>
> *From:* printing-architecture-bounces at lists.linux-foundation.org [mailto:
> printing-architecture-bounces at lists.linux-foundation.org] *On Behalf Of *Daniel
> Dressler
> *Sent:* Monday, April 02, 2012 2:27 PM
> *To:* Petrie, Glen****
>
>
> *Cc:* printing-architecture at lists.linux-foundation.org;
> printing-summit at lists.linux-foundation.org
> *Subject:* Re: [Printing-architecture] [Printing-summit] OPS
> Preparationminutes (28 March 2012)****
>
>  ****
>
> To continue my last email I wanted to say that I would like it if Glen
> continued to be my mentor. My biggest concern is about code quality and I
> think he can provide the criticism and code review I need to improve. ****
>
>
> What exactly is the issue with implementing a micro job ticket backend? It
> was my understanding that MJT would be a simple job ticket format and thus
> a good one to implement as an example/development backend. Is there a
> reason we might need to alter the MJT standard?
>
> Daniel****
>
>  ****
>
>
> _______________________________________________
> Printing-summit mailing list
> Printing-summit at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-summit****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20120409/d613a0bc/attachment.html>