ietf
[Top] [All Lists]

Re: capitulation to closed organizaions (was Re: rfc publication suggestions)

2001-03-13 00:00:04
Valdis,

Thanks for your reply:

First off, "directly from my microphone" is *highly* unlikely to be
incredibly factual. 

No more or less so than the creation timestamp, which is almost always
the first time a file was saved, sometime after it was created.

It's *conceivable* that your MUA reads directly from your system's
equivalent of /dev/microphone, base64's and writes directly to
the SMTP datastream outbound

Yes, that is what two of my MUAs do on certain platforms, and I think 
that is also exactly what Qualcomm's Eudora does on multiple platforms.
Certainly "Pocket Outlook" for WinCE also does it, bun until Microsoft 
gets their act together regarding address book access and scriptable 
message transmission, I'm not going near any Outlook family products.
Whether the buffer is in RAM or on the filesystem is incidental.

makes the attachment of multiple bodyparts "interesting"

The "inline" vs. "attachment" are still there to indicate whether the 
part is intended to be presented or stored on arrival.

So... what you *really* care about, I suspect, is "was this audio
clip recorded while composing the message" or "is this a clip from
yesterday he attached".  What you want is a *datestamp* of when
the recoring was made, and an identification of *who/what* it
is a recording of (is it me saying it yesterday, or a sound bite
of something Steve Bellovin said at an IETF plenary a while ago)?

Good point, but here is another example:  suppose I sent you a 
picture as an attachment to an email.  Would you like to know 
whether it was attached from my camera or scanner (or filesystem)?
Sure, the datestamps are important, but don't have everything you 
might want to know.

What if it's a composite of several different audio clips? ...

That kind of thing, and the other scenarios you asked about, are 
really more of what the filename or internal description fields of
audio file formats are for.
 
And of course, there's the *biggest* issue - if it's *really* important
to know whether it came off the microphone or file system,  how do
you *verify* the field values?

Such source device information isn't any more or less secure than the 
datestamps -- both can be easily altered.  But it is easy to make use 
of information that might not always be trustworthy.  For example, 
you might make a .forward script to send all your inline audio sent 
from microphone devices to your wireles PDA or cellphone or voicemail, 
while ignoring inline audio from other devices.  What's the worst 
that can happen?  Someone spoofs your .forward script and you get 
spam in your cellphone, until you block it.  So what?  This sort of 
thing is going to be a problem eventually, and I don't see why it 
isn't better to address it sooner rather than later.

Anyway, you know that you almost always have many Content- headers 
and this "single parameter" -- while not very useful in isolation -- 
would preserve important information that would otherwise be lost.  

Can you think of a better way to keep that information in band?

Cheers,
James