Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt

From: [email-masked] (Robert Herriot)
Date: Fri, 6 Jun 1997 12:42:43 -0700

> From [email-masked] Thu Jun  5 19:32:57 1997
> 
> > None of these solutions solve the problem of the Printer's 
> > resolutions-supported attribute which, hopefully, tells the
> > client exactly what resolutions the Printer supports without
> > any extraneous values and without a complicated structure
> > for the attribute.
> 
> I think this is the same problem fax has, though.
> Why would a list of pairs of integers (x-res/y-res)
> or integer & ratio (x-res, aspect ratio) have 'extraneous
> values'? Or be a 'complicated structure'?
> 

If there are attributes x-res and y-res, then according to the IPP
model, there must be an x-res-supported and a y-res-supported in the
Printer.  Suppose the printer supports 300 and 300x600 and 600 Then
both x-res-supported and y-res-supported have values of 300 and 600.
Then x-res and y-res can have any of the following 4 values 300x300,
300x600, 600x600 and 600x300.  The last value is not a legitimate value
according to my original statement.

It may be that resolutions supported by real printers and all future
printers can never have this problem. For example if the values are 300
and 300x600, then x-res-supported is 300 and y-res-supported is 300 and
600. No illegal combinations are possible with these values.

That's the problem I have with the x-res, y-res solution.  If you can
show my that this solution cannot lead to unsupported combinations,
then I would agree that a pair of integers is possibly a better solution.

Bob Herriot

---

From: [email-masked] (Robert Herriot)
Date: Fri, 6 Jun 1997 15:04:14 -0700

Your solution below requires new, more complicated mechanisms for relating
pairs of attributes.  All this is just for solving a problem for one
attribute. We have tried to keep the rules for attributes simple.  

I think it is simpler to have resolution be a set of keywords, than to
have some complex mechanism for relating two attributes or to add some
new value syntax for integerOrPairOfIntegers.

Bob Herriot

> From [email-masked] Fri Jun  6 13:45:40 1997
> 
> At 12:42 PM 6/6/97 -0700, Robert Herriot wrote:
> >
> You will need to specify the following pairs:
> x-res=300, y-res=300
> x-res=300, y-res=600
> x-res=600, y-res=600
> 
> or maybe
> 
> x-res=600, y-res=600
> x-res=300, y-res>=xres
> 
> 
> >
> >Bob Herriot
> >
> >
> >
> 
> ------------------------------------------------------------------------
> Neil Joffe                                     Email:  [email-masked]
> Software Engineer                        Voice:  +1 (408) 527-7957
> Voice Technology Engineering     Fax:     +1 (408) 527-3907
> Cisco Systems
> San Jose
> ------------------------------------------------------------------------
> 
>

---

From: Harry Lewis <[email-masked]>
Date: Mon, 9 Jun 1997 10:31:47 -0400

I know this must be an area of "clash" between DPA and the Printer MIB, but
wouldn't it be a good idea to  establish a convention which is compatible with
RFC1759 regarding Feed and CrossFeed marker addressability?

>>> Harry Lewis <<<

------- Forwarded by Harry Lewis/Boulder/IBM on 06/09/97 08:23 AM ------

        [email-masked]
        06/06/97 08:19 PM
Please respond to [email-masked] @ internet

To: [email-masked] @ internet, [email-masked] @ internet,
[email-masked] @ internet
cc: [email-masked] @ internet, [email-masked] @ internet,
[email-masked] @ internet, [email-masked] @ internet,
[email-masked] @ internet
Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt

Bob Herriot

---

From: Tom Hastings <[email-masked]>
Date: Thu, 19 Jun 1997 11:34:09 PDT

>RFC1759 regarding Feed and CrossFeed marker addressability?

The problem with having an IPP attribute that is so physical that relates
to the feed direction, is that some printers feed long edge first and
some feed short edge first (and some do either depending on how the
input tray is set up).  The requester should not have to know how the
printer is currently configured, but should be able to specify attributes
in a more printer independent and configuration independent manner.

Tom