Subject: RE: [VPIM] Analogy to Content-Duration for Faxes

From: "Neystadt, John" <[email-masked]>
Date: Tue, 8 Feb 2000 12:06:11 +0200

If I undestand correctly the Content-Duration header is applied not to
primary MIME header, but to MIME envelopes of individual body parts. Thus if
you have few TIFs or few voice attchements (or mix of each) you can indicate
length for each of them.

As to overloading the subject, this can be done only because of lack of
standard. I the conventional way should be MIME header so that software from
different vendors could interoperate.

I think Content-Length is bad header to put number of pages, since it used
in HTTP to indicate the octet-length of the body part. This would create
overloading.

So I propose - either to use same Content-Duration (this may be misleading
sematically) or to invent another header, like 'Content-Pages:'.

John Neystadt 
[email-masked] 
http://www.neystadt.org/john/ 

-----Original Message-----
From: Tony Kueh [mailto:[email-masked]]
Sent: Tue, February 08, 2000 3:40 AM
To: 'Glenn Parsons'; IETF VPIM List
Cc: [email-masked]
Subject: RE: [VPIM] Analogy to Content-Duration for Faxes

From an UM perspective, you could potentially have multiple faxes within one
message. How would one calculate the total length in the subject field? If
it was really part of the subject, then changing the content of a message
(ie. forward a fax) would require the update of the subject field.
 
Sounds like a lot of work.
 
Why not just keep the Content-Length header on the body part and have the
clients that wish to render a total length to dynamicallly pre-pend it or
set it on the rendered subject field on the fly?
 
-----Original Message-----
From: Glenn Parsons [mailto:[email-masked]]
Sent: Monday, February 07, 2000 8:07 AM
To: IETF VPIM List
Cc: [email-masked]
Subject: RE: [VPIM] Analogy to Content-Duration for Faxes

At one point we had proposed a 'Content-Length' header specifically for fax
page count.  I cannot remember if it was ever included in an RFC or not.
In practice, we have found it more practical to put thie information in the
Subject field.  Then the user will see the info in their GUI. 
Cheers, 
Glenn. 
---------- 
From:   Murray, Doug 
Sent:   Thursday, February 3, 2000 6:11 pm 
To:     'Neystadt, John'; [email-masked] 
Subject:        RE: [VPIM] Analogy to Content-Duration for Faxes 
Yes, it is very useful to have content duration in meaningful units such as 
seconds of audio (or video), pages of fax, etc. Most e-mail clients will not

display this information, however. 
The place that this information is most useful is within a TUI where it is 
useful to announce the number of pages in a fax, Word document or whatever 
so the recipient can decide whether to forward the document to a fax 
machine. 
-----Original Message----- 
From: Neystadt, John [mailto:[email-masked]] 
Sent: Thursday, January 27, 2000 3:27 AM 
To: [email-masked] 
Subject: [VPIM] Analogy to Content-Duration for Faxes 

Hi! 
I wonder if anybody came to need of Analogy to Content-Duration for Faxes to

indicate the number of pages. This is handy to present GUI idication of fax 
size in pages (as in seconds for voice) instead of KBs. 
Does somebody needs this in addition to us? 
Regards, 
John Neystadt

---

From: Tony Hansen <[email-masked]>
Date: Tue, 08 Feb 2000 09:42:52 -0500

In addition to its use within HTTP, one of the common mailbox formats
also uses Content-Length: to hold the number of octets in the message.
Systems that use this mailbox format also rewrite any existing
content-length: header before storing the message into the mailbox to
have the correct number of octets.

A different header is definitely in order.

People should also be aware of RFC 2076, Common Internet Message Header
Fields. (It's currently being updated as
draft-palme-mailext-headers-02.txt.) Any proposals for new message
headers should be checked against the lists in there to see if they're
already being used somewhere else.

	Tony

"Neystadt, John" wrote:
> 
> If I undestand correctly the Content-Duration header is applied not
> to primary MIME header, but to MIME envelopes of individual body
> parts. Thus if you have few TIFs or few voice attchements (or mix of
> each) you can indicate length for each of them.
> 
> As to overloading the subject, this can be done only because of lack
> of standard. I the conventional way should be MIME header so that
> software from different vendors could interoperate.
> 
> I think Content-Length is bad header to put number of pages, since it
> used in HTTP to indicate the octet-length of the body part. This
> would create overloading.
> 
> So I propose - either to use same Content-Duration (this may be
> misleading sematically) or to invent another header, like
> 'Content-Pages:'.

---

From: [email-masked]
Date: Tue, 08 Feb 2000 11:07:40 -0800 (PST)

> A different header is definitely in order.

A really good point. Content-length, unfortunately, should be avoided at
all costs.

				Ned

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 8 Feb 2000 12:58:18 -0800

Rather than inventing a new header for every kind of
content attribute you might want to declare in the
header about a particular media element, how about registering
a "pages" feature (using RFC 2506), using the Content-Features
header (draft-ietf-conneg-content-features-02.txt), and the
media feature syntax (RFC 2533) for:

Content-Features: pages=10

to note a 10-page document.

This requires no overloading, allows interesting combinations
of feature expressions, and has a clear extension mechanism
which doesn't require creating a new header every time you want
to say something new.

Larry
-- 
http://larry.masinter.net

---

From: [email-masked]
Date: Tue, 08 Feb 2000 17:03:55 -0800 (PST)

> media feature syntax (RFC 2533) for:

Good point, and an excellent idea. I fully support it.

> to note a 10-page document.

Might even want to have an additional attribute to say what sort of "page"
you're talking about.

				Ned

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 9 Feb 2000 18:34:39 -0800

# > Content-Features: pages=10

# > to note a 10-page document.

# Might even want to have an additional attribute to say what sort of "page"
# you're talking about.

RFC 2534 already registers 'ua-media' tag with values such as 'screen-paged'
and 'stationery' (most likely the kind of pages you'd want with faxes), and
a 'paper-size' tag with additional token values. At the time RFC 2534 was
written, we were focusing mainly on media features for recipients rather
than
for content; you might still want to characterize a fax recipient as having
a maximum number of pages its willing to receive, though.