headers
MAEDA toru | 1 Feb 2001 13:08
Picon
Picon

goals for Terminal Mode


Hi, forks

I explained about Terminal Mode in the fax wg at San Diego on December,
that ITU-T requested to consider adding a new charter about Terminal Mode.

I tried to define the goals for Terminal Mode as follows.
This is just beginning of discussion.
I want have creative discussion about Terminal Mode
over mailing list before the Minneapolis IETF meeting on March.

Regards,

Toru MAEDA
CANON Inc.

Goal for Terminal Mode

1. Introduction
The specification defines Terminal mode carriage of
facsimile data over the Internet, and its functionality necessary
for achieving reliability, timeliness and capability negotiation for
Internet mail that is on a par with classic T.30 facsimile.

Terminal Mode is intend to implement features of all classic T.30 facsimile 
over
Internet, providing a level of service that approximates the level
currently enjoyed by fax users, and providing all fax-specific features
that will be implemented in an embedded fax device software working on
G3 fax based system with limited memory size and CPU performance.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Burger | 1 Feb 2001 16:22

FW: I-D ACTION:draft-ietf-vpim-hint-02.txt

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

	Title		: Message Context for Internet Mail
	Author(s)	: E. Burger, E. Candell, C. Eliot, G. Klyne
	Filename	: draft-ietf-vpim-hint-02.txt
	Pages		: 19
	Date		: 26-Jan-01

This memo describes a new RFC822 message header, 'Message-Context'.
This header provides information about the context and presentation
characteristics of a message.
A receiving user agent (UA) may use this information as a hint to
optimally present the message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-vpim-hint-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
McIntyre, Lloyd | 2 Feb 2001 02:08
Picon

Implementers Guide comments


Tamura-san,
I would like to comment on two items, 1) ambiguity with regard to the
definition of "word" size and 2) comments on Section 5 of the Implementers
Guide. Please see below.

Thank you,
Lloyd

1) Word Size

The requirement to begin an IFD on a "word" boundary is specified in TIFF
6.0. TIFF-FX is simply reiterating this requirement. Since TIFF 6.0 is the
based reference for TIFF-FX, any clarification of ambiguity associated with
the definition of "word" size should be done in TIFF 6.0, not TIFF-FX. It
may, however, be appropriate to add an item to Section 5.1 of the
Implementers Guide giving guidance on interpretation of this ambiguity. I
propose revising Section 5.1 of the Implementers Guide V4.0 to read as
follows:

5.1 IFD Placement in TIFF file & Profile S Constraints

a) An IFD is required, by TIFF 6.0, to begin on a word boundary, 
   however, there is ambiguity with regard to the defined size of
   a word. A word should be interpreted as a 2-byte quantity. This
   recommendation is based on examination of Figure 1 and the
   definition of IFD Entry, Bytes 8-11, found in Section 2 of 
   TIFF 6.0.

b) Low memory devices, which support resolutions greater than the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hiroshi Tamura | 5 Feb 2001 01:28
Picon

Re: Implementers Guide comments

> 1) Word Size
> 
> The requirement to begin an IFD on a "word" boundary is specified in TIFF
> 6.0. TIFF-FX is simply reiterating this requirement. Since TIFF 6.0 is the
> based reference for TIFF-FX, any clarification of ambiguity associated with
> the definition of "word" size should be done in TIFF 6.0, not TIFF-FX. It
> may, however, be appropriate to add an item to Section 5.1 of the
> Implementers Guide giving guidance on interpretation of this ambiguity. I
> propose revising Section 5.1 of the Implementers Guide V4.0 to read as
> follows:

OK.

> 5.1 IFD Placement in TIFF file & Profile S Constraints
> 
> a) An IFD is required, by TIFF 6.0, to begin on a word boundary, 
>    however, there is ambiguity with regard to the defined size of
>    a word. A word should be interpreted as a 2-byte quantity. This
>    recommendation is based on examination of Figure 1 and the
>    definition of IFD Entry, Bytes 8-11, found in Section 2 of 
>    TIFF 6.0.

Ok. I think everybody can agree to the above.

> 2) Section 5 of the Implementers Guide
> 
> Most of errors document in Section 5.2 were NOT experienced during
> interoperability testing, as stated.
> 
> Recommendation
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hiroshi Tamura | 6 Feb 2001 08:07
Picon

Re: Progress update: negotiation

At first glance of draft-ietf-fax-content-negotiaion-04.txt,
lots of points are clarified, I think.

> The draft is all there now, but there are some specific points I would like 
> to discuss.  One in particular that the authors jointly feel would benefit 
> from group discussion has arisen from the late addition of a negotiate-down 
> example:  if the sender has an alternative that assumed _lower_ 
> capabilities than the version actually sent, should those lower 
> capabilities be described explicitly by a Content-alternatives 
> header?  When the draft is available, I'll post more details of this 
> issue.  Other points regarding which WG revciew is explicitly requested are:

Negotiation-down example itself is good. Thanks for taking it.

In my feeling, it is better to describe lower or baseline capabilities
in Content-alternatives explicitly, but not mandatory.
All terminals or software must support baseline one at least.

>    o  Cache-control for recipient features? (e.g. colour offered for
>       selected senders only). (3.2.3)

I understand under some conditions the receiver do not want to
announce his capabilities. If you take care, you can write something
in Appendix A(implementation issues).

>    o  Check the correct final disposition for lost message data (3.4)

An suitable type do not exist in the current definitions,
but "deleted" is ok for me.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hiroshi Tamura | 7 Feb 2001 06:19
Picon

Re: goals for Terminal Mode

Folks,

Our group was requested to reply to ITU-T SG16. Next SG16 meeting
will be held at the end of May. We have time to consider.
But, at Minneapolis meeting, I would like to have some directions.

I think Maeda-san is preparing two I-Ds. One is about the terminal mode,
which he writes below. The other is about ifax status information.

About the terminal mode, we already have a letter from ITU-T and
He writes his goals below. If there are comments, please kindly say in ML.
Any comment are welcome by him.

W.R.T. the ifax status information, there are no information.
We wait for his I-D or something.

Regards,
--
Hiroshi Tamura, Co-chair of IETF FAX WG
E-mail: tamura <at> toda.ricoh.co.jp

From: MAEDA toru <maeda.toru <at> canon.co.jp>
Subject: goals for Terminal Mode
Date: Thu, 01 Feb 2001 21:08:44 +0900

> 
> Hi, forks
> 
> I explained about Terminal Mode in the fax wg at San Diego on December,
> that ITU-T requested to consider adding a new charter about Terminal Mode.
(Continue reading)

Permalink | Reply | 0 comments |
headers
MAEDA toru | 7 Feb 2001 11:09
Picon
Picon

E2E communication over SMTP

Hi, forks,

I have mailed the goals for Terminal Mode into the mailing list last week.
I proposed that the end to end communication over SMTP in the goal.
We have been discussed about the store and forward IFAX for long time
and developed Simple Mode and EIFAX.
My question is why do we need the store and forward system for Internet fax.
In case of communication to Email client such as PCs,
the existing S&F mailing environment must be used.
Since the Terminal Mode IFAX devices will run and will be connected to 
iternet all time,
end to end communication is more practical and more beneficial.

I think it will be easy to connect to the receiver by SMTP as end-to-end,
when the destination address is the global address instead of the Email 
address.

Any comments?

Regards,

Toru MAEDA

--------------------
MAEDA TORU
MIE Development Div. 2
CANON Inc.
--------------------
(Continue reading)

Permalink | Reply | 10 comments |
headers
Toyoda, Kiyoshi | 7 Feb 2001 11:58
Picon

Re: E2E communication over SMTP

Maeda-san,

MAEDA toru wrote:
>Hi, forks,
>
>I have mailed the goals for Terminal Mode into the mailing list last week.
>I proposed that the end to end communication over SMTP in the goal.
>We have been discussed about the store and forward IFAX for long time
>and developed Simple Mode and EIFAX.
>My question is why do we need the store and forward system for Internet fax.
>In case of communication to Email client such as PCs,
>the existing S&F mailing environment must be used.
>Since the Terminal Mode IFAX devices will run and will be connected to 
>iternet all time,
>end to end communication is more practical and more beneficial.

In the most enterprise, fire wall rejects SMTP to the terminal other than
mail server. If we want end to end communication in the Internet, we need
security policy of fire wall to allow to open the port of SMTP to the IFAX. 
On the other hand, end to end communication is practical in the Intranet 
and we can get benefits deifferenet from S&F communicaton.

I think that IPP has the same problem and the IFAX which communicate directry 
between terminals on T.38. If we can solve the problem of fire wall, I 
prefer terminal mode than T.38 because SMTP protocol is simple and easy 
to implement. 

Kiyoshi Toyoda
(Continue reading)

Permalink | Reply | 5 comments |
headers
Monica Merlotti | 7 Feb 2001 16:56
Picon

Fax-Sendmail

Hallo,
I need some help.
I would like to send a fax to the address: /dd.fax=number <at> mydomain, but
the sendmail (Berkely 8.11),
 answers to me with the following error msg "550 5.7.1
/dd.fax=number <at> mydomain.. Cannot mail directly to files".

Which configuration option or something like this I have to add to my
sendmail to accept msg to /dd.fax=......

Many thanks.
Monica Merlotti
Permalink | Reply | 5 comments |
headers
George Pajari | 7 Feb 2001 20:16

Re: Fax-Sendmail

> I would like to send a fax to the address: /dd.fax=number <at> mydomain, but
> the sendmail (Berkely 8.11),
>  answers to me with the following error msg "550 5.7.1
> /dd.fax=number <at> mydomain.. Cannot mail directly to files".
>
> Which configuration option or something like this I have to add to my
> sendmail to accept msg to /dd.fax=......

Unless sendmail has been configured (in sendmail.cf) to recognise the
'/dd.fax' pattern in the local-part of the address it will think you are
trying to email to a filename.

Of course, not only do you have to configure sendmail.cf to recognise a fax
address, you need to provide a delivery agent that will accept the message
from sendmail and attempt to deliver it by fax.

Sendmail does not come with such a delivery agent but there are commercial
(such as ours) and open-source solutions to accomplish this.

If you wish to "roll your own" then an excellent place to start is with
O'Reilly's definitive book on sendmail
(http://www.ora.com/catalog/sendmail2/) which will explain how to configure
sendmail to recognise special email addresses and how to interface delivery
agents.

George Pajari
Faximum Software
Permalink | Reply | 4 comments |

Gmane