headers
Internet-Drafts | 23 Feb 2005 21:49
Picon
Favicon

I-D ACTION:draft-ietf-fax-gateway-protocol-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Fax Working Group of the IETF.

	Title		: Internet FAX Gateway Requirements
	Author(s)	: K. Mimura, et al.
	Filename	: draft-ietf-fax-gateway-protocol-13.txt
	Pages		: 12
	Date		: 2005-2-23
	
To allow connectivity between the general switched telephone network
facsimile service (GSTN fax) and the e-mail based Internet Fax service
(i-fax) an "Internet FAX Gateway" is required. This document provides
recommendations for the functionality of Internet FAX Gateways. In
this context, an "offramp gateway" provides facsimile data transmission
from  i-fax to GSTN fax; viceversa an "onramp gateway" provides data 
transmission form GSTN fax to i-fax. The recommendations in this
document apply to the integrated service including Internet Fax
terminals, computers with i-fax software on the Internet, and GSTN Fax
terminals on the GSTN.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-13.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
(Continue reading)

Permalink | Reply |
headers
McIntyre, Lloyd | 8 Nov 2001 18:52
Picon

RE: I-D ACTION:draft-ietf fax-tiff-fx-reg-00.txt


Please note that the draft is not accessible at the URL provided below.

The problem is likely due to an error in the Filename and URL listed below.
Please change "Filename" from
 	 draft-ietf fax-tiff-fx-reg-00.txt
to
       draft-ietf-fax-tiff-fx-reg-00.txt
where the space " " between "ietf" and "fax" is replaced by a dash "-".

Please modify the URL accordingly.

Thanks,
Lloyd

> -----Original Message-----
> From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
> Sent: Thursday, November 08, 2001 3:57 AM
> Cc: ietf-fax <at> imc.org
> Subject: I-D ACTION:draft-ietf fax-tiff-fx-reg-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Internet Fax Working Group 
> of the IETF.
> 
> 	Title		: Tag Image File Format Fax eXtended (TIFF-FX)  
>                           -image/tiff-fx MIME Sub-type Registration
> 	Author(s)	: L. McIntyre, G. Parsons, J. Rafferty
(Continue reading)

Permalink | Reply |
headers
Terry Brookes | 18 Jul 2001 14:18
Picon
Favicon

RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt


Hi Dan,

pardon the probably dumb newbies question, but why can't the fax-terminal 
inside the firewall simply use POP to get the ifax from wherever its mailbox 
is, inside the firewall or outside ?

also

>Is the intent of the 'full mode' ifax to work only within an enterprise's
>internal network, or between enterprises that trust each other, or between
>enterprises that have a VPN set up between themselves?  If that's the 
>model,
>that's fine, too.  In fact, I could believe such a model would be more
>successful and more viable.
>

You just killed the market for it, thanks ;-) !

Terry

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
Permalink | Reply |
headers
Dan Wing | 18 Jul 2001 18:45
Picon
Favicon

RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt


"Full-mode" requires an end-to-end connection to support all existing T.30
functions.  POP can't do that.  It would have to be SMTP end-to-end (from
transmitter to receiver).  This means POP wouldn't work.

-d

> -----Original Message-----
> From: Terry Brookes [mailto:brookes_terry <at> hotmail.com]
> Sent: Wednesday, July 18, 2001 2:18 PM
> To: dwing <at> cisco.com; maeda <at> crf.canon.fr; Claudio.Allocchio <at> garr.it
> Cc: ietf-fax <at> imc.org
> Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt
>
>
> Hi Dan,
>
> pardon the probably dumb newbies question, but why can't the fax-terminal
> inside the firewall simply use POP to get the ifax from wherever
> its mailbox
> is, inside the firewall or outside ?
>
> also
>
>
> >Is the intent of the 'full mode' ifax to work only within an enterprise's
> >internal network, or between enterprises that trust each other, or between
> >enterprises that have a VPN set up between themselves?  If that's the
> >model,
> >that's fine, too.  In fact, I could believe such a model would be more
(Continue reading)

Permalink | Reply |
headers
McDonald, Ira | 14 Jul 2001 17:57
Favicon

RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt


Hi,

The following reply was lost due to the size of the attachment,
but the URL for the attachment is in the message.

Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
  High North Inc
-----------------------------
This message was too long. Please send it again without attaching the 
large PDF file.

>  >From owner-ietf-fax Wed Jul 11 09:00:56 2001
>Received: from sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101])
>	by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BG0tm27020
>	for <ietf-fax <at> imc.org>; Wed, 11 Jul 2001 09:00:55 -0700 (PDT)
>Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253])
>	by sharplabs.com (8.9.3+Sun/8.9.2) with ESMTP id JAA10977;
>	Wed, 11 Jul 2001 09:00:12 -0700 (PDT)
>Received: by webmail.sharplabs.com with Internet Mail Service (5.5.2653.19)
>	id <N527VLD6>; Wed, 11 Jul 2001 08:50:35 -0700
>Message-ID: 
><1115A7CFAC25D311BC4000508B2CA537C52DB9 <at> mailsrvnt02.enet.sharplabs.com>
>From: "McDonald, Ira" <imcdonald <at> sharplabs.com>
>To: "'MAEDA Toru'" <maeda <at> crf.canon.fr>, Dan Wing <dwing <at> cisco.com>
>Cc: ietf-fax <at> imc.org
>Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt
>Date: Wed, 11 Jul 2001 08:50:33 -0700
>MIME-Version: 1.0
(Continue reading)

Permalink | Reply |
headers
Terry Brookes | 5 Jul 2001 12:34
Picon
Favicon

RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt


Hi Ira,

>Do you just dislike IPP?
Nope, think it's great and would like to see a URI on every business card, 
but from a business standpoint it doesn't look like a very good way of 
meeting Mr Maeda's requirements. As far as I can tell he's looking for a way 
to use the popularity of e-mail as the basis for a simple low cost T30-like 
internet fax machine to replace the 100 million or so traditional fax 
machines in use. There are estimated to be half a billion fax users, this, 
presumably, is the target market. I believe its a reasonable assumption that 
a very large proportion of these users now have e-mail addresses; a rapidly 
growing number use Instant Messaging ( a number which will accelerate 
dramaticaly when Windows XP appears); but only a very small and exclusive 
group (the IPP developers ? printer manufacturers ?) appears to have any 
knowledge whatsoever of IPP. From a technical standpoint Dan's proposal of 
IPP may be OK, from a marketing standpoint it doesn't look like a very good 
idea because the user won't have anyone to send to, because, despite the 
valiant efforts of IPP people, hardly anyone actualy uses it. IM could (not 
would!) be a better bet on the basis that it could work very much like T30 
AND have a large number of people already using it. Not IMPP, which the Blue 
Window Software Corporation (Redmond WA) is in the process of killing, but 
Windows IM which will probably be the de facto IM standard by the time Mr 
Maeda's machine is ready for production.
My own belief is that FOIP will only be successfull if it's as easy to use 
as a regular fax machine. POP/SMTP has proved to be much too complex to set 
up, IPP doesn't have a user base even if it *is* imbedded in every printer, 
so maybe IM will be the answer...who knows?

Terry
(Continue reading)

Permalink | Reply |
headers
McDonald, Ira | 3 Jul 2001 19:27
Favicon

RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt


Hi Terry,

Do you just dislike IPP?

For IPP Fax to work, IPP does NOT need to be ubiquitous.  It just
needs to be ubiquitous in deployed PRINTERS.  Very few printers
shipped in calendar 2001 that did not have IPP protocol support.
Probably NONE will ship in calendar 2002 without IPP protocol
support.

I agree that SMTP is ubiquitous, but it doesn't (and can't ever)
do realtime capabilities negotiation, by its very nature.

Certainly such protocols as IMPP (your suggestion) are utterly
inappropriate for sending large documents by VALUE (like IPP)
and not by REFERENCE.

Could you explain your implacable opposition to IPP Fax, please?

Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
  High North Inc

-----Original Message-----
From: Terry Brookes [mailto:brookes_terry <at> hotmail.com]
Sent: Tuesday, July 03, 2001 8:30 AM
To: dwing <at> cisco.com
Cc: ietf-fax <at> imc.org; maeda <at> crf.canon.fr; dcrocker <at> brandenburg.com
Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt
(Continue reading)

Permalink | Reply |
headers
Terry Brookes | 3 Jul 2001 14:29
Picon
Favicon

RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt


Hi
I'd re-phrase the following-
>IPP exists. <

This would be more accurate-
>IPP barely exists<

Also 'IPP FAX' certainly does NOT exist...yet.

IPP also requires infrastrucure in the form of IPP servers, so it may not 
meet the stated requirements of 'using existing infrastructure'.

If SMTP really doesn't work for fax terminal mode then strategicaly the new 
Windows Instant Messenger could be a much better bet. It's likely to become 
a de facto standard for the non-AOL IM's, and with IM you get an instant 
response that should allow replication of T30 with great simplicity. You 
also get SIP with Windows IM, which could allow discovery of the 
capabilities of the receiving fax terminal, probably even give you the color 
of the operator's hair.

Terry Brookes
www.polyteq.com

>From: "Dan Wing" <dwing <at> cisco.com>
>To: "Dave Crocker" <dcrocker <at> brandenburg.com>
>CC: "MAEDA Toru" <maeda <at> crf.canon.fr>, <ietf-fax <at> imc.org>
>Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt
>Date: Sat, 30 Jun 2001 17:42:39 -0700
>
(Continue reading)

Permalink | Reply |
headers
McDonald, Ira | 2 Jul 2001 22:16
Favicon

RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt


Hi Dan,

I like your approach to the T.30 error codes below.

But I would revise your two 'Attachment' error codes as follows:

"unable to process attachment as TIFF"
---> "invalid attachment encoding"
     (because someday Internet Fax might allow other high-quality
     document formats like PDF as PWG IPP Fax has chosen to do)

"invalid pointer in TIFF"
---> "invalid pointer in attachment"
     (which is understood and documented to include bad URL references
     in XML and PDF documents, as well)

Comments?

Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
  High North Inc

-----Original Message-----
From: Dan Wing [mailto:dwing <at> cisco.com]
Sent: Monday, July 02, 2001 2:03 PM
To: MAEDA Toru
Cc: ietf-fax <at> imc.org
Subject: RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt
(Continue reading)

Permalink | Reply |
headers
Dan Wing | 2 Jul 2001 22:43
Picon
Favicon

RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt


There are lots of things that could be wrong with an attachment; I believe
Vivian's Implementation Guide document lists many of these.  Perhaps we would
like to number them, too, I don't know -- in any event it needs to be
enumerated.

-d

> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald <at> sharplabs.com]
> Sent: Monday, July 02, 2001 1:16 PM
> To: 'Dan Wing'; MAEDA Toru
> Cc: ietf-fax <at> imc.org
> Subject: RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt
>
>
> Hi Dan,
>
> I like your approach to the T.30 error codes below.
>
> But I would revise your two 'Attachment' error codes as follows:
>
> "unable to process attachment as TIFF"
> ---> "invalid attachment encoding"
>      (because someday Internet Fax might allow other high-quality
>      document formats like PDF as PWG IPP Fax has chosen to do)
>
> "invalid pointer in TIFF"
> ---> "invalid pointer in attachment"
>      (which is understood and documented to include bad URL references
(Continue reading)

Permalink | Reply |
headers
Terry Brookes | 29 Jun 2001 13:47
Picon
Favicon

RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt


Hi Dan,
IPP deployment is minimal whereas SMTP is universal.
If you want to suggest alternative protocols IMPP (or just go with Windows 
Messenger ?) could be a better choice.
Terry

>From: "Dan Wing" <dwing <at> cisco.com>
>To: <ietf-fax <at> imc.org>
>Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt
>Date: Wed, 27 Jun 2001 09:47:40 -0700
>
>
>IPP is more suitable for these goals than SMTP.
>
>-d
>
> > -----Original Message-----
> > From: owner-ietf-fax <at> mail.imc.org [mailto:owner-ietf-fax <at> mail.imc.org]On
> > Behalf Of Internet-Drafts <at> ietf.org
> > Sent: Wednesday, June 27, 2001 4:03 AM
> > To: IETF-Announce:
> > Cc: ietf-fax <at> imc.org
> > Subject: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Internet Fax Working Group of the IETF.
> >
(Continue reading)

Permalink | Reply |
headers
Hiroshi Tamura | 23 Jun 2001 07:41
Picon

Re: I-D ACTION:draft-ietf-fax-timely-delivery-03.txt


What about this one?

At Minneapolis meeting, we agreed to go to the final stage.
In fact, there are few issues in TODO in Appendix A.
But, it seems that there are some items to be considered
in REVIEW CHECKLIST.

At first, I would like to hear the editors' comment.

Folks,
any comments are welcome.

Regards,
--
Hiroshi Tamura, Co-chair of IETF-FAX WG
E-mail: tamura <at> toda.ricoh.co.jp
Permalink | Reply |
headers
Graham Klyne | 23 Jun 2001 10:40

Re: I-D ACTION:draft-ietf-fax-timely-delivery-03.txt


Tamura-san,

Thank you for raising this.  (I should first apologize for taking far 
longer to get the draft to this state than I originally said I would.)

There is one issue I would like to clarify before requesting a last call, 
namely how a congested relay can avoid exacerbating the congestion condition.

The basic idea I am contemplating is that if a relay is congested, it can 
immediately reject a message by an error response to a MAIL FROM command 
with a TIMELY option specified.  (Otherwise, a new message -- especially if 
retries are being attempted -- may simply exacerbate the congestion.)

So I am asking:

Q: does this approach seem reasonable?

Q: assuming it's reasonable, what error code to use?  (a) an existing, or 
(b) a new code?  If (a) then the choices would seem to be:
   450 Requested mail action not taken: mailbox unavailable
   451 Requested action aborted: local error in processing
   452 Requested action not taken: insufficient system storage

(I think 450 is inappropriate, as it's specific to a mailbox.)

My preference would be to define a new code, something like:
   453 Message not accepted: relay busy
RFC2821 seems to say this would be OK. But, lacking a registry for SMTP 
error codes, is this likely to prove problematic, procedurally?
(Continue reading)

Permalink | Reply |
headers
Graham Klyne | 23 Jun 2001 22:48

Re: I-D ACTION:draft-ietf-fax-timely-delivery-03.txt


At 06:58 PM 6/23/01 +0900, Hiroshi Tamura wrote:
> > Also, a separate matter as a point of information.  I am liaising with 
> Greg
> > Vaudreil, who is working on a revised versions of the extended SMTP status
> > codes specification, about the new status codes introduced by this draft.
>
>Could you specify I-D or ML or something?
>The people here may be interesting in it.

Part of the I-D announcement is copied below.

#g
--

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : Extensions to Mail System Status Codes
         Author(s)       : G. Vaudreuil
         Filename        : draft-vaudreuil-1983ext-00.txt
         Pages           : 5
         Date            : 21-Jun-01

This document defines an additional set of extended status codes based
on new messaging applications and associated error states since the
creation of the original RFC 1893 document.  These include extended
media conversion codes for fax and voice messaging and results for
message tracking.

A URL for this Internet-Draft is:
(Continue reading)

Permalink | Reply |
headers
Graham Klyne | 3 Jul 2001 16:50

Re: I-D ACTION:draft-ietf-fax-timely-delivery-03.txt


At 02:05 PM 6/30/01 +0900, Hiroshi Tamura wrote:
> >          Title           : Extensions to Mail System Status Codes
> >          Author(s)       : G. Vaudreuil
> >          Filename        : draft-vaudreuil-1983ext-00.txt
> >          Pages           : 5
> >          Date            : 21-Jun-01
> >
> > This document defines an additional set of extended status codes based
> > on new messaging applications and associated error states since the
> > creation of the original RFC 1893 document.  These include extended
> > media conversion codes for fax and voice messaging and results for
> > message tracking.
>
>Is it being discussed in VPIM WG or just come out?
>It addresses the fax related codes.

I'm not aware that this is being discussed by VPIM.  I'm not sure if it is 
being discussed specifically by any WG.

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<Graham.Klyne <at> Baltimore.com>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------
(Continue reading)

Permalink | Reply |
headers
Hiroshi Tamura | 30 Jun 2001 07:05
Picon

Re: I-D ACTION:draft-ietf-fax-timely-delivery-03.txt


Graham,

Thanks for your information. Also, sorry for my very slow response.

>          Title           : Extensions to Mail System Status Codes
>          Author(s)       : G. Vaudreuil
>          Filename        : draft-vaudreuil-1983ext-00.txt
>          Pages           : 5
>          Date            : 21-Jun-01
> 
> This document defines an additional set of extended status codes based
> on new messaging applications and associated error states since the
> creation of the original RFC 1893 document.  These include extended
> media conversion codes for fax and voice messaging and results for
> message tracking.

Is it being discussed in VPIM WG or just come out?
It addresses the fax related codes.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: tamura <at> toda.ricoh.co.jp
Permalink | Reply |
headers
Hiroshi Tamura | 23 Jun 2001 11:58
Picon

Re: I-D ACTION:draft-ietf-fax-timely-delivery-03.txt


Graham,
You are also working on Saturday :-<

> The basic idea I am contemplating is that if a relay is congested, it can 
> immediately reject a message by an error response to a MAIL FROM command 
> with a TIMELY option specified.  (Otherwise, a new message -- especially if 
> retries are being attempted -- may simply exacerbate the congestion.)
> 
> So I am asking:
> 
> Q: does this approach seem reasonable?

It's ok for me.

> Q: assuming it's reasonable, what error code to use?  (a) an existing, or 
> (b) a new code?  If (a) then the choices would seem to be:
>    450 Requested mail action not taken: mailbox unavailable
>    451 Requested action aborted: local error in processing
>    452 Requested action not taken: insufficient system storage
> 
> (I think 450 is inappropriate, as it's specific to a mailbox.)

Yes.

> My preference would be to define a new code, something like:
>    453 Message not accepted: relay busy

I think so, too.
(Continue reading)

Permalink | Reply |
headers
TJenkins | 6 Mar 2001 14:58

Re: I-D ACTION:draft-ietf-fax-ffpim-01.txt


I have tried to get off this mailing list several times and can not.
Please remove me.
Thank You
Permalink | Reply |
headers
Dan Wing | 23 Feb 2001 02:54
Picon
Favicon

Re: I-D ACTION:draft-ietf-fax-gateway-options-01.txt

(correction below)

Thanks.

I was most concerned with the paragraphs recommending that only 1/100 of 
positive messages be sent.  Section 2.4 (sorry I had omitted this 
previously).

Both S/MIME and PGP are standards for encrypting messages; both need to be 
allowed.

-d

At 09:39 AM 02/23/01 +0900, Katsuhiko Mimura wrote:

>Wing-san,
>
>Dan Wing wrote:
>
>>The non-deterministic recommendation in section 4 of this document is 
>>worrisome.
>
>Sorry, I have not change section 4.
>I would llike to change Section 4 to say something like:
>
>Offramp and Onramp gateway MAY have a user authorization
>function to confirm that they are the data that suitable user transmitted.
>
>Encipherment of  facsimile data is performed by the existing SMTP, such as 
>S/MIME, using the possible
(Continue reading)

Permalink | Reply |
headers
McDonald, Ira | 24 Jan 2001 04:03
Favicon

RE: I-D ACTION:draft-ietf-fax-implementers-guide-05.txt

Hi,

I picked this up from the IETF repository and noticed
some formatting problems.

This document contains 7 horizontal tab characters and
has 166 lines that are longer than 72 columns.  The
editors might want to fix this up a bit.  The longest
line is 84 columns and displays quite poorly in many
text viewers.

Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
  High North Inc

-----Original Message-----
From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
Sent: Tuesday, January 23, 2001 4:34 AM
Cc: ietf-fax <at> imc.org
Subject: I-D ACTION:draft-ietf-fax-implementers-guide-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Internet Fax Working Group of the IETF.

	Title		: Implementers Guide for Facsimile Using Internet
Mail
	Author(s)	: V. Cancio, M. Moldovan, H. Tamura, D. Wing
	Filename	: draft-ietf-fax-implementers-guide-05.txt
	Pages		: 19
(Continue reading)

Permalink | Reply |
headers
Hiroshi Tamura | 24 Jan 2001 06:35
Picon

RE: I-D ACTION:draft-ietf-fax-implementers-guide-05.txt

Hi,

> I picked this up from the IETF repository and noticed
> some formatting problems.
> 
> This document contains 7 horizontal tab characters and
> has 166 lines that are longer than 72 columns.  The
> editors might want to fix this up a bit.  The longest
> line is 84 columns and displays quite poorly in many
> text viewers.

I edited -05.
I wrote some parts from version -00 to -04.
But, this is the first time I edited as the whole.
I already noticed when I was editting -05.

At first I was thinking of modifying as you intension.
But I did not. Because, if so, you might not find *easily*
the difference from -04 and -05, I think.

Please be patient.

I comment something about -05 in another thread,
today or tomorrow.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: tamura <at> toda.ricoh.co.jp
(Continue reading)

Permalink | Reply |
headers
Hiroshi Tamura | 27 Oct 1999 03:01
Picon

Re: I-D ACTION:draft-ietf-fax-implementers-guide-00.txt

Hi,

My comments are below.(after "- End quote -")

-- Begin quote --
   3.1.1 Multipart-alternative

   Legacy (old) email client implementations may not be capable of
   processing 'multipart-alternative'. If a sender is unsure if the
   recipient complies with the MIME requirements, the sender should
   assume the worst and not use content-types which have known
   problems with such non-compliant implementations.  Specifically,
   multi-part/alternative SHOULD be avoided in situations where the
   recipient is not known to properly support multipart/alternative.

   [[[Note: How does a sender's client application know this information?]]]
- End quote -

If we add something, maybe,
"The mechanism or something is beyond the scope of this document."

We sometimes see the expressions like "beyond the scope" or "out of scope".

But I don't think it is necessary.
In fact, it cannot be done without capability exchange.

-- Begin quote --
   3.2.1 Multipart-alternative and Storage Capacity

   Devices with little storage capacity are unable to cache previous
(Continue reading)

Permalink | Reply |
headers
Hiroshi Tamura | 26 Oct 1999 06:35
Picon

Re: I-D ACTION:draft-ietf-fax-content-negotiation-00.txt

Hi,

1 3.3

There are the following sentences.
"
  If the sender is no longer able to send message data for any
  reason, it MUST send a message to the receiver indicating a failed
  transfer.  It SHOULD also generate a report for the sender
  indicating the failure.

  [[[Discuss this last paragraph.]]]
"

In this case, what kind of messages do SENDER send to RECEIVER ?
As you said in [[[]]], this is the discussion point.

2 "Content-alternative" and 'Alternative-preferred'

I think more than two "alternative"s cat be described
in the first Sender's message,
by using of more than "Content-alternative" headers.

Receiver cannot specify the exact one that it wants.
'Alternative-preferred' disposition modifier is only defined.
Another sub-modifier(?) is necessary for it.

And,

Receiver cannot judge whether the message from Sender is
(Continue reading)

Permalink | Reply |
headers
Graham Klyne | 9 Mar 2000 12:40

Re: I-D ACTION:draft-ietf-fax-content-negotiation-00.txt

Tamura-san,

I am reviewing the comments you made some time ago concerning the fax 
negotiation draft.

At 04:35 AM 10/26/99 +0000, Hiroshi Tamura wrote:
>Hi,
>
>1 3.3
>
>There are the following sentences.
>"
>   If the sender is no longer able to send message data for any
>   reason, it MUST send a message to the receiver indicating a failed
>   transfer.  It SHOULD also generate a report for the sender
>   indicating the failure.
>
>   [[[Discuss this last paragraph.]]]
>"
>
>In this case, what kind of messages do SENDER send to RECEIVER ?

This is a very good question.  At first, I had thought that an ordinary 
text or image message simply saying something like "The alternative data 
you have requested is no longer available".  But on reflection, I wonder if 
this is enough:

(a) an ordinary message conveys no information that the receiver might be 
able to use to print the data originally received (assuming it was 
buffered), or to otherwise indicate failure.
(Continue reading)

Permalink | Reply |
headers
Hiroshi Tamura | 10 Mar 2000 02:28
Picon

Re: I-D ACTION:draft-ietf-fax-content-negotiation-00.txt

Klyne-san,

<snip>

> >   If the sender is no longer able to send message data for any
> >   reason, it MUST send a message to the receiver indicating a failed
> >   transfer.  It SHOULD also generate a report for the sender
> >   indicating the failure.

<snip>

> >In this case, what kind of messages do SENDER send to RECEIVER ?
> 
> This is a very good question.  At first, I had thought that an ordinary 
> text or image message simply saying something like "The alternative data 
> you have requested is no longer available".  But on reflection, I wonder if 
> this is enough:
> 
> (a) an ordinary message conveys no information that the receiver might be 
> able to use to print the data originally received (assuming it was 
> buffered), or to otherwise indicate failure.
> 
> (b) the failure information would not be available in a language neutral 
> form for ocalized presentation of the problem.

OK. I understand you.

> So now, I am thinking that it might be reasonable to define a 
> multipart/report based format for carrying diagnostic information from 
> sender to receiver.  The general format would be very like DSN or MDN, but
(Continue reading)

Permalink | Reply |
headers
Hiro Yuki Aya Ikegami | 31 Aug 1999 19:29
Picon

I-D ACTION:draft-ietf-fax-tiff-fx-02.txt

> "On the recommendation of the JBIG committee of ISO/IEC JTC1/SC29/WG1,

> made T82Options = 0 (the default value) correspond to the T.85
> application profile; made corresponding changes in 5.4 and 8.5.
> The committee rationalized that T.85 is the minimum T.82 profile
> and it is also the most widely implemented profile."

I agree to this change.

******************************************************
  Hiroaki Ikegami
      Fuji Xerox Co. Ltd.
      Imaging Technology Development Department
      430  Sakai, Nakai-machi, Ashigarakami-gun,
      Kanagawa  259-0157,  Japan
      TEL:+81-465-80-2139, FAX:+81-465-81-8964
      E−Mail:Hiroaki.Ikegami <at> fujixerox.co.jp
******************************************************
Permalink | Reply |
headers
Graham Klyne | 24 Nov 1998 12:45

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

Tamura-san,

Thank you for your question.  I do think this is a matter which would
usefully be clarified.

If I understand you correctly, you are asking if it is necessary to include
default capabilities in an Internet fax capability expression.

The short answer is, I believe:  this is not necessary, but it is desirable.

I try to explain below my reasons for this view:

The fax feature schema is a profile of a general capability feature
description scheme, and simply provides a means to describe media handling
capabilities that are provided by an application.  The capability
description framework does not have any concept of "default" capabilities:

+ if any feature is not explicitly mentioned in a capability description
option, then it is not constrained by that option.

+ if a feature is mentioned in a capability description option, then any
alowed values must be mentioned explicitly.

There are two possible cases to consider:
(A) a system with *only* minimum capabilities:  should it provide any
capability description?
(B) a system with greater than minimum capabilities:  assuming it provides
a capability description, should it include the TIFF-S capability in that
description?
(Continue reading)

Permalink | Reply |
headers
Hiroshi Tamura | 25 Nov 1998 09:49
Picon

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

Klyne-san,

Thank you for your reply.

>> Thank you for your question.  I do think this is a matter which would
>> usefully be clarified.

I think so, too.

>> There are two possible cases to consider:
>> (A) a system with *only* minimum capabilities:  should it provide any
>> capability description?
>> (B) a system with greater than minimum capabilities:  assuming it provides
>> a capability description, should it include the TIFF-S capability in that
>> description?
>> 
>> (A) One of the recommendations of the "extended internet fax" specification
>> is that that minimum capabilities (TIFF-S) be advertised, even though they
>> are required for any Internet fax implementation, because by explictly
>> advertising this capability it shows the system is capable of "full mode"
>> behaviour as well as "simple mode".
>> 
>> (B) The presence or absence of any capabilities that are not allowed by a
>> capability description is, in my view, controlled by the "extended internat
>> fax" specification.  My interpretation is that TIFF-S would be allowed even
>> if not specifically mentioned in the capability desription provided.
>> 
>> However, I would recommend that the TIFF-S capability be mentioned
>> explictly, because this may ease interoperability with other applications
>> in the future.  This applies to both case (A) and (B).
(Continue reading)

Permalink | Reply |
headers
Graham Klyne | 16 Oct 1998 16:59

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

At 18:47 15/10/98 -0700, McIntyre, Lloyd wrote:
[...]
>> 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.
>	[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.

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)
(Continue reading)

Permalink | Reply |
headers
McIntyre, Lloyd | 16 Oct 1998 03:47
Picon

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

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

> -----Original Message-----
> From:	Graham Klyne [SMTP:GK <at> dial.pipex.com]
> Sent:	Thursday, October 15, 1998 3:17 PM
> To:	James Rafferty
> Cc:	Lloyd McIntyre; ietf-fax <at> imc.org
> Subject:	Re: I-D ACTION:draft-ietf-fax-feature-schema-00.txt
> 
> At 18:39 14/10/98 -0400, James  Rafferty wrote:
> [...]
	[McIntyre, Lloyd]  snip ------- 

> >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
(Continue reading)

Permalink | Reply |
headers
Graham Klyne | 16 Oct 1998 00:17

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

At 18:39 14/10/98 -0400, James  Rafferty wrote:
[...]
>>  Section 3 enumerates the feature tags that MUST be recognized and
>>  processed by extended Internet fax systems, according to their
>>  capabilities.
>>
>IMO, Section 3 should define the tags,
>but not prescribe -eifax behaviour. 

Agreed.

>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?   

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 )
(Continue reading)

Permalink | Reply |
headers
McIntyre, Lloyd | 15 Oct 1998 04:04
Picon

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

James,
Some personal responses to your comments.

> -----Original Message-----
> From:	James Rafferty [SMTP:jrafferty <at> worldnet.att.net]
> Sent:	Wednesday, October 14, 1998 3:39 PM
> To:	Graham Klyne; Lloyd McIntyre
> Cc:	ietf-fax <at> imc.org
> Subject:	Re: I-D ACTION:draft-ietf-fax-feature-schema-00.txt
> 
> 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,
(Continue reading)

Permalink | Reply |
headers
Dan Wing | 15 Oct 1998 03:32
Picon
Favicon

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

>5. Security considerations
[...]

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

-Dan Wing
Permalink | Reply |
headers
Dan Wing | 14 Oct 1998 17:52
Picon
Favicon

Re: I-D ACTION:draft-ietf-fax-reporting-extensions-03.txt

This is the 'smaller' document that James was referring to.

It contains only the "Accept-Features" field for DSNs or MDNs, and
no fax- or printer- offramp-specific information (such as call 
duration, new RFC1893-style codes, actual-number-dialed, etc.).

-Dan Wing

-----

>	Title		: Indicating Supported Media Features Using Extensions 
>                          to DSN and MDN
>	Author(s)	: D. Wing
>	Filename	: draft-ietf-fax-reporting-extensions-03.txt
>	Pages		: 4
>	Date		: 13-Oct-98
>	
>   A device, unlike a workstation, is not generally extensible by
>   installing a new reader, plugin, or other software.  There is a need
>   in Internet mail for a recipient to indicate the media features it
>   supports so that messages can be generated by senders without
>   exceeding the recipient's abilities.
> 
>   This memo describes a format for generating Message Disposition
>   Notifications [RFC2298] and Delivery Status Notifications [RFC1894]
>   which contain such information.  This information can be used by
>   senders to avoid exceeding the recipient's capabilities when sending
>   subsequent messages.
>
>Internet-Drafts are available by anonymous FTP.  Login with the username
(Continue reading)

Permalink | Reply |
headers
Dan Wing | 12 Nov 1997 19:00
Picon
Favicon

RE: I-D ACTION:draft-ietf-fax-scenerios-00.txt

Thanks.  I'd like to get more scenarios collected, and the document
has some sections that obviously need more work.  

Anyone with more scenarios to add to the draft-ietf-fax-scenarios-??.txt
document, or ideas for sections which might be appropriate, please let
me or the ietf-fax <at> imc.org mailing list know.

(And, yes, I didn't spell scenario correctly in the entire I-D.  A new
 version, with corrected spelling, will be announced tomorrow.) 

-Dan Wing

-----

>From: "Herman R. Silbiger" <hsilbiger <at> exit109.com>
>To: "ietf-fax <at> imc.org" <ietf-fax <at> imc.org>
>Subject: RE: I-D ACTION:draft-ietf-fax-scenerios-00.txt
>Date: Wed, 12 Nov 1997 11:02:03 -0500
>
>This internet draft gives a good overview of all the difficulties involved 
>in trying to use SMTP for fax delivery.
>
>I assume a scenerio is a variant of a scenario.
>
>Herman Silbiger  
>----------
>From: 	Internet-Drafts <at> ietf.org[SMTP:Internet-Drafts <at> ietf.org]
>Sent: 	Wednesday, November 12, 1997 9:56 AM
>To: 	IETF-Announce <at> ietf.org
>Cc: 	ietf-fax <at> imc.org
(Continue reading)

Permalink | Reply |
headers
Herman R. Silbiger | 12 Nov 1997 17:02

RE: I-D ACTION:draft-ietf-fax-scenerios-00.txt

This internet draft gives a good overview of all the difficulties involved in trying to use SMTP for fax delivery.

I assume a scenerio is a variant of a scenario.

Herman Silbiger  
----------
From: 	Internet-Drafts <at> ietf.org[SMTP:Internet-Drafts <at> ietf.org]
Sent: 	Wednesday, November 12, 1997 9:56 AM
To: 	IETF-Announce <at> ietf.org
Cc: 	ietf-fax <at> imc.org
Subject: 	I-D ACTION:draft-ietf-fax-scenerios-00.txt

<<File: ATT00003.txt>><<File: draft-ietf-fax-scenerios-00.txt.url>>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Fax Working Group of the IETF.

	Title		: Scenerios for Delivery of FAX messages over SMTP
	Author(s)	: D. Wing
	Filename	: draft-ietf-fax-scenerios-00.txt
	Pages		: 11
	Date		: 11-Nov-97
	
This document describes various fax-over-SMTP implementation and
deployment scenerios and some of the problems inherient with various
solutions.

Most of these scenerios have been described and discussed on the
IETF-FAX mailing list.
(Continue reading)

Permalink | Reply |
headers
Claudio Allocchio +39 40 3758523 | 7 Nov 1997 10:17
Picon

Re: I-D ACTION:draft-ietf-fax-addressing-01.txt


Hallo Larry,

>The number of drafts that talk about encoding telephone numbers
>into URLs and email addresses and DNS addresses is confusing.

yes, it looks like too many groups or individuals woke up together, 
trying to do similar specifications.

>I don't think we need 4 different standards, but I've not seen much direct
>activity on getting these specs to work together. 

I believe we need for sure specifications for:

- PSTN numbers into e-mail addresses
  (this is covered by draft-ietf-fax-addressing-0x.txt)

- PSTN numbers into URLs
  (this is covered by draft-antti-telephony-url-0x.txt)

and maybe also something for DNS encoding (but I'm not really sure yet... 
TPC.INT experiment is still there... I believe we need a serious 
brainstorming about encoding into DNS for PSTN numbers, at least to 
synchronize TPC.INT and others).

E-mail and URLs specifications are currently different flavours (different
syntaxes) of the same encoding schema (the e-mail LHS turnes to be nearly
identical to the URL itself)

e-mail   fax=+358.55.1234567p23 <at> gateway.domain
(Continue reading)

Permalink | Reply |
headers
Larry Masinter | 8 Nov 1997 03:34
Picon
Favicon

Re: I-D ACTION:draft-ietf-fax-addressing-01.txt

This is my personal opinion about what should happen:

You and the authors of the other drafts try to come up with a single
specification which consists of

a) PSTN numbers as strings

b) Embedding of those strings in
  URLs of various schemes
  Email addresses

The main concern is that we don't have one syntax for a phone
number embedded in an email address, and another for embedding
it in a URL (or several, each different depending on the URL
scheme).

Also, we should have a complete syntax for all PSTN syntax
features (delays, pauses, DTMF tones, subaddresses, etc.)
which is the union of the capabilities that are needed for
the various applications. The applications should then profile
which addressing elements are appropriate.

I'm starting to wonder whether "addressing" for Internet Fax
should in fact be "URL" rather than "EMail address", and that
if you want to EMail the fact you use a "mailto:" URL but
if you want to use HTTP or some other protocol, you can use
that instead. This is really a user interface issue, but
especially with the enhancements in
draft-hoffman-mailto-url-02.txt, this would allow more complex
routing, addition of other (safe) mail headers, etc.
(Continue reading)

Permalink | Reply |
headers
Keith Moore | 8 Nov 1997 08:18
Picon

Re: I-D ACTION:draft-ietf-fax-addressing-01.txt

> You and the authors of the other drafts try to come up with a single
> specification which consists of
> 
> a) PSTN numbers as strings
> 
> b) Embedding of those strings in
>   URLs of various schemes
>   Email addresses
> 
> The main concern is that we don't have one syntax for a phone
> number embedded in an email address, and another for embedding
> it in a URL (or several, each different depending on the URL
> scheme).
> 
> Also, we should have a complete syntax for all PSTN syntax
> features (delays, pauses, DTMF tones, subaddresses, etc.)
> which is the union of the capabilities that are needed for
> the various applications. The applications should then profile
> which addressing elements are appropriate.

I agree (enthusiastically) with this much.

> I'm starting to wonder whether "addressing" for Internet Fax
> should in fact be "URL" rather than "EMail address", and that
> if you want to EMail the fact you use a "mailto:" URL but
> if you want to use HTTP or some other protocol, you can use
> that instead. This is really a user interface issue, but
> especially with the enhancements in
> draft-hoffman-mailto-url-02.txt, this would allow more complex
> routing, addition of other (safe) mail headers, etc.
(Continue reading)

Permalink | Reply |
headers
Claudio Allocchio +39 40 3758523 | 8 Nov 1997 12:41
Picon

Re: I-D ACTION:draft-ietf-fax-addressing-01.txt


Hallo Larry and Keith,

>You and the authors of the other drafts try to come up with a single
>specification which consists of
>
>a) PSTN numbers as strings

This is done: just check pstn-mbox definition in addressing-01 draft.

>b) Embedding of those strings in
>  URLs of various schemes
>  Email addresses

This is also done both in addressing-01 and in current Antti URL draft ( I
understand a newly aligned version is nearly ready, is it? )

>Also, we should have a complete syntax for all PSTN syntax
>features (delays, pauses, DTMF tones, subaddresses, etc.)
>which is the union of the capabilities that are needed for
>the various applications. The applications should then profile
>which addressing elements are appropriate.

Correct: in fact addressing-00 was modified into addressing-01
just to exactly support all of this, and it is the general
hopefully complete specification for PSTN syntax into strings
and allows specification of any PSTN service into e-mail 
addresses. URL document adopts pstn-mbox strings into URL
form. In fact the main reason why addressing-01 became more
complex in the pstn-mbox specification is to support all
(Continue reading)

Permalink | Reply |
headers
James Rafferty | 6 Nov 1997 06:39
Picon

Re: I-D ACTION:draft-ietf-fax-addressing-01.txt

Claudio,  

A couple of small points on the Addressing-01 draft:   

1.   Please add a reference to T.33

i.e. ITU-T T.33 - Facsimile routing utilizing the subaddress;
recommendation T.33 (July, 1996)

Since T.33 itself incorporates T.30 by reference (for definition of the
subaddress in the fax
protocol), a T.30 reference is probably not needed

2.  Revise example in 5.5 to use image/tiff instead of image/tiff-f to
represent a TIFF-F 
media type, consistent with the current consensus on this.  

James 
*------------------------------------------------*
James Rafferty			
President, Human Communications 	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email:  JRafferty <at> worldnet.att.net
	 J_Rafferty_HC <at> compuserve.com

HC Web Site:  http://www.humancomm.com  (newly activated!)
*---------------------------------------------------
(Continue reading)

Permalink | Reply |
headers
Claudio Allocchio +39 40 3758523 | 6 Nov 1997 09:28
Picon

Re: I-D ACTION:draft-ietf-fax-addressing-01.txt


> Claudio,  
> 
> A couple of small points on the Addressing-01 draft:   
> 
> 1.   Please add a reference to T.33
> 
> i.e. ITU-T T.33 - Facsimile routing utilizing the subaddress;
> recommendation T.33 (July, 1996)
> 
> Since T.33 itself incorporates T.30 by reference (for definition of the
> subaddress in the fax
> protocol), a T.30 reference is probably not needed
> 
> 2.  Revise example in 5.5 to use image/tiff instead of image/tiff-f to
> represent a TIFF-F 
> media type, consistent with the current consensus on this.  
> 
> James 

Done! It will appear on "addressing-02" edition.

Any other suggestions for the draft?

Claudio
Permalink | Reply |
headers
Larry Masinter | 6 Nov 1997 15:19
Picon
Favicon

Re: I-D ACTION:draft-ietf-fax-addressing-01.txt

The number of drafts that talk about encoding telephone numbers
into URLs and email addresses and DNS addresses is confusing.

I don't think we need 4 different standards, but I've not seen
much direct activity on getting these specs to work together.

Can you please review the current status of getting these specs
together? I don't think we'll get it through the IESG without
doing this.

Larry
--

-- 
http://www.parc.xerox.com/masinter
Permalink | Reply |
headers
Dan Wing | 15 Jul 1997 18:03
Picon
Favicon

Re: I-D ACTION:draft-ietf-fax-transport-00.txt

Because we neglected to send -00 to the Internet Drafts editor previously,
our "-01" is the first time they've seen draft-ietf-fax-transport, so it is
called "-00".  The -00 document available from the Internet Draft sites is
exactly the same as the -01 document I posted to ietf-fax <at> imc.org a few days
ago. 

Sorry for any confusion this might cause.

-Dan Wing
Permalink | Reply |

Gmane