Subject: [IPP] Updated JPS3 draft posted

From: Michael Sweet <[email-masked]>
Date: Thu, 3 Mar 2011 22:41:36 -0800

All,

I've posted a new draft of JPS3 at:

    ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110303.docx
    ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110303.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110303-rev.pdf

Aside from regenerating the table of contents, this version includes the xxx-uuid attributes and the multiple-operation-timeout-action attribute from MFD Model. I also filled in the new finishings and job-state-reasons values.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Yousey, Marc" <[email-masked]>
Date: Fri, 4 Mar 2011 23:53:42 +0000

One thing that would be nice to add to the media-col is the pwg-standard-name.  With rounding going on on both sides of the wire it can be difficult to associate the standard sizes in media-supported to the media-size elements in the media-col-database.  If the media-size collection had a pwg-standard-name (or similar) attribute we could be sure which size everyone was talking about rather than trying to guess.

Also, a few questions:

1) job-uri is just an informational object correct?  I.e. it is not a new way to specify which job you are operating on in say a get-job-attributes or cancel-job request.

2) On the new job-state-reasons, is there a corresponding status code to return with job requests?  There seems to be a pairing between many but not all of the job-state-reasons and status-codes.

Thanks,
Marc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Thursday, March 03, 2011 10:42 PM
To: [email-masked]
Subject: [IPP] Updated JPS3 draft posted

All,

---

From: Michael Sweet <[email-masked]>
Date: Fri, 4 Mar 2011 16:59:06 -0800

> One thing that would be nice to add to the media-col is the pwg-standard-name.  With rounding going on on both sides of the wire it can be difficult to associate the standard sizes in media-support…

I have no objection to adding a media-name member attribute that contains the PWG media name that corresponds to the given dimensions and margins. While size matching is not usually an issue for CUPS, margin matching often can be...

> 1) job-uri is just an informational object correct?  I.e. it is not a new way to specify which job you are operating on in say a get-job-attributes or cancel-job request.

I assume you mean job-uuid? In the current definition it is only used as an informational object. The local job-id  or job-uri is used to actually specify the job object in job operations. If all you had was a job-uuid, you would need to use the Get-Jobs operation to get a list of all jobs and their job-uuid attributes and then find the job you are interested in.

> 2) On the new job-state-reasons, is there a corresponding status code to return with job requests?  There seems to be a pairing between many but not all of the job-state-reasons and status-codes.

Currently I have not added any new status-code values, although we can do so if a need is seen. Both document-security-error and document-unprintable-error checking could be done as part of job/document creation, although I think it is more likely that they will be discovered while processing the job.

Is the existing client-error-document-format-error status code sufficient, or would you prefer to see new status codes for each?

---

From: Ira McDonald <[email-masked]>
Date: Sat, 5 Mar 2011 03:06:42 -0500

Hi,

I suggest that this new attribute be explicitly named
"media-size-name" (rather than the sadly ambiguous
"media-name") and constrained to ONLY take size
name values from the PWG Standard for Standardized
Media Names (PWG 5101.1-2002) - which is BTW
certainly the most circular and meaningless PWG
Candidate Standard document title that we've ever
come up with...

Note that our DMTF CIM_PrintInputTray class has the
element "MediaSizeName" which we used to map from
the Printer MIB's "prtInputMediaDimFeedDirDeclared"
and "prtInputMediaDimFeedDirDeclared" objects.

Also note that either "job-uri" or "job-id" can be used in
job operations, but either MUST be accompanied by the
enclosing "printer-uri" that specifies the over-the-wire
protocol target of the IPP over HTTP request.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
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:[email-masked]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

On Fri, Mar 4, 2011 at 7:59 PM, Michael Sweet <[email-masked]> wrote:

> > One thing that would be nice to add to the media-col is the
> pwg-standard-name.  With rounding going on on both sides of the wire it can
> be difficult to associate the standard sizes in media-supported to the
> media-size elements in the media-col-database.  If the media-size collection
> had a pwg-standard-name (or similar) attribute we could be sure which size
> everyone was talking about rather than trying to guess.
>
> I have no objection to adding a media-name member attribute that contains
> the PWG media name that corresponds to the given dimensions and margins.
> While size matching is not usually an issue for CUPS, margin matching often
> can be...
>
> > Also, a few questions:
> >
> > 1) job-uri is just an informational object correct?  I.e. it is not a new
> way to specify which job you are operating on in say a get-job-attributes or
> cancel-job request.
>
> I assume you mean job-uuid? In the current definition it is only used as an
> informational object. The local job-id  or job-uri is used to actually
> specify the job object in job operations. If all you had was a job-uuid, you
> would need to use the Get-Jobs operation to get a list of all jobs and their
> job-uuid attributes and then find the job you are interested in.
>
> > 2) On the new job-state-reasons, is there a corresponding status code to
> return with job requests?  There seems to be a pairing between many but not
> all of the job-state-reasons and status-codes.
>
> Currently I have not added any new status-code values, although we can do
> so if a need is seen. Both document-security-error and
> document-unprintable-error checking could be done as part of job/document
> creation, although I think it is more likely that they will be discovered
> while processing the job.
>
> Is the existing client-error-document-format-error status code sufficient,
> or would you prefer to see new status codes for each?
>

---

From: Michael Sweet <[email-masked]>
Date: Sat, 5 Mar 2011 01:21:59 -0800

On Mar 5, 2011, at 12:06 AM, Ira McDonald wrote:
> ...

media-size-name it is, then...

> protocol target of the IPP over HTTP request.

Actually, only job-id needs the printer-uri. job-uri can stand alone, per 2911...

---

From: Ira McDonald <[email-masked]>
Date: Sat, 5 Mar 2011 09:14:19 -0500

Hi Mike and Mark,

True, RFC 2911 allows "job-uri" alone to be specified
for *some* Job operations.

But RFC 2911/2910 do not specify the relationship
between "job-uri" and "printer-uri" (which is a bug).

So the later RFC 3510 ('ipp' URI Scheme) was unable
to specify any such relationship.

Which is why I've seen quite a few IPP implementations
that do NOT accept a "job-uri" value as HTTP request-URI
(i.e., as a protocol endpoint) - since it's implementation
dependent anyway, they simply refuse to honor stand-alone
"job-uri".  I have always advised my clients to avoid the
assumption that "job-uri" is a safe protocol endpoint.

IPP Everywhere cannot really fix this ambiguity.  And
just saying that "job-uri" should work won't help any.

OTOH - "printer-uri" plus "job-id" is safe and reliable.

My two cents.

Cheers,
- Ira

---

From: "Yousey, Marc" <[email-masked]>
Date: Mon, 7 Mar 2011 21:53:21 +0000

That will teach me to write an email when I'm walking out the door on Friday.

You're right Mike that I was talking about job-uuid and not job-uri.  I'm just making sure we're not adding another job specifier to the uri/id mess we have now.

Thanks,
M.

From: Ira McDonald [mailto:[email-masked]]
Sent: Saturday, March 05, 2011 6:14 AM
To: Michael Sweet; Ira McDonald
Cc: Yousey, Marc; [email-masked]
Subject: Re: [IPP] Updated JPS3 draft posted

Hi Mike and Mark,

My two cents.

Cheers,
- Ira

mailto:[email-masked]<mailto:[email-masked]>

On Sat, Mar 5, 2011 at 4:21 AM, Michael Sweet <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Yousey, Marc" <[email-masked]>
Date: Mon, 7 Mar 2011 21:55:14 +0000

Client-error-document-format-error works for me I just wasn't sure if we had a policy on whether job-state-reasons should have a matching status-code or not.  There seems to be a rough but not perfect correlation between them.

I'm not asking for new stutus-codes just clarification.

Thanks,
Marc