[Printing-architecture] [Printing-summit] OPS Preparationminutes (28 March 2012)
Petrie, Glen
glen.petrie at eitc.epson.com
Mon Apr 9 21:31:00 UTC 2012
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/blueroofmusic>
http://sites.google.com/site/highnorthinc
<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/blueroofmusic>
http://sites.google.com/site/highnorthinc
<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/7253d92b/attachment-0001.html>
More information about the Printing-architecture
mailing list