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

Tue Apr 10 00:08:22 UTC 2012

Hello Glen

Actually I don't think that clause would give us the opportunity to alter
the spec. Only to provide in-line documentation on the existing spec.

I'm not fond of the idea of creating yet another job ticket format. Ira
suggested that we use a simple serialisation of the internal data, which I
think is an acceptable option.

I would like a super-thin format for testing and the only thing thinner
than serialisation I can think of is a binary dump. Plus since it will
break all the time we do not have to worry about it escaping into the wild.

Ira, if pwg has new properties does that mean jtapi will need an update?
Are the changes mostly aditive? By that I mean is it safe to implement the
current jtapi spec with the expectation that jtapi 2.0 will simply be
larger?

Daniel

2012年4月9日15:31 Petrie, Glen <glen.petrie at eitc.epson.com>:

> ** ** ** ** ** **
>
> Ira,****
>
> ** **
>
> As a reference I copied the Copyright license from a PWG candidate
> standard which is copied below; I believe the license would give OP the
> right to create an MJT specification from a PWG:MJT specification.
> However, creating a new OP:JTAPI:JT specification to exercise JTAPI and to
> be used as an example for other readers, writers, or convertors would be
> much better.****
>
> ** **
>
> Glen****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> This document may be copied and furnished to others, and derivative works
> that comment on, or otherwise ****
>
> explain it or assist in its implementation may be prepared, copied,
> published and distributed, in whole or in ****
>
> part, without restriction of any kind, provided that the above copyright
> notice, this paragraph and the title of ****
>
> the Document as referenced below are included on all such copies and
> derivative works.  ****
>
> ** **
>
> ** **
>  ------------------------------
>
> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com]
> *Sent:* Monday, April 09, 2012 8:37 AM
>
> *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 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/d819f347/attachment-0001.html>