All,
I have submitted a boatload of errata for 3382 to fix all of the spots where the wrong units were used and to add a normative reference to PWG 5100.3.
On Nov 8, 2011, at 3:29 PM, Tom Hastings wrote:
> I agree that it would be good to fix RFC 3382 to use the same 100th of mm units that are used in other IETF Recommendations and PWG standards for media sizes.
>> But to understand how this happened, RFC 3382 was written many years before other standards in order to define how the ‘collection’ data type could be used to define attributes. Because it was an RFC, it had to go through the lengthy IETF process (much longer than the PWG standards process), so it was published after the other PWG standards that defined attributes with media size units for the first time using the 100th of mm units. The idea we had in writing up the “media-col” example in RFC 3382, was to show how the ‘collection’ data type “could” be used. That is why we used the subjunctive (“might”) for the description of the “media-size-supported” (1setOf collection) attribute:
>> For example, "media-size-supported" might have the values {{x-
> dimension:210, y-dimension:297},{x-dimension:297, y-
> dimension:420}} to show that it supports two values of "media
> size": A4 (210x297) and A3 (297x420). It does not support
> other combinations of "x-dimension" and "y-dimension" member
> attributes, such as 210x420 or 297x297, and it does not support
> non-enumerated values, such as 420x595.
>> Tom
>> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Zehler, Peter
> Sent: November 08, 2011 08:48
> To: Michael Sweet
> Cc: IPP at pwg.org> Subject: RE: [IPP] media-size unit problem in rfc3382
>> Mike,
>> I know it’s confusing; it confused some people here. One thing, other than the inconsistent differences, that contributed to their confusion was that RFC3382 was publish in September of 2002 and PWG5100.3 was published in February of 2001. Their initial assumption was that newer spec should be correct. They did not read the fine print in section 5 that indicates the definitions are informative. Furthermore there is no reference, normative or informative, that points to the official definition.
>> I’d like to see the 6 mistakes in rfc3382 corrected. It might also be a good idea to include at least an informative reference to PWG5100.3.
>> Pete
>>> Peter Zehler
>> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>> From: Michael Sweet [mailto:msweet at apple.com]
> Sent: Tuesday, November 08, 2011 11:26 AM
> To: Zehler, Peter
> Subject: Re: [IPP] media-size unit problem in rfc3382
>> Pete,
>> The media-col definition in 3382 was informative and never registered.
>> (and yes this is confusing)
>> On Nov 8, 2011, at 4:31 AM, Zehler, Peter wrote:
>>> All,
> The units for media-size in rfc3382 are incorrect. The examples in rfc3382 are inconsistent. It is my understanding that current implementations from multiple vendors use hundredth of a millimeter.
>> Rfc3382:
> 3.1 4a – example is in mm
> 5.1.2.1 – defines units as inches
> 5.1.2.2 - defines units as inches
> 7.2 – example in inches
> Appendix A – example in inches
> Appendix B – example in inches
>> PWG5100.3:
> 3.13.8.1 - defines units as hundredths of a millimeter
> 3.13.8.1 - defines units as hundredths of a millimeter
> 3.13.8.3.1 - defines units as hundredths of a millimeter
> 3.13.8.3.2 - defines units as hundredths of a millimeter
>> PWG5105.1:
> 7.1 - defines units as hundredths of a millimeter (references 5100.3)
>> PWG5108.1:
> 4.3.1 – does not call out unit but references 5100.3
> 5.2.1 - defines units as hundredths of a millimeter (references 5100.3)
>>>>> Peter Zehler
>> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean. _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>> __________________________________________________
> 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.
__________________________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20111110/4771f97c/attachment-0001.html>