im2000 protocol base, was Re: Dynamic recoding of content

Rickard Armiento <[email protected]>:

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

it cannot be any otherway, since we cannot define the entire im2000
protocol "world" right now.  this _must_ be an extensible protocol.

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

and this should be one of possibilities, but only one of them.  when
im2000 is extensible and in this sense covers all bases, it will
neccessarily be reflected in its tiniest parts ("media player") as
well.

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

i'd even suggest leaving MIME and all that implementation dependant.

what could an extensible protocol look like?  it can't define every
"command" ever to be seen py participants, because new commands will
pop up all over.  so how can new semantics be defined _within_ a
protocol?  future implementors will answer this question with
programs.

my suggestion is this:  im2000

- can be visualized as connected nodes
- a node connects to other nodes by messages carrying headers
- every node may add or remove any of the headers it sees
- for im2000, nodes only connect to trusted nodes, ie. nodes they
  know a key of
- "if you trust me, you get a hug  :)"  a node receiving a work
  packet (message) knows the sending node by its, say, IP, and the
  authenticity of the IP by the nodes signature.  in return for the
  trust (as a moral/monetary value if you like) it will perform
  something for or on behalf of the sender
- "we may see many revokation signatures!" a communication can be
  successful or not.  if nodes do something which eventually turns
  out to making no sense or even be contraproductive, trust is
  withdrawn and they will receive less messages in the future
- every new message needs a "Path-ID"
- Path-IDs must be large, but not secret values that cannot not
  feasably be guessed
- nodes send state information or results only about Path-IDs
  specifically requested, and may not let any external entity know
  about the Path-IDs they currently know about
- (specialized?) nodes should be able keep state info, in order to
  provide a "roll back" mechanism for failed parts of a communication

such a framword makes possible the notion of "agents".  imagine
"voters" that oversee (parts of a) communication and initiate failure
operations, which could result in rejection messages to be generated
and the degrading of trust values of other nodes.  or "insurers" that
are stores beeing capable of resetting (parts of a) communication in
order to let other nodes to give it a try (fallback).  or "converters"
that receive certain user-data types and send it in another format.
or "stores" which provide the user-data once other nodes (and finally
the receivers MUA) approach them with a Path-ID.  or "routers" which
keep lists of nodes and their specific capabilities, so they can
match them and set (IP, Path-ID, data-type) tuples as the parts of
the network capable of handling some communication.

of course, for im2000 "key" agents have to keep association lists of
user-IDs and their currently valid keys, together with trust values
in the form of signatures.  i wonder if key servers should have
priviliges in im2000 in that their own trust cannot be as easily
manipulated by other nodes, but i'm really not sure about this.  the
theory sure looks much prettier without such special cases, and an
ideal world wouldn't need them.  but reality will soon evoke hacked
or malicious nodes that, for example, keep sending failure
notifications to degrade nodes under attack and thereby mobbig or
ousting them out of the 'net.  any ideas on this?  the requirement of
nodes sending/answering only valid Path-IDs should make it impossible
that unconnected or unparticipating nodes can interfer with valid
communication.

all in all i'd like this to be "my" im2000, with issues like MIME or
not MIME to be left to implementors.  some day standards will evolve
that facilitate this im2000 better than others, but whether terms
like SMTP, IMAP, MIME etc. will be part of valid im2000 messages
isn't important.

> 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:
>
> [details stripped]
>
> If there are any additional end-point user expectations that this
> does not handle, please point it out.

finally "end-point user expectations" show up!  :)  what do you
think, will my connected nodes be able to fulfill these
expectations?

  clemens

-----BEGIN PGP SIGNATURE-----

iD8DBQE+hU5wpdlrZyFBkK8RAot2AJ9Ys8VeCPcVXQ7e0dFuLWoAIUaa+gCeKzfa
vUi3BB0g/BifSP+YCRXMa4Y=
=faJG
-----END PGP SIGNATURE-----