headers
a.s.patel | 1 May 2003 14:17
Picon

PWG-ANNOUNCE> Registration Details: June 16-20, 2003, Portland Oregon

Greetings All,

The PWG Registration page is now available at
http://www.ieee-isto.org/pwg/registration.html.  Please register to attend
the upcoming June 16-20, 2003 meetings in Portland, Oregon.

There is a daily attendance fee of US$45.00. (Payments are processed on the
first day of the meeting series.)  This fee is to cover food/beverage and
meeting accommodations at The Westin Portland.

The deadline for reserving sleeping accommodations at The Westin Portland
is May 23, 2003.  Please call +1 888 627 8401 and ask for the "PWG Printer
Working Group" rate.    If you have any problems with making your sleeping
room reservations, please contact me directly so that I may notify the
hotel.

The agenda for the meetings has been tentatively finalized as well.  Please
see below:

Monday (June 16)
     - Device Management
     - Character Repertoire
Tuesday (June 17)
        FSG Tracks
     -  FSG OP PAPI (8am-11am)
     -  FSG OP JTAPI (12pm-3pm)
     -  FSG OP Printer Driver/Renderer (3pm-6pm)
     -  FSG OP Plenary (7pm-9pm)
Wednesday (June 18)
     -  Plenary (Morning)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Lawrence | 1 May 2003 18:56

IPP> polling re: Upgrade and CONNECT support


I'm attempting to determine what features of HTTP specified by RFC
2817 (Upgrade header and CONNECT method support) have been implemented
and tested with other implementations in order to discover whether or
not the spec can be advanced to Draft Standard status.

The RFC discusses these features in the context of upgrading to HTTP
over TLS, because doing so was needed by IPP, so I expect that some
features will have been done primarily in the HTTP used by IPP clients
and servers. 

However, the protocol features it describes are actually generic to
any use of Upgrade and CONNECT.  The usage of CONNECT is (we believe)
the same as that specified in the original Internet Draft by Ari
Luotonen, which was never otherwise published as an RFC.

If you are responsible for (or knowlegable regarding) a Client,
Server, or Proxy that implements Upgrade and/or CONNECT support in
some form, would you please take a moment to comment on its support of
the specific features outlined below?  

Replies to the list you're reading this on are fine - I'm on both.
Responses sent to me off list will be treated as confidential
information unless you specify otherwise - at most, the fact that an
affirmative response was received from someone will be made known
publicly, but neither the responder nor the implementation will be
identified.

Thank you for your time.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Sweet | 1 May 2003 19:32
Favicon

Re: IPP> polling re: Upgrade and CONNECT support

Scott Lawrence wrote:
> I'm attempting to determine what features of HTTP specified by RFC
> 2817 (Upgrade header and CONNECT method support) have been implemented
> and tested with other implementations in order to discover whether or
> not the spec can be advanced to Draft Standard status.
> 
> The RFC discusses these features in the context of upgrading to HTTP
> over TLS, because doing so was needed by IPP, so I expect that some
> features will have been done primarily in the HTTP used by IPP clients
> and servers. 
> 
> However, the protocol features it describes are actually generic to
> any use of Upgrade and CONNECT.  The usage of CONNECT is (we believe)
> the same as that specified in the original Internet Draft by Ari
> Luotonen, which was never otherwise published as an RFC.
> 
> If you are responsible for (or knowlegable regarding) a Client,
> Server, or Proxy that implements Upgrade and/or CONNECT support in
> some form, would you please take a moment to comment on its support of
> the specific features outlined below?  
> 
> Replies to the list you're reading this on are fine - I'm on both.
> Responses sent to me off list will be treated as confidential
> information unless you specify otherwise - at most, the fact that an
> affirmative response was received from someone will be made known
> publicly, but neither the responder nor the implementation will be
> identified.

CUPS (http://www.cups.org/) implements HTTP Upgrade for TLS on
the client and server ends.
(Continue reading)

Permalink | Reply | 0 comments |
headers
McDonald, Ira | 2 May 2003 01:47
Favicon

RE: IPP> Document Object Spec Comments... [for Thur 5/15]

Hi Michael,

Next week's SM telecon is cancelled.

But two weeks from now (Thur 5/15) we intend to devote to 
addressing your concerns about the Document Object spec.
So, could you possibly explain a little more your various
comments below by email?  And (if you can) join the SM
telecon in two weeks?

Today, we decided to break the current Document Object
spec into _three_ specs:

1)  IPP Document object - only document specific stuff
2)  IPP Extensions for IPPFAX/PSI - only the extensions
    needed for PSI and/or IPPFAX (but NOT the higher
    REQUIRED conformance for any operation or attribute
    - that is left to the IPPFAX or PSI specs themselves)
3)  Miscellaneous IPP Extensions - stuff we want to add
    to IPP, but not on the critical path for PSI/IPPFAX

We expect that these three specs progress (to Candidate
Standards) in the numeric order above (Document object
first, because it's critical to several PWG standards 
and several FSG Open Printing standards).

[I don't understand how you can map Create-Document
to Validate-Job.  Could you explain, please?]

Cheers,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Sweet | 2 May 2003 03:25
Favicon

Re: IPP> Document Object Spec Comments... [for Thur 5/15]

McDonald, Ira wrote:
> ...
> So, could you possibly explain a little more your various
> comments below by email?  And (if you can) join the SM
> telecon in two weeks?

I don't know if I'll be able to, but if I am free I will call in.

 > ...
> [I don't understand how you can map Create-Document
> to Validate-Job.  Could you explain, please?]
> ...

The spec mentions using Create-Document to validate the format and
attributes of a document prior to submission, which is exactly what
Validate-Job does.  While Validate-Job won't reserve a slot for a
document like Create-Document, I see that particular feature of the
Create-Document object as the biggest potential security hole in
the spec with very little benefit.  Realistically speaking, if a
document format and specific job template attributes are acceptable
at one time, then they will be acceptable all the time for that
printer object.

If the Create-Document semantics are absolutely required (I don't
see that, but if so the spec should include the justification/reason
for it), then I highly recommend that we either place a limit of 1
outstanding document per job or add a new status code ("server-
error-too-many-documents"?) so that the server can enforce limits to
avoid Denial-of-Service cases.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hastings, Tom N | 4 May 2003 02:15
Picon

RE: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]

Michael,

Are you saying that a client that wants to validate *all* of the documents
before sending any should just use Validate-Job, one for each of the
documents?  If they all validate, then the client can send the documents
with Create-Job and multiple Send-Documents and they will all be accepted.
That will work usually, except for the following two use cases:

1. Use Case 1: One Printer supports multiple dissimilar devices

One case where this scenario doesn't quite work is for a Printer that is
fronting for a number of actual dissimilar devices, in which no one device
is a superset of all of the others.  For example, a duplex black and white
printer and a simplex color printer (not an uncommon mixture).  Here a
Validate-Job with "sides"='two-sided-long' for the black and white document
will succeed as will a Validate-Job with a "sides"='one-sided' and
"color-effect-type"='color' for the color document.  However, the job
containing both documents will not be able to be printed as requested on
either device.

So the Create-Job, followed by the Create-Document for each of the documents
will (MAY/SHOULD/MUST?) get a failure on the second Create-Document, if both
documents cannot be printed in the same Job.  Then the client can decide to
break the job into two jobs and submit each document as separate jobs or
find another Printer (without having sent *any* document data for either
document).  

REBUTTAL (against this use case):  But some may argue that the simple IPP
Printer "xxx-supported" model for describing the Printer's capabilities
isn't able to correctly represent a Printer that fronts for dissimilar
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Sweet | 4 May 2003 04:59
Favicon

Re: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]

Hastings, Tom N wrote:
> ...
> 1. Use Case 1: One Printer supports multiple dissimilar devices
> 
> One case where this scenario doesn't quite work is for a Printer that
> is fronting for a number of actual dissimilar devices, in which no
> one device is a superset of all of the others.  For example, a duplex
> black and white printer and a simplex color printer (not an uncommon
> mixture).  Here a Validate-Job with "sides"='two-sided-long' for the

I've never seen such a combination, but assuming that such a composite
printer object exists, it *should* be smart enough to route B&W jobs
to the B&W printer and color jobs to the color printer.  If the job
gets bound to a single output device then the implementation is no
better than one that exposes multiple printer objects.

> ...
> Then the client can decide to break the job into two jobs and submit
> each document as separate jobs or find another Printer (without
> having sent *any* document data for either document).

How is this different from the Send-Document case?

> ...
> 2. Use Case 2: client doesn't have all of the documents up front
> 
> A second use case that the Create-Document operation allows is a
> client that is collecting documents over a period of time (if the
> Printer's "multiple-operations-time-out" Printer Description
> attribute value is large enough).  For example a mail reader or a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hastings, Tom N | 4 May 2003 12:58
Picon

RE: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]

Michael wrote:

I've never seen such a combination, but assuming that such a composite
printer object exists, it *should* be smart enough to route B&W jobs
to the B&W printer and color jobs to the color printer.  If the job
gets bound to a single output device then the implementation is no
better than one that exposes multiple printer objects.

<th>
I assume that a client submitting a single job containing a black and white
document and a color document to the same Printer wanted them to be printed
together.  Perhaps, even asking for multiple copies collated, so that they
could be handed out at a meeting.  So such a composite Printer shouldn't
split up a Job, sending one document to one device and the other to the
second device.  

If the client didn't care whether the two documents came out together on a
single device as a single job, then the client should submit each document
to two separate Printers, where one controls a black and white device and
the other controls a color device.
</th>

> ...
> Then the client can decide to break the job into two jobs and submit
> each document as separate jobs or find another Printer (without
> having sent *any* document data for either document).

How is this different from the Send-Document case?

<th>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Sweet | 4 May 2003 19:56
Favicon

Re: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]

Hastings, Tom N wrote:
> Michael wrote:
> 
> I've never seen such a combination, but assuming that such a composite
> printer object exists, it *should* be smart enough to route B&W jobs
> to the B&W printer and color jobs to the color printer.  If the job
> gets bound to a single output device then the implementation is no
> better than one that exposes multiple printer objects.
> 
> <th>
> I assume that a client submitting a single job containing a black and white
> document and a color document to the same Printer wanted them to be printed
> together.  Perhaps, even asking for multiple copies collated, so that they
> could be handed out at a meeting.  So such a composite Printer shouldn't
> split up a Job, sending one document to one device and the other to the
> second device.  

<ms>
I personally don't think that IPP provides any guarantee of documents
being rendered by a single device; about the closest it *does* come
is the multiple-document-handling attribute, but even then it only
means that the final document will be combined, not that it must be
output by a single device.
</ms>

> If the client didn't care whether the two documents came out together on a
> single device as a single job, then the client should submit each document
> to two separate Printers, where one controls a black and white device and
> the other controls a color device.
> </th>
(Continue reading)

Permalink | Reply | 0 comments |
headers
McDonald, Ira | 4 May 2003 22:50
Favicon

RE: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]

Hi folks,

PSI and IPP are NOT equivalent in their operations and
semantics here!

PSI defines basic AddDocumentByValue (read IPP 'Send-Document')
and AddDocumentByReference (read IPP 'Send-URI').

PSI also defines AddDocumentByPush (not really equivalent to 
IPP 'Create-Document'), which MUST be promptly followed by 
PushDocumentDocumentDelivered (after the data has been pushed 
_out_of_band_ to one of the server offered push URI that were 
sent back in the AddDocumentByPush response message).

PSI does NOT define a 'Send-Data' inband operation.  This is
an IPP artifact.  And IPP does not define an equivalent to
PushDocumentDataDelivered (unfortunately).

Note that security is NOT an issue for AddDocumentByPush or
AddDocumentByReference because in both cases PSI REQUIRES support
only of 'http:' schemed URLs (no credentials required, typically).

Cheers,
- Ira McDonald
  High North Inc

-----------------------------
Michael Sweet wrote:

I personally don't think that Create-Job and Send-Data are necessary,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane