Subject: RE: More on Adobe concerns

From: "McIntyre, Lloyd" <[email-masked]>
Date: Sun, 18 Mar 2001 22:14:49 -0800

I would like to respond to three points in Mr. Foshee's comments. 

1. Mr. Foshee is mistaken with regard to TIFF 7 being the reference for
TIFF-FX. TIFF 6 is the base on which TIFF-FX is build, please see Section
1.1 Scope. As far we know, there is no publicly available TIFF 7 spec. 

2. Given that the authors of TIFF-FX, with exception of Mr. Zilles of Adobe,
have not had access to the TIFF 7 draft prior to TIFF-FX being issued as
Proposed Standard RFC 2301, it is not possible to claim that TIFF-FX is
based on TIFF 7. On March 15 and June 1, 1999, Mr. Foshee kindly provided
Dr. Buckley and myself with our only glimpses of the TIFF 7 draft. By then,
TIFF-FX had already been a Proposed Standard for a year, the
interoperability testing had been completed and the Implementation Report
issued (on March 9, 1999). 

3. At no time during the multiple engagements between Mr. Foshee, Mr.
Buckley and myself has Mr. Foshee stated any deficiency of TIFF-FX relative
to the TIFF grant provided by Abode to the IETF for the development of
TIFF-FX.

Lloyd

> -----Original Message-----
> From: Scott Foshee [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 7:35 PM
> To: Ned Freed; Patrik Faltstrom; [email-masked]; Claudio Allocchio;
> Hiroshi Tamura; James Rafferty; Steve Zilles; "McIntyre
> Lloyd"@Adobe.COM; McIntyre, Lloyd; Glenn Parsons; Scott Bradner; David
> Crocker
> Cc: [email-masked]
> Subject: More on Adobe concerns
> 
> 
> 
> Thanks to Mr. Rafferty for his timely response to my e-mail; 
> it has helped
> me to understand where some of the confusion lay.  It is my hope this
> e-mail helps clarify some of our concerns.  Please accept my 
> apology if my
> articulation of the Adobe position is in any way unclear.
> 
> Adobe has maintained the TIFF standard as a community 
> resource in addition
> to it being a key capability of many of our applications.  
> Its primary use
> is in the wrapping of photographic type image data.  The 
> ability of Adobe
> and our customers to use TIFF in an unencumbered manner is an 
> essential
> element to it being a resource useful to Adobe, our 
> customers, and the many
> organizations with products based on TIFF.  Adobe seeks to 
> maintain TIFF as
> an image file format unencumbered by royalty fees or other 
> restrictions.
> 
> Although Adobe has not participated in TIFF FX development 
> since the spring
> of 1998, I have been in contact with the TIFF FX editors on numerous
> occasions spanning from 1998 to the present.  Throughout, I 
> have indicated
> that the candidate TIFF 7 specification upon which TIFF-FX is 
> based has not
> been approved.  Thus, TIFF FX is not a valid use of our license
> grant.....due to the portions of the TIFF FX document that 
> depend on TIFF 7
> technology (rather than TIFF 6).  This is primarily due to 
> the M profile.
> As TIFF FX editors, I would have expected Mr. Buckley or Mr. 
> McIntyre to
> communicate this deficiency to the IETF rather than progress 
> the work. 
> 
> Regardless, Adobe continues to be concerned regarding the 
> IESG moving TIFF
> FX forward.  Adobe remains supportive of the efforts of the TIFF FX
> committee and is willing to review proposals for changing 
> TIFF Version 6 as
> an alternative to the IETF changing TIFF FX.  The Candidate 
> TIFF submission
> form as explained in the TIFF policy document is the 
> appropriate method of
> submitting change proposals.  Before TIFF FX moves any 
> further forward, we
> would like to review Xerox's response to our December 21 e-mail and
> understand the IETF position.
> 
> Please use me as your point of contact within Adobe regarding 
> all TIFF and
> TIFF FX matters.  I will be attending the March 19th Internet 
> Fax meeting.
> We look forward to hearing from the IETF as soon as possible.
> 
> Sincerely,
> 
> Scott Foshee
> 
> 
> 
> Scott Foshee, Ph.D.			v: 408-536-4299
> Adobe Systems Inc.			f: 408-537-4198
> 345 Park Ave.			[email-masked]
> San Jose, CA			http://www.adobe.com
>

---

From: [email-masked]
Date: Mon, 19 Mar 2001 11:09:51 -0800 (PST)

draft-ietf-fax-minaddr-v2-02.txt
Minimal GSTN address format in Internet Mail
 
Section 1., last paragraph. "whole GSTN addressing" ->
"entirety of GTSN addressing". Also delete
": there is some work in progress in the field, where also
a number of optional  standard extensions are being
defined." -- such a comment is inappropriate in a draft
standard.

Section 2.1, first paragraph. "purpouse" -> "purpose".

Section 2.1, third paragraph. "within minimal" ->
"within the minimal"

Section 2.1, sixth paragraph. "also permit" -> "also
permits"

Section 2.1, implementor's note. The recommendation

  User Agents SHOULD remove written-sep elements before
  submitting messages to the Message Transport System.

is problematic and needs to either be revised or removed.
The problem is that this can be interpreted as giving MUAs
the right to remove periods and dashes from any address that
happens to meet the syntactic requirements set forth in this
document. But this is in direct conflict with the principle
that agents not responsible for a domain have no business
mucking around in the left hand sides of addresses associated
with that domain.

Of course a MUA that converts a phone number into an
address of this sort is entitled to remove any separators
it finds. So one way to fix this is to say that MUAs
composing such addresses from GSTN information SHOULD
remove any separators. But given that all conformant
implementations have to accept such separators, I question
whether a better approach is just to remove this suggestion
entirely.

Section 2.2, first paragraph. "follows:" -> "are:"

Section 2.2, note. This can be construed as saying that
qualif-type1 qualifiers that you don't recognize are
illegal. I suggest changing this to read:

Note: These examples are given as illustrations only; they
      do not necessarily represent valid pstn-addresses.

Section 3., note. Reword

Note: both in the SMTP envelope and in the message headers, the
      standards permit the use of "domain names" or "domain 
      literals" in addresses.

as

Note: The use of "domain names" or "domain literals"
      is permitted in addresses in both the SMTP envelope
      and message header fields.

Section 4, implementors' note. This section talks about how
pstn-address information has to conform to RFC822/RFC1123
syntax requirements. This isn't quite right; what has to
conform to RFC822 syntax requirements is the pstn-email
string in its entirety. The current text can be read as
requiring quotes immediately surrounding pstn-address, which
could result in nonsensical stuff like

    /"service=number/foo=bar blech"/@domain

I suggest adding double quotes to the pstn-address syntax
(so it is clear that they surround the entire local-part) and
saying that RFC822/RFC1123 specify the syntax rules that
determine when they need to be present. 

Section 4.2, note. This should also be changed to something
like:

Note: These examples are given as illustrations only; they
      do not necessarily represent valid pstn-addresses.
      
Section 7., first paragraph. Delete "ones".

Section 7., second paragraph. "fulfil" -> "fulfill"

****

draft-ietf-fax-faxaddr-v2-02.txt
Minimal FAX address format in Internet Mail

Section 2., second note. 'the "#" character should be used' ->
'the "#" character be used'.

Section 2.2, note. "the" -> "The"

Section 3., first paragraph. "has got" -> "has"

Section 3., note. Reword

Note: both in the SMTP envelope and in the message headers, the
      standards permit the use of "domain names" or "domain
      literals" in addresses.

as

Note: The use of "domain names" or "domain literals"
      is permitted in addresses in both the SMTP envelope
      and message header fields.

Section 4, implementors' note. This has the same problem as
the same section in draft-ietf-fax-minaddr-v2-02.txt, and it
needs to be resolved in the same way.

Section 4.2, note. "the" -> "The".

Finaally, ann RFC editor note saying that references to RFC2303bis
need to be replaced with the RFC number for
draft-ietf-fax-minaddr-v2-02.txt and references to RFC2304bis need to
be replaced with references to this document's RFC number should be
added.

That's it!

				Ned