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

Tue Apr 10 16:17:43 UTC 2012

Ah sorry this is my web dev background showing through. By serialisation I
had JSON in mind.

So I think we're all on the same page now.

Daniel

2012年4月10日7:09 Petrie, Glen <glen.petrie at eitc.epson.com>:

> ** ** ** ** ** **
>
> Daniel****
>
> ** **
>  ------------------------------
>
>
> 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.
> [gwp] the clause allows creation of derivative work.****
>
>
> 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.
> [gwp] Not creating another job ticket format; creating a mechanism to test
> JTAPI and example code without worry if using a specific Job Ticket Format
> is up to date.   ****
>
>
> 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.
> [gwp] The intent is that a front-end to JTAPI would accept XML or JSON;
> not data structures****
>
>
> 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/20120410/aa1991f8/attachment-0001.html>