Subject: [Simple] SIMPLE system architecture - outline

From: "Avshalom Houri" <[email-masked]>
Date: Wed, 1 Jan 2003 16:59:02 +0200

Few weeks ago we have asked for issues to be included in an outline
of a SIMPLE system architecture. We still did not get any
comments from the list :-(. Following is an initial version of the
outline. Please comment.

Thanks a lot to Jonathan Rosenberg for his help.

Thanks
        Tony Hansen
        Avshalom Houri

Server Centric Architecture View
---------------------------------

1. Services provided by the Architecture
 
2. Components and Layouts
        (Each type of layout will relate also to firewalls
         and edge systems)
2.1 Enterprise (Single Domains of Trust)
2.2 Federated Networks
2.3 Public Systems Interconnecting

User Centric Scenarios and Message Flows
-----------------------------------------

3 Locating the Server
 
4 Logging-In
4.1 Authentication
4.2 Identification of Client Capabilities
 
5 Presence Lists
5.1 Management

6. Subscriptions
6.1 Subscribing to Presence List
6.2 Subscribing to Watchers List
6.3 Authorization
6.3.1 Reactive
6.3.2 Asynchronous
 
7. Presence Statuses
7.1 Status Values
7.2 Invisible (Lurking) Mode
7.3 Enhanced Status Codes
7.4 Permissions
7.5 Setting
7.6 Propagation

8. Instant Messaging
8.1 Page Mode IMs
8.2 IM Sessions
8.3 Permissions
8.4 Action Cues(Is-Typing)
8.5 Message History
8.6 Offline Messages
8.6.1 Queued Offline Messages
        (Messages that are delivered to the user when s/he logs in)
8.6.2 Other Offline
        (Delivery via email SMS etc.)
8.7 Emoticons (smily etc.)
8.8 Message Backgrounds (E.g. Yahoo's IMVironments)

9 IM Conferences
9.1 Instant Conferences
9.2 Scheduled Conferences
9.3 Switching between IM Page Mode, IM Sessions and IM Conferences
9.4 Permissions
 
10 Additional Services
10.1 File sharing
10.2 Voice
10.3 Video
10.4 General Application Invocation
10.5 Profiles
        (Searching for other users, Sending profiles to other users etc.)

Server Centric Scenarios and Message Flows
------------------------------------------

Note: The full list should fall out of the user-centric features, when 
applying them inter-domain.

11 Locating other servers
12 Authentication between servers
13 Trust Between Servers from Different Domains
14 Replication of Data
15 Use of Directories
16 Logging Capabilities (e.g. Message History)
17 Offline Messages

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Thu, 02 Jan 2003 17:01:04 -0600

The outline below looks (with a few nits) looks good from a provider 
oriented perspective; that is, one where much of the service is provided 
by, and controlled by, some service provider.

I would also like to see a description of a more client (or end to end) 
focused architecture, where provider-hosted servers play very little 
role beyond helping clients discover each other.

Some more comments inline:

Avshalom Houri wrote:
[...]

> 2.3 Public Systems Interconnecting

The 2.x terminology above seems to favor controlled interconnection 
between provider domains, much like you see on telecom networks. We also 
need to discuss open, uncontrolled communication between domains like 
you often see over the internet with technologies such as email.

> User Centric Scenarios and Message Flows

I am not sure what is meant by "logging in" in a SIMPLE based 
presence/IM service. Are we simply talking about authentication of an 
initial SIP (or other protocol) interaction?

[...]
> 6.2 Subscribing to Watchers List

Need an entry for subscribing to a presentity.

> 7.3 Enhanced Status Codes

May need an entry for composition of presence status from multiple sources.

> 8.3 Permissions

Need a discussion of IM privacy and integrity protection.

> 8.8 Message Backgrounds (E.g. Yahoo's IMVironments)

Much of 8.7 and 8.8 involve IM sender attempts to control the user 
experience of the receiver. We might need some discussion on what 
controls the receiver can place on this as well. For example, if we give 
you a mechanism to send me animated emoticons, we should give me a 
mechanism to make sure I never receive one of the vile things;-)

This might be part of permissions and capabilities as mentioned in 
previous places.

[...]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Jan 2003 00:00:45 -0500

inline.

> you often see over the internet with technologies such as email.

I agree completely. However, it was my assumption that this was under 
the scope of "federated networks" since, in fact, its the same problem 
sans the security. Perhaps worth splitting off though.

> initial SIP (or other protocol) interaction?

I thought this meant REGISTER, which is our closest analogy to logging in.

> May need an entry for composition of presence status from multiple sources.

A good point. In fact, multiple clients impact in multiple places. For 
example, in delivery of an IM (forking). Might be worth considering it 
throughout the doc.

> mechanism to make sure I never receive one of the vile things;-)

IMHO, emoticons as they are done today are horrible and would be an 
unending source of interoperability problems. I much better way to do it 
is to send an IM with a markup, perhaps HTML, that contains inline 
images to the desired emoticons. This way, there is no ambiguity in the 
intent of the sender. It also gets you what you want - a receiver can 
always choose not to download the inline images.

As an example of the problem, Dean Willis and I were IM'ming on yahoo. 
He IM'd me his sip URI:

sip:[email-masked]

now, it turns out that :d is a big grinned smiley face emoticon on 
yahoo. Thus, Dean's sip URL came through with a happy face in the 
middle. Kind of appropriate but not what he meant.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com