[JDEV] Questions on the protocol

[Jeremie]

> Some question that has arisen during my work with the protocol.
> They're not very pressing, just my musings and some unclear issues.
> 
> 1. Are we allowed to put subsessions within a session? Eg

Nope... that would and could really complicate things(recursive xml
definition), and I don't see the use, but any client is free to create
multiple seperate sessions to a server at any time if there was a need for
it.

> 2. We should stipulate that the <login><user></user></login> always
>    contains the user's whole address including domain. This would make
>    it possible to create transparent proxies.

Excellent idea!  I can't see any drawbacks with this approach either,
great!

> 3. Current examples enters addresses for other transports as
>    12341424 at ICQ. I'd like to propose the less ambiguous form
>    icq:12312313. This will take care of the fact that someone else may
>    come up with the same scheme as we have. Of course, pedants may use
>    jabber:user at blah.org. Incidentally, we now have a subset uf the URI
>    standard. 
> 
>    This will conflict with current description which allows special
>    characters in the ID. These should then be escaped in accordance
>    with URI standard.

There's a major problem with that approach, and the problem is that the
server would have to "know" where the ICQ transport is.  As it stands now,
the ICQ transport could be foobar.server.com and nobody would know the
difference.  You could layer that on and say icq:12345 at server.com, but why
even have the distinction between different addresses?

Also, we wouldn't have any way of knowing all the possible transports out
there and specifying them, there will likely be third party services that
put up a special closed service on their server, and this should be
transparent to the end user, just blah at service.com.

Pure and absolute transparency is one of the essential goals of Jabber,
there shouldn't be any way of distingushing the type of user from the
address.

> 4. According to various example docs (eg
>    docs.jabber.org/overview.html) the sender's server is responsible
>    for storing messages until recipient is back online. Like this:
> 
>       Message >> Client >> Server >> Offline storage
> 
>    Rather than:
> 
>       Message >> Client >> Server >> Server >> Offline storage
> 
>    Is this how we want it?

The docs are wrong, everything is stored offline on the recipients server,
sorry about the confusion!

> 5. Overview says:
> 
>    Each "user" has multiple "sessions" 
>        Every connection to a Jabber server can be "addressed"
>        uniquely. This allows every user to connect multiple times, or
>        use their account from
>        several locations(home and work), and still be able to
>        send/recieve messages at any one of the locations uniquely. 
> 
>    How is this identification/addressing done? If a user is running
>    two different sessions, which one do we send status & messages to?

Every session is uniquely identified by the combination of the users
address and the nickname they choose for that session, so I might be:
  nick="work" user="jer at jeremie.com"
and
  nick="server shell" user="jer at jeremie.com"
which would be two unique sessions.  That's why you can specify nick="" in
to tags.

If there are multiple sessions and no nick is specified, it will be up to
the module to decide based on user preferences, but it will likely go to
the session with the highest priority.

> 6. Receipts and confirmations. The current protocol examples does not
>    include any mechanisms for receipts or confirmations that an XML
>    fragment has been received. Is this intentional?

Yes, it's intentional.  There is a whole slew of features including and
related to this, receipts, unique ids, server tracking, date/timestamping,
and more.  There are quite a few different ideas I've had along these
lines, and I'm sure others have had some too.  It's been my goal to
produce a working platform that provides the core functionality, and then
we can all start experimenting with different ways of layering on this
"higher" level functionality.

So I'd say these things will and must come, but we need a working platform
to experiment with them first :)  So in a few weeks after 0.7 is making
considerable progress I'll toss out a few ideas again...

Jer