Dynamic recoding of content (was: The issue of mime parsing)

With reference to previous discussion:
The thing with dynamic recoding of content is that a user does not
only want this to work in the context of email. In the ideal case
it should work for every piece of content he accesses, regardless
whether its origin is an email, a 'media'-link on a webpage, a file
on an electronic "bussnies card" obtained in the form of a mini-CD,
etc etc.

Nevertheless, it is an interesting problem that I guess may, or may
not, be included in an specification for "im2000". I imagine
a content recoding system
  i) not being an integral part of the "email" system itself.
  ii) having most of its logic implemented within the
      receivers "media player", but (possibly) using the same
      kind of communication that the "email" system uses. (Which
      I guess is why the subject may be on topic here)

Suggestion: An im2000 email use MIME multipart/alternative to list
all the content-type:s that the sender himself can provide inside the
notification file. All this information is handed to the receivers
im2000-compliant media player which analyzes his local codecs as well
as all possible chains of re-coding servers that can be setup between
sender and receiver, using the "best" option. This approach should
work regardless of whether the sender provides streaming or static
content.

clemens:
> nephew andy wants to send ... [full text in mail dated 27 Mar 2003
> 23:05:56 +0100]

Lets for the moment discard all info on how you expect this to be
implemented, and lets just look at the background and the
expectations of the end-point users in your scenario:

* the sender A (andy) wants to send the receiver B
  (bertha) a music + speach audio file.
* A has a working im2000 email account, but no other
  identifiaction tokens.
* B should recive the email, but with the speach part
  converted into text because she does not hear well
  and has configured her media player accordingly.

Here is my take on how I imagine this to be implemented:
 i) A:s MUA logs in on his outgoing email server to obtain his
    private key. No keys are available, so the MUA generates a new
    key-pair and uploads them.
 ii) A:s MUA creates an im2000 email by combining the audio file
    with a notification file describing the content (including a
    hash of it) and uses the key to sign the notification file.
 iii) The message is uploaded to A:s outgoing im2000 email server.
 iv) A:s outgoing mail server sends the notification file to B, where
    B:s incoming mail server is configured to accept the notification
    although the signers key is previously unknown.
 v) B:s MUA connects to her incoming mailserver and downloads the
    notification file.
 vi) B:s MUA hands the media links and their MIME-types to the
    media player which recognize that the MIME-type 'audio' has a
    very low "priority". It goes through local codecs and all
    external recoding services it knows about (both free and ones
    that cost money). It cleverly assigns priority values to all
    possible chains of recoding and picks the one with highest
    priority. This time it decides to go through an external
    speech-2-text service.
 vii) B:s MUA automatically sends an im2000 email to the
    speech-2-text service and attach the content that currently
    resides on A:s server, specified as:
      "https://example.com/fk3j39enh3/birthday.mp3".
    The recoding service is configured to reply with an im2000 email
    with the recoded contents attached. (Note that "attached" only
    means that the notifcation includes an adress to the content)
 viii) B:s media-player downloads the content from the server and
    display it.

If there are any additional end-point user expectations that this
does not handle, please point it out.


//Rickard