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

From: "James P. Salsman" <[email-masked]>
Date: Mon, 12 Mar 2001 12:47:39 -0800 (PST)

> perhaps a more useful mode of discussion would be to determine what criteria
> should be used for the rfc publication process and whether incremental
> improvements are possible, independent of encoding changes.

When someone submits a new Content-disposition value or parameter 
registration -- http://xml.resource.org/public/rfc/html/rfc2183.html --
the Area Directors and IESG would be best served to refrain from deferring
the registration decision to secretive industry consortia who have only to 
do with one of the many uses of the header.

Does anyone disagree?  If so, why?

If not, I will re-submit the "device" parameter registration.
  
Cheers,
James

---

From: [email-masked]
Date: Mon, 12 Mar 2001 14:03:26 -0800 (PST)

> do with one of the many uses of the header.

First of all, since IANA is the resistration agency specified by RFC 2183, you
appear to be asserting that IANA is "a secretive industry consortia". If so, I
completely disagree with this characterization. IANA isn't secretive and it
isn't an industry industria in any sense that I understand the words.

Second, you appear to be assigning a lot more weight to the registration
"decision" than it deserves. This is a *registration* process. That means you
say "I want this registered" and IANA checks to see that it doesn't conflict
with anything that's already there,  and if it doesn't it says "OK".

Now, having said that, I will also point out that RFC 2183 is unfortunately a
bit behind the times in terms of registration procedures. In particular, the
registration of such things as type and disposition parameters has been shown
to have nontrivial technical repercussions in fair number of cases. IANA has
neither the expertise nor the desire to perform technical evaluations of this
sort, so when they come up they usually contact the IESG and ask how to
proceed.

The way more modern registration procedures work is that the IANA refers
registrations it receives to a reviewer appointed by the IESG. The reviewer
then reviews the request, applying the registration criteria specified by the
relevant standard. If the registration meets those criteria it is approved, it
not it is returned with an explanation of what is wrong and how to fix it.
IANA's contribution to this sort of registration is to handle the purely
administrative aspects of this process.

When RFC 2183 is next revised its registration procedure should be updated to
bring it into alignment with similar procedures for things like media types,
charsets, and languages. I also note that the review criteria probably need to
be spelled out in more detail.

> Does anyone disagree?  If so, why?

I certainly do. See above.

> If not, I will re-submit the "device" parameter registration.
  
Not having seen any previous attempt to register a "device" content-disposition
parameter, I'm not clear on what you're talking about here. If you're referring
to your http://www.bovik.org/device-upload.html proposal, as far as I can tell
that doesn't specify a device content-disposition parameter. Device is an HTML
attribute, which is an entirely different thing.

Perhaps you've revised this proposal so it uses a new "device"
content-disposition parameter. If that's the case, while I see no obvious
procedural problem with the registration separate from the overall proposal, I
have to wonder what the value of such a parameter is in isolation. It seems
tightly coupled to the proposal as a whole and unless the entire proposal is
approved (and that appears to be a W3C and not IETF matter) I'm not sure what
value it has.

				Ned

---

From: "James P. Salsman" <[email-masked]>
Date: Mon, 12 Mar 2001 18:41:15 -0800 (PST)

Ned,

Thanks for your message in reply:

> First of all, since IANA is the resistration agency specified by RFC 2183, 
> you appear to be asserting that IANA is "a secretive industry consortia".

Sorry, I meant the W3C, which has multiple, specific, and far-reaching 
non-disclosure terms even for independent participants as part of its 
by-laws, completely unlike IANA.  My opinion of the W3C's culture of 
secrecy is so low that I support reverting the entire text/html family of
type registrations back to the IETF.  I don't know how closely you are
watching the progress of the W3C working groups, but many of them are more
than a couple of years behind their own schedules.  If they were IETF 
Working Groups, the stalled and blocked WGs would be reviewed and closed, 
but the W3C needs their lucrative membership fees, the participants love 
the deductable junkets and ill-informed prestege, so I predict the W3C WGs 
such as XForms (to which I was referred by the previos Applications AD) 
will probably be around soaking up time and resources for as long as HTML 
is being used.  Worse yet, some of the people with the most authority in 
the W3C have clearly vested interests in closed, proprietary protocols 
such as WAP/WML.  Can you think of one function of the W3C that would not 
be better served by the IESG and IETF?

>...the registration of such things as type and disposition parameters has
> been shown to have nontrivial technical repercussions in fair number of
> cases. IANA has neither the expertise nor the desire to perform technical
> evaluations of this sort, so when they come up they usually contact the
> IESG and ask how to proceed.
> 

That is all I would ask for the "device" disposition parameter 
registration.  But that is nowhere near my experience.  What actually 
happened, was that an Area Director at the time also assumed that the 
registration had no purpose outside of multipart/form-data HTML upload 
forms, and told me to wait and see what the W3C decided, when the whole 
reason that I had filed the registration is that the XForms working 
group chair and staff contact had told me that they would wait and see 
what the IESG did with the Content-disposition registration before 
further agendizing my device-upload proposal.  

When I pointed out that the situation was a Catch-22, the XForms chair
apologized profusely but made it clear that I wasn't allowed to say 
anything about it.  When I balked at that, the W3C complained to my 
company's Advisory Committee representative, who complained to my 
Cisco manager, and shortly thereafter I was fired without explaination.
Although I still don't know, I suspect I was accused of violating my 
non-disclosure agreements.  I will never forget how I was treated.

> Not having seen any previous attempt to register a "device"
> content-disposition parameter....
>
> content-disposition parameter. If that's the case, while I see no
> obvious procedural problem with the registration separate from the
> overall proposal, I have to wonder what the value of such a parameter
> is in isolation.

Consider multiple devices producing or accepting the same media type.  For 
example, if I send you an email with an audio/basic attachment, is there 
value in your knowing whether it came directly from my microphone or off 
of my file system?  I think there is.  I would really like to know what 
you think.  Is there some better way to communicate the source information?

> I certainly do. See above.

And now that you know I was referring to W3C instead of IANA?
 
Keith can probably point you to the original registration request, or 
let me know if you want me to send a copy.

Cheers,
James

---

From: [email-masked]
Date: Tue, 13 Mar 2001 01:03:56 -0500

> you think.  Is there some better way to communicate the source information?

Nope. No value in knowing. At least not at the level that a single parameter
gives you.

First off, "directly from my microphone" is *highly* unlikely to be
incredibly factual.  More likely, as you compose the message, you decide
you need an audio clip, and when you record, it goes into a temporary
file on disk before being base-64'ed and included as part of the outbound
stream.  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, but that is (a) painful to contemplate
and (b) makes the attachment of multiple bodyparts "interesting".
So we'll take it as a given that the audio *did* (at least potentially,
for systems that have in-memory file sytstem caches) hit your filesystem
at some point.

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

In addition, even if it was recorded "right now", you need to have
identification if the file was edited (even if it was merely to
remove dead air, pauses, stutters/stammers, background noise, etc).
You also need to identify if the audio is a composite mixed from
several sources (I could create a clip of me speaking with a
background of a MIDI transcription of a Bach concerto - was this
from the microphone that my voice came from, the software synthesiser
that created the Bach, or the software mixer that combined the two?

What if it's a composite of several different audio clips? I've seen
rap songs that the credits run to several column-inches due to the
heavy use of sampling.

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?  Lest you think this is purely academic,
I suggest poking around the Bugtraq archives and seeing how many CGI packages
have broken because they blindly trust 'HIDDEN' form input "because nobody
would change the price of a CD player".  Or Napster offering to filter
filenames "because nobody would ever misspell Metallica".

Other than that, I don't see any problems. ;)

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: "James P. Salsman" <[email-masked]>
Date: Mon, 12 Mar 2001 22:49:37 -0800 (PST)

Valdis,

Thanks for your reply:

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

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 13 Mar 2001 08:57:03 +0100

>If not, I will re-submit the "device" parameter registration.

The registration procedure you refer to starts out

>10. Registration of New Content-Disposition Values and Parameters
>
>     New Content-Disposition values (besides "inline" and "attachment") 
> may be defined only by Internet
>     standards-track documents, or in Experimental documents approved by 
> the Internet Engineering Steering
>     Group.

Could you also mention the I-D name of the draft that you think should be 
published as an Experimental or Standards-track RFC along with this?
The reason for the relatively high bar on this one is that
(from what I remember, vaguely, from last time, there were people who did 
not like your approach, but I don't even remember the I-D name....)

Note that like all IESG decisions, the appeals process can be used if you 
think that an IESG decision is wrongly done; see RFC 2026.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 13 Mar 2001 09:09:00 +0100

>Sure, the datestamps are important, but don't have everything you

actually all a standard that trusts the end-users can accomplish is whether 
*the sender wants you to react as if* the picture was sent straight from a 
camera; he can't verify the origin of the picture.

for that purpose, I think "here's my hairdo of the day" in the text 
preceding the picture is more effective (and more informative) than a 
content-disposition header.

(and I think overloading the content-disposition header is the Wrong Thing, 
anyway - how the sender composed the message is not a content disposition.)

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 13 Mar 2001 10:35:36 -0500

James P. Salsman wrote:

> [...]  suppose I sent you a 

The human reading the email _might_ want to know, in which case the 
body of the message is the right place to put that information - not 
a header that they don't (and shouldn't) see.

The Content-Disposition header should not be about where the body 
part _came_from_ - it is about where it should _go_to_ (its 
Disposition, not its Source).

If you think that there is a reason to tell the MUA about the source 
(personally, I don't see what I would do with such a thing), then 
argue for a new header that does that (and get mired in the 
security/trust issues already cited elsewhere), but don't try to 
change the usage of Disposition.

---

From: [email-masked]
Date: Tue, 13 Mar 2001 12:03:07 -0500

> that is also exactly what Qualcomm's Eudora does on multiple platforms.

Ouch.  What happens if you decide that you want to *cancel* what you've
recorded?  When I say *directly*, that's what I mean.  When the 150th
byte of audio is input from the microphone, the SMTP MAIL FROM and RCTP
TO have already been sent, the RFC822 headers have been sent, the MIME
headers for this recording have already been sent - makes it difficult
to cancel at THAT point.

A simple thought experiment shows that Eudora does *NOT* do this.  Proof -
after you finish recording, you *still* have to hit 'send'.  Ergo, during
the time between 'finish' and 'send', that audio is stored someplace.

> part is intended to be presented or stored on arrival.

No.. What I *meant* was that unless you spool the audio into a temporary
file, as noted above, *creating* the e-mail with multiple attachments
is interesting.

> audio file formats are for.

Right.  And your proposal adds more value how?

> while ignoring inline audio from other devices.  What's the worst 

Actually, that's probably a bad criterion - I've had people ramble into
my voicemail until it fills up, and I don't want THAT being beamed to my
cellphone, while ignoring a short but important 10-second audio clip
just because it happened to have existed as a disk file at one time.

And what do you propose to do about the distinction between an MUA that
supports inline recording (and thus tags it "microphone") and the *SAME
USER* with the *SAME INTENT* who's message gets tagged with "disk file"
merely because the MUA he has installed on *this* machine doesn't support
inline recording, so he was forced to attach an audio part he recorded to
disk via an external program 15 seconds before?  I send it with Eudora,
you'll listen to it, I send it with Exmh plus a config hack, you'll listen
to it, but I send it with Exmh without config hacks, you'll not listen because
it wasn't recorded inline?  What's the logic here?

In addition, there's another issue here - if you send me an attachment
flagged as "microphone", what is the proper handling if I forward the
message?  When I forward it, it's not microphone, it's a disk file.
And it's quite possible that the headers can't be modified because they're
covered by a PGP or S/MIME signature.

---

From: "James P. Salsman" <[email-masked]>
Date: Tue, 13 Mar 2001 19:03:18 -0800 (PST)

Scott,

Thanks for your message:

>From slawrence virata.com Tue Mar 13 07:38:11 2001
>

You are absolutly right.  I should try a registration for a new part
header, "Content-source-device:" and use "X-content-source-device:" 
in the mean time.

Does anyone else think there would be value in such a header, even if 
it were incompletely reliable?  

Since this trancends just audio, would VPIM still be an acceptable WG?

Cheers,
James

P.S.  Valdis:  TCP requires its input to be buffered.  You must have 
been thinking of RTP or some other UDP-like destroyer of audio quality.

---

From: [email-masked]
Date: Wed, 14 Mar 2001 04:27:45 -0500

> been thinking of RTP or some other UDP-like destroyer of audio quality.

No, I wasn't thinking of RTP.  What I *specifically* stated was that
an MUA would probably record any audio into a temporary file and THEN
send it out.  YOu don't hit 'SEND' and then 'RECORD' so you ship
the data out in real time (at least not for any SMTP I've seen).
The situation for HTTP upload is of course different - that *coould*
be a case of hitting 'SUBMIT' first and then 'RECORD'.

Think - where is your audio in Eudora during the time between when you
stop recording and when you hit 'SEND'? Yes, it's in a disk file. ;)