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

From: "Glenn Parsons" <[email-masked]>
Date: Fri, 10 Mar 2000 11:00:45 -0600

Now I remember :-)

It was one of the opitions described in <draft-ema-vpim-imap-01.txt> for
message length indicator.  I have exerted the section below.  The original
intent of this was for clients to get this information via IMAP and present
it on the client.

Despite the ugliness of subject overloading, I am afraid that is what a lot
of products implement.  I guess the question is do we want to endorse this,
or create a better mechanism (like the Conneg suggestion or one of the
others below).  If we choose the latter, the client vendors have to agree to
implement it, or the industry will likely tend to what they do now.

Glenn.

8.  Message Length Indicator     In the cases of large attachments, small clients and slow links      there is also a need for the client to see the length of the      message in a suitable format before opening it.      A message length indicator suitable for voicemail and fax should      indicate the length of the message using number of seconds for a      voice message and using number of pages for a fax message.  The      client MUST support the chosen method.  There are three suggested      methods and among them, 8.3 is favoured:   8.1  MIME Header Content-Duration as described in RFC 2424 [7]     For fax messages a new MIME Header, Content-Page-Length, would be      defined, similar to Content-Duration with the exception that number      of pages would be specified, rather than number of seconds. (e.g.      Content-Page-Length:3).  This would be created at originator.   8.2  FETCH item USERSIZE similar to FETCH items described in      IMAP4rev1 [3].  This would be creat!
ed at reception.   8.2.1  USERSIZE is a non-negative number.  Its meaning depends on      document type.     C: abc FETCH 1:2 (USERSIZE)     S: *1 FETCH (12)     S: *2 FETCH (57)     S: abc FETCH completed.   8.2.2  USERSIZE is a pair of number and unit.  There is a small set      of unit tokens.     C: abc FETCH 1:2 (USERSIZE)     S: *1 FETCH (12 pages)     S: *2 FETCH (57 seconds)     S: abc FETCH completed.   8.2.3  USERSIZE is a sequence of pairs, in case something extends in     more than one unit.     C: abc FETCH 1:2 (USERSIZE)     S: *1 FETCH (12 lines)     S: *1 FETCH (57 pages 6 hours)     S: abc FETCH completed.     Servers that support USERSIZE SHOULD list the USERSIZE capability      in response to the CAPABILITY command.   8.3  Message length indicated as a parameter of an existing Header Field
[4].       This would be created at the source.  This method would allow the
message      length to be passed to the client by default.         8.3.1  Content-Type Header Field        Content-Type=audio/*; length=50        Content-Type=image/tiff; pages=3        8.3.2 Subject Header Field        Subject=Voice Message (0:04)        Subject=Fax Message (3)        The advantage of the subject field is that it is automatically
displayed        to the user.

> ----------
> From: 	Parsons, Glenn [NORSE:6L45:EXCH]
> Sent: 	Friday, February 4, 2000 6:08 am
> To: 	[email-masked]
> 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: [email-masked]
Date: Sat, 11 Mar 2000 16:43:41 -0800 (PST)

> of products implement.  I guess the question is do we want to endorse this,

Well, an additional question is whether you'll be _able_ to endorse it in a
standard. Let me say right now I'm strongly opposed to such mechanisms. For one
thing, endorsing one may open the door to endorsing lots of others. And unlike
other recent discussions like the "-xml" tag business, this is NOT an academic
concern: There are so many subject line label thingies floating around already
it isn't funny.

Another issue is the potential for conflicting use. I would not care to
bet that there isn't a conflicting use of parenthesized colon-separated
numeric values other there -- indeed, I'm pretty sure I've encountered a couple
over the past few years. Stuff that looks like it has a fair potential
to fail to interoperate doesn't make it into IETF standards.

And finally, past experience with embedding information as tags in unrelated
header fields, even in contexts far less overloaded than the subject field, has
been dismal at best. Two examples come immediately to mind: Storage of original
and recipient information in comments in Received: fields and storage of
certain delivery/return options in comments in To:/Cc:/Bcc:. Both of these
uses have been the source of numerious operational problems.

> implement it, or the industry will likely tend to what they do now.

Conneg gives us a framework for this stuff. I think we should use it.

				Ned