Subject: Re: I-D ACTION:draft-ietf-fax-feature-schema-00.txt

From: James Rafferty <[email-masked]>
Date: Wed, 14 Oct 1998 18:39:28 -0400

Graham, Lloyd,  

The draft is off to a good start.   

Here are some comments, that supplement some earlier private comments:     

>1.1 Organization of this document
>
>  Section 2 specifies the overall syntax for fax feature descriptions
>  by reference to the media feature registration and syntax documents
>  [1,2].
>
>  Section 3 enumerates the feature tags that MUST be recognized and
>  processed by extended Internet fax systems, according to their
>  capabilities.
>
I have proposed similar text on the behavior of extended Internet fax
systems for inclusion in -eifax.    IMO, Section 3 should define the tags,
but not prescribe -eifax behaviour. 

...
>
>2. Fax feature schema syntax
>
>  The syntax for the fax feature schema is described by "An algebra
>  for describing media feature sets" [2].  This in turn calls upon
>  media feature tags that may be registered according to the
>  procedure described in "Media Feature Tag Registration Procedure"
>  [1].
>
>       ??Note:  The document name for [2] will change to "A
>       syntax for describing media feature sets".
>
>       Note:  Media feature registration provides a base
>       vocabulary of features that correspond to media handling
>       capabilities.  The feature set syntax provides a
>       mechanism and format for combining these to describe
>       combinations of features that may be handled by eifax
>       systems.
>
A side thought:   

I can envision a capabilities list (by whatever mechanism) in 2 different
ways.   
First, a simple list of features and range of values.  Second, a more
sophisticated

listing which shows combinations of features and thus has a more complex
expression.   Comments?   

>3. Internet fax feature tags
>
>  This section enumerates and briefly describes the feature tags that
>  MUST be recognized and processed by eifax systems and for which a
>  value SHOULD be offered in any capability announcement, according
>  to their capabilities.
>

>  That is, a number of feature tags are presented below that an eifax
>  system is expected to be able to recognize its ability or non-
>  ability to handle.
>
Again, I'd prefer that this kind of language be in the protocol documents
(such as
-eifax) which reference this document.   

So, revised text could be:  

" This section enumerates and briefly describes a set of feature tags which
is defined for use with extended Internet fax systems and applications.
These tags may also be used by other systems and applications which want to
support the related features.   "  

>  Definitive descriptions of feature tags are indicated by reference
>  to their registration per the 'conneg' registration procedure (some
>  of which are appended to this document)
>
>       NOTE:  The presence of a feature tag in this list does
>       not mean that an eifax system must have that capability;
>       rather, it must recognize the feature tag and relate it
>       to the capabilities that it does have.
>
>       Further, an eifax system is not prevented from
>       recognizing and offering additional feature tags.  The
>       list below is intended to provide a minimum vocabulary
>       which all eifax systems can use in a consistent fashion.
>
As I've noted in a previous private comment, I believe its essential that
we include a tag for the TIFF profile.  We went to a lot of trouble to
define the 

file formats and related profiles in RFC 2301 and we were only able to use
the minimum subset Profile (S) in the simple mode.   Including a profile
tag will permit extended Internet fax recipients to state exactly which
profiles they support.   Then, other feature tags can be used to indicate
values that go beyond the minimum requirements for any given profile.  

My understanding of the agreements from the August meetings of our WG and
Conneg were that the TIFF feature tag definition would be taken out of the
conneg media features draft (this has now been done) and included in a fax
schema draft.   

So, we could use the text from the -02 version of Conneg and then refine
it.   
That text was:  

"tiff (token)

   The ability to process Internet Media type image/tiff [TIFF]
   extension FX profiles corresponding to the given token. [RFC2301] defines
   several such profiles: S, F, J, C, L, M.  Others may be registered
   with IANA as part of an extension to the TIFF feature set."   

I think we can use this text as a starting point and then add to it to put
it into the style you have been using in the draft.  Other points I think
need to be made are:  

a.  When a recipient indicates support for a specific TIFF profile, this
implies that the recipient can recognize all TIFF fields supported in the
profile and can process all of the mandatory values for the fields in the
profile.   

(My comment:  So, the implication here is that the semantic meaning of the
TIFF profile is based on 
support for the minimum allowed fields and values ; if other (non-mandatory
) field values for a profile are supported, this can be reflected using the
other media feature tags)   

b.  We need to be very clear about the permitted values.  I favor the use
of the profile values as was contained in the media-features-01 draft.   

>3.1 Image Size
>
>  Feature tag name    Legal values
>  ----------------    ------------
>  pix-x               <Integer> (>0)
>  pix-y               <Integer> (>0)
>
>  Reference: "Media Features for Display, Print, and Fax" [3].
>
>
>
>  [[[The use of pixels as a measure of fax image size is currently
>  under discussion: should we use pixels or some physical unit of
>  measure?]]]
>
FYI, At the June ITU SG8 meeting, it was decided to correct the T.30 text to 
use pels (picture elements) for the horizontal dimension and "lines" in the
vertical direction in describing resolutions.    

So, for example, resolutions would be stated in 200 pels per inch
horizontal and 200 lines per inch (or per 25.4 mm), for 200 x 200.   

I personally don't have a problem with pixels, since they map well to the
TIFF profiles.   

>3.2 Resolution
>
>  Feature tag name    Legal values
>  ----------------    ------------
>  dpi                 <Integer> (>0)
>  dpi-xyratio         <Rational> (>0)
>
>  Reference: "Media Features for Display, Print, and Fax" [3], and
>  this document appendix A.
>
>  [[[The use of resolution and x/y resolution ratio values versus
>  using separate x- and y- resolutions is currently under
>  discussion]]]
>
My preference is for separate X, Y resolutions values, especially since fax
does not always use even resolutions (e.g. the 204 x 98 and 204 x 196 dpi
supported in all of the TIFF profiles.   

>3.3 Media type
>
>  Feature tag name    Legal values
>  ----------------    ------------
>  ua-media            screen
>                      screen-paged
>                      stationery

>                      transparency
>                      envelope
>                      envelope-plain
>                      continuous
>
>  Reference: "Media Features for Display, Print, and Fax" [3].
>
>  [[[The relevance of media type to Internet fax is currently under
>  discussion.  I think it is not relevant.]]]
>
Well, actually, the concept may be highly relevant in one respect.  When using
CIELAB for descriptions of the color components to be used with JPEG
compressed images, T.42 originally defined a recommended set of defaults
(i.e. for gamut range, chrominance, white point) based on "hard copy" 
applications.   Later, a separate recommended set of defaults was specified
for "soft copy" applications.   So, if JPEG color is used AND the recipient
specifies a preference for only hard copy or only soft copy applications,
this would permit the sender to fine tune the color data being sent to
produce a better image quality.   

We might want to add a note to this effect, such as:  

"Where the recipient indicates support for only a hard copy or soft copy
media, a sender of color image data may wish to adjust the color components
per the related rules of [T.42] to improve potential image quality.   

>3.4 Paper Size
>
>  Feature tag name    Legal values
>  ----------------    ------------
>  paper-size          A4
>                      A3
>                      B4
>                      letter
>                      legal
>
>  Reference: "Media Features for Display, Print, and Fax" [3].
>
>  [[[There may be some conflict or interaction between this and
>  'image size' above.]]]

Paper size and image size may be different (for example, where the image
size does not quite fill the paper size).   I think this approach works for 
fax use, at least to describe paper handling capabilities.   It also maps to 
T.30 in a pretty straightforward manner.  

>3.5 Color and greyscale
>
>  Feature tag name    Legal values
>  ----------------    ------------
>  grey                <Integer>
>                      (Typically 2,16,256,65536,16777216)
>  color               <Integer>
>                      (Typically 16,256,65536,16777216)
>
>  Reference: "Media Features for Display, Print, and Fax" [3].
>
>       NOTE: a bi-level (i.e. black-and-white only) fax image or
>       capability is indicated by the feature value 'grey=2'.
>       This is indicates the rendering capabilities of a
>       recipient or requirements of a document, and does not of
>       itself indicate a coding scheme.
>
>3.6 Coding
>
>  Feature tag name    Legal values
>  ----------------    ------------
>  image-coding        MH
>                      MR
>                      MMR
>                      JBIG
>                      JBIG-LO
>                      JBIG-T43
We should only have 2 JBIG encodings, 
one for B/W and one for the T43 lossless color.  
It is possible to have variations in stripe sizes 
for JBIG B/W, but this would be handled in 
a separate tag, I think, since it is not really 
a different encoding.   

Lloyd, do we deal with this somehow in RFC 2301?   

>                      JPEG
>  image-interleave    Strip
>                      Plane
>  color-subsampling   <Boolean>

I would think a color subsampling ratio is 
needed somewhere, maybe a separate 
tag in addition to the boolean value
entity you show here.   

>  MRC-level           <Integer> [0-7]
>  MRC-strip           Fullpage
>                      Line256
>
>  Reference: this document, appendix A.
>
>3.7 Color model
>
>  Feature tag name    Legal values
>  ----------------    ------------
>  custom-illuminant   <Boolean>
>  custom-gamut        <Boolean>
>
>  Reference: this document, appendix A.
>

>
>3.8 Preferred units
>
>  Feature tag name    Legal values
>  ----------------    ------------
>  preferred-unit      metric
>                      inch
>
This might be useful for T.30 offramps (which are technically out of scope
until we start dealing with them in other documents), but in RFC 2301, we
have specified a preferred unit of inch for consistency with traditional
use of TIFF.   So, we may need some clarifying text here if this is to be
kept in.  

Does this tie into how we state resolution?   

A proposed note for now:   

Note:   The units of TIFF image files per [RFC 2301] are inch based.   

>  Reference: this document, appendix A.
>
>4. Examples
>
>  <<<to be provided>>>
>
>  <<<Suggested example subjects follow>>

Since our scope is "Internet Fax", I think we should
have our examples based on that.  In other words, 
start with a "simple mode" example and build up from there.  

>4.1 Simple fax machine
Revise to be Simple Mode Internet Fax System 

Features list:  

Mandatory

TIFF: S

Optional (implied already by TIFF S):   

image-coding: MH
paper-size=A4
dpi= ?
dpi-xyratio = ?
ua-media=stationery
units=inch

4.2   Add "High End Black and White Internet Fax System" 

(this would include support for B/W JBIG and be equiv to what 
some marketing folks are calling Super G3, except that Internet
fax functionality would be added).    

>4.2 Grey-scale fax machine
>
Change to 4.3 "Grey scale Internet Fax System"  or
omit (since no-one does this so far)

>4.3 Full-colour fax machine
>
Change to 4.4 "Full Colour Internet Fax System - JPEG Based"

(Lloyd might want to add an MRC Internet Fax System"   
>4.4 PC-based e-mail recipient 
>
Maybe change to "PC-Based e-mail recipient with JPEG-based Internet fax
support"   

>5. Security considerations
>
>  <<<to be provided>>>
>
Threats: 

Most of these would pertain to what would happen if the capabilities
information got into the hands of someone who wanted to abuse it.    
This document only specifies a list of capabilities which will help a sender'
determine what types of TIFF files can be successfully processed by the 
recipient and does not specify the mechanisms by which these capabilities 
would be made known.   Implementors and users should take steps to ensure
that these capabilties are provided to authorized persons, systems and
agents.   

1.  Unsolicited Bulk Mail - IF it is known that a recipient can process
certain types of images, they may be targeted by bulk mailers that want to
send such images.  

>
>8. References
>
>[1]  "Media Feature Tag Registration Procedure"
>     Koen Holtman, TUE
>     Andrew Mutz, Hewlett-Packard
>     Ted Hardie, NASA
>     Internet draft: <draft-ietf-conneg-feature-reg-03.txt>
>     Work in progress, July 1998.
>
>[2]  "A syntax for describing media feature sets"
>     Graham Klyne, 5GM/Content Technologies
>     Internet draft: <draft-ietf-conneg-feature-syntax-00.txt>"
>     Work in progress, September 1998.
>
>[3]  "Media Features for Display, Print, and Fax"
>     Larry Masinter, Xerox PARC
>     Koen Holtman, TUE
>     Andrew Mutz, Hewlett-Packard
>     Dan Wing, Cisco Systems
>     Internet draft: <draft-ietf-conneg-media-features-02.txt>
>     Work in progress, September 1998.
>
>[4]  "Internet fax feature mapping from Group 3 fax"
>     Lloyd McIntyre, Xerox Corporation
>     Graham Klyne, 5GM/Content Technologies
>     Internet draft: <draft-ietf-fax-feature-T30-mapping-00.txt>
>     Work in progress, August 1998.
>
>[5]  "Extended Facsimile Using Internet Mail
>     Larry Masinter, Xerox Corporation
>     Dan Wing, Cisco Systems
>     Internet draft: <draft-ietf-fax-eifax-04.txt>
>     Work in progress, September 1998.
>
>[6]  "Procedures for document facsimile transmission in the general
>     switched telephone network"
>     ITU-T Recommendation T.30
>     International Telecommunications Union
>     July 1996
>
Add T.42, maybe T.43 as well (technically T.44 not yet available for
reference)

>Appendix A: Feature registrations
>
>  [[[This appendix contains registrations of media features, that are
>  specific to fax and for which no applicable registration already
>  exists.]]]
>
Right; this belongs here.  

Whew!  Thats it for this round of comments.  

James 

*------------------------------------------------*
James Rafferty			
President, Human Communications 	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email:  [email-masked]
	 [email-masked]

HC Web Site:  http://www.humancomm.com  
*---------------------------------------------------

---

From: Dan Wing <[email-masked]>
Date: Wed, 14 Oct 1998 18:32:23 -0700

>5. Security considerations
[...]

Also see section 4.1 of draft-ietf-fax-eifax, "Inaccurate Capabilities 
Information".

-Dan Wing

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Wed, 14 Oct 1998 19:04:11 -0700

James,
Some personal responses to your comments.

> -----Original Message-----
> From:	James Rafferty [SMTP:[email-masked]]
> Sent:	Wednesday, October 14, 1998 3:39 PM
> To:	Graham Klyne; Lloyd McIntyre
> Cc:	[email-masked]
> Subject:	Re: I-D ACTION:draft-ietf-fax-feature-schema-00.txt
> 
> Graham, Lloyd,  
> 
	[McIntyre, Lloyd]  Sounds reasonable.

> listing which shows combinations of features and thus has a more
	[McIntyre, Lloyd]  No comment.

> support the related features.   "  
	[McIntyre, Lloyd]  Sounds reasonable.

> values that go beyond the minimum requirements for any given profile.
	[McIntyre, Lloyd]  I agree.

> it into the style you have been using in the draft.  
	[McIntyre, Lloyd]  Sounds good.
> Other points I think
	[McIntyre, Lloyd]  Sounds reasonable.

> I personally don't have a problem with pixels, since they map well to
	[McIntyre, Lloyd]  I believe the use of pixels would be more
universal.

> supported in all of the TIFF profiles.   
	[McIntyre, Lloyd]  I agree, especially since X, Y resolutions
map to TIFF fields.

> applications.  
	[McIntyre, Lloyd]  True.
>  Later, a separate recommended set of defaults was specified
> for "soft copy" applications.   
	[McIntyre, Lloyd]  Studied but not specified as in the case of
hard copy. Provisions were, however, made to define optional (custom)
gamuts that could be media specific. This is consistent with the current
tags under color model.
> So, if JPEG color is used AND the recipient
	[McIntyre, Lloyd]  True.
> "Where the recipient indicates support for [McIntyre, Lloyd] media
> that falls outside the values defined for hard copy  [McIntyre, Lloyd]
> in Rec. T.42 (i.e. soft copy), a sender of color image data may wish
> to adjust the color components
	[McIntyre, Lloyd]  Both are indeed need. For scanned input and
profiles other than Profile M (MRC), there is a one to one mapping for
the image and paper width. For synthetic images, all best are off. For
length the is usually a disparity. It must be noted that TIFF has no
provision for paper size. There are image dimension fields which MUST
contain the actual image width and height or there will be corruption.

> a separate tag, I think, since it is not really 
	[McIntyre, Lloyd]  Given that these are to be generic tags,
available for use with other applications, there actually needs to be
three JBIG encodings: 1. JBIG-T82    2. JBIG-T85    3. JBIG-T43. The is
also a similar need for two JPEG encodings: 1. JPEG-T.81   2.
JPEG-T4ANNEX_E.
> Lloyd, do we deal with this somehow in RFC 2301?   
	[McIntyre, Lloyd]  RFC2301 contains the TIFF required field
"RowsPerStrip" (n: number of scanlines per TIFF strip)  field. There is
no provision for retaining the 128 default count or the variable option
that may be used in a T.85 stream. The size of the TIFF strip is left to
the TIFF writer. The same situation is true in Profile M where multiple
stripes of various sizes within a page may be used. It is our intention
to add a requirement to Profile M stating that the TIFF strip size
SHOULD retain the line count of the data stream stripe from which the
file is being written. It appears that we should make a similar add to
Profile J and L (JBIG bi-level and multi-level) or place this
requirement under the general requirements sections of "2.1.3 TIFF File
Structure for Fax Applications" and the "RowsPerStrip(278)" field of
"2.2.1 TIFF Fields required for all fax modes". It would also be
appropriate under "StripRowCounts(559)" field of "8.2.3 New Fields".

> >  Feature tag name    Legal values
	[McIntyre, Lloyd]  There needs to be adds for colour space or
colour coding (i.e. CIE L*a*b* per Rec. T.42 and palette per Rec. T.43).

> use of TIFF.   So, we may need some clarifying text here if this is to
	[McIntyre, Lloyd]  This is another one without a corresponding
TIFF tag.

> dpi= ? [McIntyre, Lloyd]  200 
> dpi-xyratio = ? [McIntyre, Lloyd]  100/200 or 200/200 
> ua-media=stationery
> units=inch
> 
> 
> 
> reference) [McIntyre, Lloyd]   T.85 should be added along with T.42,
> T.43 and T.44. 
> 
>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 15 Oct 1998 23:17:23 +0100

At 18:39 14/10/98 -0400, James  Rafferty wrote:
[...]
>IMO, Section 3 should define the tags,

Agreed.

>listing which shows combinations of features and thus has a more complex

I think both are available within the conneg -syntax- framework, if one
allows a small amount of syntactic 'fluff'.  A simple list of features and
value ranges would be, for example:

  (& ( dpi=[100,200] )
     ( color<=256 )
     ( width<=2550/254 )
     ( length<=2970/254 )
     ( paper-size=A4 )
     ( image-coding=[MH,MR,MMR,JBIG,JBIG-T43,JPEG] )
     ( image-interleave=strip )
     ( color-subsampling=FALSE )
     ( MRC-level<=5 )
     ( MRC-strip=[fullpage,line256] )
     ( custom-illuminant=TRUE )
     ( custom-gamut=FALSE )
     ( preferred-unit=inch ) )

This simple combining approach works as long as no feature tag is repeated.
 To capture dependencies between features (as exhibited by T.30
capabilities) then more complex forms of expression are needed.  But it
would still be built upon this basic form.

>>  MUST be recognized and processed by eifax systems [...]

>(such as-eifax) which reference this document.   

Agreed.

>values that go beyond the minimum requirements for any given profile.  

I believe that rather than defining the TIFF profiles as new feature tags,
we should publish them in the form of "auxiliary predicates" (as described
in the conneg -syntax- draft.  The fax schema, in conjunction with the
conneg -syntax- framwork, is capable of capturing all the profile features,
and other levels of functionality between.

I recognize the value of the TIFF profiles, and believe that they do have
aplace in this document.  I'm just suggesting that they shouldn't be new
feature tags.  The reason for this resistance is that the capability
identification framework has maximum value if there are fewer ways of
expressing the same capability, because one is less likely to have one
system use one form of expression, and onother expect a different form.

By publishing the TIFF profiles in the form of auxiliary predicates, we
show exactly how they can be expressed in the underlying capability
expression form, thus allowing a maximum useful level of interaction with
other systems that don't explicitly recognize TIFF profiles.

>other media feature tags)   

This would be formalized in the approach I propose.

>of the profile values as was contained in the media-features-01 draft.   

This issue goes away in the approach I propose.

[...]

>I personally don't have a problem with pixels, since they map well to the

In my opinion, we should use physical dimensions rather than pixels,
because when a device (like a fax) offers a range of resolutions, these are
not generally reflected in the physical image size, though they would
affect the pixel size.

Thus, using physical dimensions, it is not necessary to specify a different
image size with each resolution option. I.e. the image *size* is generally
the same, even though the resolution may be 200dpi, 300dpi, 400dpi;  this
would not be generally true if pixel based measures were used.

>supported in all of the TIFF profiles.   

So is mine.

But there is also a body of opinion that more devices use non-differential
than differential resolutions.  Using the 'n/m' notation for rational
numbers, I think a workable compromise is possible:

    (| (& (dpi=204) (dpi-xyratio=204/98) )
       (& (dpi=204) (dpi-xyratio=204/196 ) )

etc.  The advantage of this is that, although it may look a little messy,
it simply contains the x- and y- resolution values.  A receiver could not
rely on the ratio containing the actual resolutions, but the computation
required to sort this out is quite trivial.

[...]
>per the related rules of [T.42] to improve potential image quality.   

OK, done.

>size does not quite fill the paper size).

Agreed, but...

>   I think this approach works for 

...specifically in the case of T.30 fax there are separate capabilities for
different sizes of paper.  Some relate to tokenized paper size.  Others
relate to width and length described separately.

My personal view is that, in the case of fax, we are pretty much talking
about the imageable area -- T.4 contains a discussion of "guaranteed
reproducible area" etc.  I think references to paper size are often to do
with the physical form-factor of the resoluting document;  e.g. kind of
folder it is to be stored in (NA-letter vs A4).  Printers that handle a
given size of paper often have quite significant margins on which they
cannot actually print, so the paper size and imageable areas are different
quantities.

In the case of fax, judging by the T.30 and T.4 specs, it seems that paper
size *is* about imageable area.  Hence my view that we may be better
dealing with physical dimensions of the imageable area, and not worry too
much about paper size.

>one for B/W and one for the T43 lossless color.  

We did agree, I recall, that we should capture the semantics of T.30.  And
T.30 offers this range of coding options.

But an idea to address your concern:
Define separate feature tags:  one as you indicate, and another that acts
as a modifier, and is noted as being intended for use when dealing with
traditional fax machines.  That way, some of the arcane oddments of T.30
don't get propagated into other environments.

>a separate tag, I think, since it is not really 

There is a separate tag suggested for image interleave stripe size.

>tag in addition to the boolean value

Er... I did discuss this with Lloyd, and it did seem to get rapidly
complicated.  Is there a real need for/use of colour sub-sampling other
than 4:1:1?  If so, then we should try and accomodate it.  Are other
subsamplig ratios always square (as in (1:1:1, 4:1:1, 9:1:1, 16:1:1, etc.,
or are rectagular colour subsamples possible (e.g. 1*2:1:1, 2*1:1:,
2*3:1:1, etc.).  Are the colour channels always subsampled as the same
frequency?  (Or could 4:4:1 happen?)

I'm throwing up these questions so we can understand where the line is
being drawn.

And finally, a possible compromise:  rather than answer the awkward
questions above, simply change the type of the feature tag to <token>, with
defined values of "SS-1-1-1" and "SS-4-1-1".  Other values could be defined
in future.

>use of TIFF.   So, we may need some clarifying text here if this is to be

It's here to capture T.30 semantics.  As you will know, certain T.30
capabilities have slightly different meanings when used with inch- or
metric- units.  Specifically, some resolution options.

The purpose in keeping this as a feature tag is to avoid possible image
conversion and distortion that might occur if a sender or receiver could
render accurately for either metric- or inch-based resolutions.

But as I write this, I think the semantics could be captured completely in
the resolution value options.

>Does this tie into how we state resolution?   

No:  resolution is *always* expressed in dpi.

>Note:   The units of TIFF image files per [RFC 2301] are inch based.

OK.

>start with a "simple mode" example and build up from there.  

OK.

>Revise to be Simple Mode Internet Fax System 

This is my revised example, based on your comments:

# This example describes the capabilities of a typical 
# simple mode Internet fax system.  Note that TIFF 
# application S is required to be supported by such a 
# system.
# (& ( dpi=200 )
#    ( dpi-xyratio=[200/100,200/200] )
#    ( grey=2 )
#    ( paper-size=A4 )
#    ( image-coding=MH )
#    ( ua-media=stationery )
#    ( preferred-unit=inch ) )

>4.2   Add "High End Black and White Internet Fax System" 

# This would include support for B/W JBIG and be equivalent 
# to what is sometimes called "Super G3", except that 
# Internet fax functionality would be added.
# (& (| (& (dpi=200) (dpi-xyratio=200/100) )    // 200*100
#       (& (dpi=200) (dpi-xyratio=1) )          // 200*200
#       (& (dpi=300) (dpi-xyratio=1) )          // 300*300
#       (& (dpi=400) (dpi-xyratio=1) ) )        // 400*400
#    ( grey=2 )
#    ( paper-size=A4 )
#    ( image-coding=[MH,MR,MMR,JBIG] )
#    ( preferred-unit=inch ) )

>certain types of images, they may be targeted by bulk mailers that want to

I've got that.  I think it bears some review and debate, so I've put it in.

>Add T.42, maybe T.43 as well (technically T.44 not yet available for

OK.  Can you provide me with full references for those that are incomplete
in the T30-mapping draft, please?  I think that will be pretty much all of
the ITU references we'll ever need!

>Whew!  Thats it for this round of comments.  

Whew indeed!  Thanks for that.  That's added some more meat to the draft.

#g

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Thu, 15 Oct 1998 18:47:39 -0700

Please see my comments below. There are some items for which I reserve
my comment until I have concurred with some more knowledgeable
colleagues.

Lloyd

> From:	Graham Klyne [SMTP:[email-masked]]
> Sent:	Thursday, October 15, 1998 3:17 PM
> To:	James Rafferty
> Cc:	Lloyd McIntyre; [email-masked]
	[McIntyre, Lloyd]  snip ------- 

> other systems that don't explicitly recognize TIFF profiles.
	[McIntyre, Lloyd]  I understand your thoughts and would tend to
agree, however, I would like to concur with my colleagues before
providing a position.

> This would be formalized in the approach I propose.
	[McIntyre, Lloyd]  See above.

> This issue goes away in the approach I propose.
	[McIntyre, Lloyd]  See above.

> would not be generally true if pixel based measures were used.
	[McIntyre, Lloyd]  This is true when the process is confined to
conventional fax. IFax sets new bounds where this not necessarily true.
Synthetic images and MRC blows this away. TIFF was designed to deal with
a more flexible world and thus the requirement for the image size to be
in pixel and correspond directly to the coded image size rather than
paper size.

> required to sort this out is quite trivial.
	[McIntyre, Lloyd]  I could live this.

> >Well, actually, the concept may be highly relevant in one respect.
> When
> using
> reproducible area" etc. 
	[McIntyre, Lloyd]  This reference is to the receive side where
it is common knowledge that printers require margins. The scanner,
however, images most of the paper. I say most because the scanners
actually implement a margin to eliminate paper edge shadow effects.
>  I think references to paper size are often to do
> folder it is to be stored in (NA-letter vs A4). 
>  Printers that handle a
	[McIntyre, Lloyd]  True.

> dealing with physical dimensions of the imageable area, and not worry
	[McIntyre, Lloyd]  We must, however, be able to indicate the
actual size (in pixels) of the coded image data. If this is not accurate
there will be a problem at the rendering side.

> don't get propagated into other environments.
	[McIntyre, Lloyd]  This is not an oddment. Please see my
previous note where I propose a generic "stripe size" tag to be applied
to all coding types.

> defined values of "SS-1-1-1" and "SS-4-1-1".  Other values could be
	[McIntyre, Lloyd]  I would tend to agree with <token>, however,
give me the chance to consult with my colleagues.

	[McIntyre, Lloyd]  True. 
> the resolution value options.
	[McIntyre, Lloyd]  I would agree if a device would indicate only
one of say 408x391  vs. 400x400 to reflect its native resolution.
Unfortunately the Japanese corrupted the intent by indicating both in
some of their products. They further degrade the intent by activating
both the inch and preference bits. This is why, in my previous note, I
said that it is a political issue. I have talked myself into accepting
either outcome.

> # (& (| (& (dpi=200) (dpi-xyratio=200/100) )    // 200*100
	[McIntyre, Lloyd]  Why did you not express dpi-xyratio=2?
> #       (& (dpi=400) (dpi-xyratio=1) ) )        // 400*400
	[McIntyre, Lloyd]  How about (| ( paper-size=A4 )( paper-size=B4
)) ?
> #    ( image-coding=[MH,MR,MMR,JBIG] )
	[McIntyre, Lloyd]  Should this be (| (image-coding=MH)
(image-coding=MR)(image-coding=MMR)(image-coding=JBIG)) ?

---

From: Graham Klyne <[email-masked]>
Date: Fri, 16 Oct 1998 15:59:39 +0100

At 18:47 15/10/98 -0700, McIntyre, Lloyd wrote:
[...]
>in pixel and correspond directly to the coded image size rather than

Please see separate message "Resolution, Width and Height" for my latest
position.

The more I think about it, the more "unreal" (i.e. virtual) this
pixel-based world seems to be.  The only case I can think of where
pixel-based dimensions are really useful is a display screen.  Other cases
seem to be dominated by physical dimension:
- Fax
- Printer
- Image for insertion into another document (having an n*m pixel image is
unhelpful unless you know the resolution at which the document is being
prepared -- in my experience, pixel-based images are a pain to work with in
a compound document).
- Even some display screens (e.g. Macintosh systems)

I accept that, at some internal level, TIFF images must be measured in
pixels.  But, other than in the display screen case, this measurement has
to be reconciled with some physical measurement before the image is
actually rendered.

>there will be a problem at the rendering side.

I think this can be achieved with physical size + resolution.  Using
rational numbers expressed as integer ratios, physical dimension and
resolution can be matched so that there is no loss of accuracy.  E.g. using
figures from Table 1/T.4, to represent a 1728-pixel wide A4 scanner.  The
scanner is quoted as being 1728 pixels per 219.46mm,
(where there exactly 25.4 mm/inch).  Thus we can say:

    Width      = 21946/2540 (inches)
    Resolution = 1728*2540/21946 (dpi) = 4389120/21946 (dpi)

Using this data, the pixel dimension is recovered as Width*Resolution:

    Pix-x = (21946/2540)*(4389120/21946)

which, by eliminating common factors "top and bottom" can be seen to be
identically equal to 1728, without any risk of rounding errors.  Computer
arithmetic can be expected to handle this accurately as long as maximum
integer values are not exceeded and the calculation is done in the right
sequence.

>previous note where I propose a generic "stripe size" tag to be applied

Ah... I think I misunderstood that proposal.  Could you e-mail a detail
candidate proposal for inclusion in the schema memo?  Then we can adjust
the other feature tags accordingly.

[...]
>one of say 408x391  vs. 400x400 to reflect its native resolution.

Or indicate both cases if (a) it was genuinely able to handle them, or (b)
was prepaped to accept the distorted image as being "as good as" the original?

>said that it is a political issue. I have talked myself into accepting

Occam's Razor:  It sounds as if we should drop 'preferred-units' and rely
on resolution, unless a political (or other) consideration clearly suggests
otherwise.

>	[McIntyre, Lloyd]  Why did you not express dpi-xyratio=2?

That would be perfectly valid.  I used the 200/100 form because you can see
exactly where the numbers come from; i.e. the x- and y- resolution values.

>	[McIntyre, Lloyd]  How about (| ( paper-size=A4 )( paper-size=B4

That's good:  per <draft-ietf-conneg-feature-syntax-xx>, the shorthand for
this is
  ( paper-size=[A4,B4] )

>(image-coding=MR)(image-coding=MMR)(image-coding=JBIG)) ?

That would be correct.  This is a shorthand form with the same meaning.

Actually, I just noticed that I didn't properly introduce that in -syntax-.
 The only place it appears is in the rewriting rules:

  5.1.3 Replace set expressions

  Replace all "set" instances in the goal predicate with equivalent
"simple" forms:

    T = [ E1, E2, ... En ]  -->  (| (T=[E1]) (T=[E2]) ... (T=[En]) )
    (T=[R1..R2])            -->  (& (T>=R1) (T<=R2) )
    (T=[E])                 -->  (T=E)

I've updated my copy of the -syntax- draft.

#g

------------
Graham Klyne
([email-masked])