At 07:31 06/09/97 PDT, Harry Lewis wrote:
>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?
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
>>>>> Harry Lewis <<<
>>>------- Forwarded by Harry Lewis/Boulder/IBM on 06/09/97 08:23 AM ------
>>ipp-owner at pwg.org> 06/06/97 08:19 PM
>Please respond to ipp-owner at pwg.org @ internet
>>>To: njoffe at cisco.com @ internet, masinter at parc.xerox.com @ internet,
>Robert.Herriot at Eng.Sun.COM @ internet
>cc: ipp at pwg.org @ internet, MONTULLI at netscape.com @ internet,
>MUTZ at hplms26.hpl.hp.com @ internet, dwing at cisco.com @ internet,
>andy_mutz at hp.com @ internet
>Subject: Re: IPP> Re: draft-mutz-http-attributes-02.txt
>>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 njoffe at cisco.com Fri Jun 6 13:45:40 1997
>>>> At 12:42 PM 6/6/97 -0700, Robert Herriot wrote:
>> >
>> >> From masinter at parc.xerox.com 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.
>>>> 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: njoffe at cisco.com>> Software Engineer Voice: +1 (408) 527-7957
>> Voice Technology Engineering Fax: +1 (408) 527-3907
>> Cisco Systems
>> San Jose
>> ------------------------------------------------------------------------
>>>>>>>>>