Re: Should SIMPLE be rechartered, replaced, closed, or what?

2012/10/18 Ben Campbell <[email protected]>:
> I'm not convinced by the "just implement one protocol" argument. I'm hard pressed to imagine a useful client that only implements SIP, and I'd be surprised if a mature client with high market penetration doesn't eventually need to implement HTTP _somewhere_ for _something_.

Implementing also HTTP means, at least, two TCP connections (even more
since HTTP uses a new TCP connection for every request/response unless
pipeline is used, that AFAIK is not widely used in simple HTTP
clients...).

But I don't focus on that. I focus on the fact that a client must
implement SIP and HTTP and use "same credentials" on both, and the
service provider must run SIP and HTTP infraestructure, with probably
different TLS certificates, and must make both SIP and HTTP servers to
authenticate to the same backend, which is not always possible with
existing software.



>> - As Adrian pointed out, a SIMPLE client needs to mantain ~18 SIP/HTTP
>> "dialogs" (subscriptions to XCAP-diff, winfo, presence...).
>> Subscriptions means "dialogs" and dialogs are really a bad idea in the
>> new Internet ecosystem: the mobile devices (those that dynamically
>> change their IP or gets unreachable for a while). Mobiles apps want to
>> use the PUSH mechanism, something unfeasible with SIMPLE
>> subscriptions. IMHO a stateless mechanism based on PULL and PUSH would
>> be the key. Nothing to reuse from SIMPLE here.
>
> Are these issues specific to SIMPLE, or an artifact of SIMPLE using SIP in the first place?

I don't know what to reply here. SIMPLE is basically SIP :)
My concern is that SIMPLE depends too much on SIP subscriptions, which
are expensive, error prune and bad for mobile apps.


> Are 18 dialogs that much worse than 1, if it forces the client to nail up a TCP connection and/or outbound proxy binding? (i.e. is this a protocol problem, or a network architecture problem?)

It's not about resource usages for mantaining 18 dialogs, but about
the complexity it involves in the application logic.


> What mechanism do you have in mind for "the PUSH mechanism"?

Exactly this:

  http://sip-space.net/flows/mutual-presence-authorization/

It's a proposal I started some time ago. It just uses SIP (no HTTP)
and defines new methods:

- STORE: used to manage content in the server (i.e. buddylist).

- PULL: used by clients to ask a buddy for some information (i.e.
presence status).

- PUSH: used by presence agents to notify watchers that a buddy has
changed something so the watcher may want to perform a PULL request
again.

Both PULL and PUSH are a stateless mechanism (no subscription/dialog
here) and fit very well with the Push mechanism in mobile apps (the
server notifies something to the app via a single TCP connection, with
minimal information, and the app decides whether to wake-up, warn the
user, or automaticall retrieve the desired information).



>> - XCAP is like Xpath 1.0 but is not compatible with it since it adds a
>> "cool" feature to save 10-20 bytes in a HTTP request (the "default
>> document namespace") so developers cannot use the widely extended
>> libxml library (which includes Xpath 1.0). Not good.
>>
>> - XML diff is too complex for expecting that anyone can properly use
>> it. If I want to code a JavaScript web application for watching SIP
>> presence, how will I implement XML diff in JavaScript? It's a no
>> sense, and taking a look to other protocols (i.e. XMPP) they do NOT
>> need it (and still they are really scalable in the whole Internet).
>>
>
> I'm open to the argument that XCAP is too complex. But that's only one piece of the bigger puzzle.

Yes, I agree.



>> So IMHO, after years of playing with SIMPLE, it's clear for me that
>> there is no way for SIMPLE to become developer-friendly and thus, a
>> new SIP presence proposal from scratch makes lot of sense IMHO.
>
> I'm extremely doubtful we could get traction with a completely new SIP based PIM. I also strongly doubt the IESG would approve work on such a thing. If SIMPLE is completely unfit for purpose, then we'd be better focusing on using XMPP with SIP.

I understand what you say. But I would also like to insist that XMPP
is not the panacea. It was initially designed 12 years ago (?),
remember: Jabber. The mechanism for basic presence distribution is
very simple and easy to implement, but for more complex features XMPP
also implement subscription/notification, so both mechanism live
togheter. Of course buddylist management is much more easier in XMPP,
but still I think that in 2012 we can do something much better by
learning from XMPP and SIMPLE.


Regards.



-- 
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Simple mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/simple