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

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>