Subject: [Simple] updated SIP-XMPP gatewaying specs

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Oct 2012 09:09:58 -0600

Last night I refreshed the following specifications covering protocol
mappings between SIP and XMPP for addresses and errors, presence,
single messages, one-to-one chat sessions, and multi-user chat...

https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core
https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-presence
https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-im
https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-chat
https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-groupchat

These specs have been around in one form or another for years. More
recently, a number of people have asked me whether they can be
finished off and published as RFCs. I think they can, although the
specs farther down the list are a bit less mature and need to be
aligned with work on MSRP and SIMPLE-based chat. I've received
feedback offlist in the last few months about several of these
(especially the groupchat spec), which I have not yet incorporated,
but I will endeavor to do that soon.

Thanks for listening,

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Oct 2012 12:44:56 -0400

AFAIK the SIMPLE WG currently exists as a placeholder.
All chartered work was done long ago. There has continued to be a low 
level of q/a discussion on the list.

But recently there has been more active interest in new work.

If we want to do more work, we should charter it, either by rechartering 
SIMPLE, by doing the work in XMPP, starting a new wg, or *something*.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 16 Oct 2012 12:34:53 -0500

> level of q/a discussion on the list.
[MB] I don't know what you mean by placeholder.  There is one WG document
that fairly recently went to IESG review.  It's not unusual to keep WGs
open until all the WG drafts are complete - e.g., XCON only closed after
the last RFCs were published. [/MB]

> SIMPLE, by doing the work in XMPP, starting a new wg, or *something*.
[MB]  Exactly.  And, I think that's the intent of Peter Saint-Andre's
posting on the updated SIP-XMPP docs. Note, that we discussed this topic 3
years ago in a DISPATCH adhoc session and there was not a lot of momentum
(I personally think that's because it was scheduled on Friday afternoon).
 A separate list for the topic was created (but not announced on DISPATCH)
and then the work went to XMPP WG to be discussed and the consensus was
that there was not enough support for the work.  However, that was
scheduled opposite the exciting SPLICES WG so not all the interested
parties were there.   The best thing to do may be to discuss this work
again in DISPATCH in an official WG session (per our process) and then
decide where it fits. [/MB]

>
>         Thanks,
>         Paul
> ______________________________**_________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/simple<https://www.ietf.org/mailman/listinfo/simple>
>

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 16 Oct 2012 19:49:40 +0200

This is great work, Peter!

Adrian

On Oct 16, 2012, at 5:09 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> 
> iEYEARECAAYFAlB9eMYACgkQNL8k5A2w/vwkbwCePKpOCnpzEEuqo51Vbii1UV/W
> SLMAn35Y/YFR9djqcQ+PCOO385B0EXjT
> =mdvB
> -----END PGP SIGNATURE-----
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Oct 2012 11:55:00 -0600

Thanks, Adrian. I still need to incorporate the feedback you sent me a
few months ago. Will do soon.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Oct 2012 14:01:57 -0400

Mary,

Peter Saint-Andre's reactivated drafts are part of what I was talking 
about. There has been other discussion that may or may not be covered by 
those drafts.

Your suggestion to discuss in DISPATCH and decide if and where we want 
to do that work makes sense, and is what DISPATCH is for. Presumably we 
can do that in Atlanta.

	Thanks,
	Paul

On 10/16/12 1:34 PM, Mary Barnes wrote:
>
>
> On Tue, Oct 16, 2012 at 11:44 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     All chartered work was done long ago. There has continued to be a
>     low level of q/a discussion on the list.
>
> [MB] I don't know what you mean by placeholder.  There is one WG
> document that fairly recently went to IESG review.  It's not unusual to
> keep WGs open until all the WG drafts are complete - e.g., XCON only
> closed after the last RFCs were published. [/MB]
>
>
>     If we want to do more work, we should charter it, either by
>     rechartering SIMPLE, by doing the work in XMPP, starting a new wg,
>     or *something*.
>
> posting on the updated SIP-XMPP docs. Note, that we discussed this topic
> 3 years ago in a DISPATCH adhoc session and there was not a lot of
> momentum (I personally think that's because it was scheduled on Friday
> afternoon).  A separate list for the topic was created (but not
> announced on DISPATCH) and then the work went to XMPP WG to be discussed
> and the consensus was that there was not enough support for the work.
>   However, that was scheduled opposite the exciting SPLICES WG so not
> all the interested parties were there.   The best thing to do may be to
> discuss this work again in DISPATCH in an official WG session (per our
> process) and then decide where it fits. [/MB]
>
>
>              Thanks,
>              Paul
>     _________________________________________________
>     Simple mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/simple
>     <https://www.ietf.org/mailman/listinfo/simple>
>
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Oct 2012 13:12:57 -0500

(as chair)

This is an interesting discussion, and please feel free to continue it on the SIMPLE list, at least for now. 

But if work comes of it, that will most likely need to go through DISPATCH. Given the general lack of energy we've seen for SIMPLE lately, I think it's unlikely that we would recharter it in it's current form. Or at least, any recharter effort will be met with the same sort of scrutiny a DISPATCH or BoF proposal.

Thanks!

Ben.

On Oct 16, 2012, at 11:44 AM, Paul Kyzivat <[email-masked]> wrote:

> All chartered work was done long ago. There has continued to be a low level of q/a discussion on the list.
> 
> If we want to do more work, we should charter it, either by rechartering SIMPLE, by doing the work in XMPP, starting a new wg, or *something*.
> 
> 	Thanks,
> 	Paul
ly

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Oct 2012 13:15:38 -0500

On Oct 16, 2012, at 12:34 PM, Mary Barnes <[email-masked]> wrote:

> 
> 
> On Tue, Oct 16, 2012 at 11:44 AM, Paul Kyzivat <[email-masked]> wrote:
> [MB] I don't know what you mean by placeholder.  There is one WG document that fairly recently went to IESG review.  It's not unusual to keep WGs open until all the WG drafts are complete - e.g., XCON only closed after the last RFCs were published. [/MB]
> 
> [MB]  Exactly.  And, I think that's the intent of Peter Saint-Andre's posting on the updated SIP-XMPP docs. Note, that we discussed this topic 3 years ago in a DISPATCH adhoc session and there was not a lot of momentum (I personally think that's because it was scheduled on Friday afternoon).  A separate list for the topic was created (but not announced on DISPATCH) and then the work went to XMPP WG to be discussed and the consensus was that there was not enough support for the work.  However, that was scheduled opposite the exciting SPLICES WG so not all the interested parties were there.   The best thing to do may be to discuss this work again in DISPATCH in an official WG session (per our process) and then decide where it fits. [/MB]

I concur, with the caveat that this shouldn't preclude _list_ discussion prior to a DISPATCH f2f discussion. (I say that assuming such a f2f discussion, if it happens, would likely be next March)

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Oct 2012 13:23:17 -0500

On Oct 16, 2012, at 1:01 PM, Paul Kyzivat <[email-masked]> wrote:

> Mary,
> 
> Peter Saint-Andre's reactivated drafts are part of what I was talking about. There has been other discussion that may or may not be covered by those drafts.
> 
> Your suggestion to discuss in DISPATCH and decide if and where we want to do that work makes sense, and is what DISPATCH is for. Presumably we can do that in Atlanta.

I believe we're past the deadline for "official" DISPATCH agenda time for Atlanta. Mary, since you've already commented, do you have thoughts on that?

---

From: Mary Barnes <[email-masked]>
Date: Tue, 16 Oct 2012 13:32:23 -0500

On Tue, Oct 16, 2012 at 1:23 PM, Ben Campbell <[email-masked]> wrote:

> to do that work makes sense, and is what DISPATCH is for. Presumably we can
> do that in Atlanta.
>
> I believe we're past the deadline for "official" DISPATCH agenda time for
> Atlanta. Mary, since you've already commented, do you have thoughts on that?
>
[MB] Yes - we are past the "official" DISPATCH dates.  Although, we have a
light agenda since only one topic was requested before the deadline.  We
may have some extra time and pending approval from the ADs, we could have
an unofficial discussion after the "official" agenda to kick this off and
pursue it formally in DISPATCH in March (with the discussion focusing on a
proposed charter).  I'll ping the ADs and see what they think. [/MB]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Oct 2012 14:01:15 -0500

On Oct 16, 2012, at 1:32 PM, Mary Barnes <[email-masked]> wrote:

> [MB] Yes - we are past the "official" DISPATCH dates.  Although, we have a light agenda since only one topic was requested before the deadline.  We may have some extra time and pending approval from the ADs, we could have an unofficial discussion after the "official" agenda to kick this off and pursue it formally in DISPATCH in March (with the discussion focusing on a proposed charter).  I'll ping the ADs and see what they think. [/MB] 
>> 

I also assume any such discussion would be dependent on someone stepping up to lead it, right? It seems like there are really at least two things under discussion on the list: SIMPLE/XMPP inter working, and whether work is needed on SIMPLE itself in order to facilitate interoperable implementations.

Thanks,

Ben.

---

From: Mary Barnes <[email-masked]>
Date: Tue, 16 Oct 2012 16:12:10 -0500

On Tue, Oct 16, 2012 at 2:01 PM, Ben Campbell <[email-masked]> wrote:

> I also assume any such discussion would be dependent on someone stepping
> up to lead it, right? It seems like there are really at least two things
> under discussion on the list: SIMPLE/XMPP inter working, and whether work
> is needed on SIMPLE itself in order to facilitate interoperable
> implementations.
>
[MB2] Yes, we would need people willing to lead the work as well as folks
that are willing to contribute to and review documents.  Yes, there are two
separate things.  My comments were on the former.  I think the latter is a
different beast and needs more consideration before thinking that we have
something to do or whether we should do something. [/MB2]

---

From: Raphael Bossek <[email-masked]>
Date: Wed, 17 Oct 2012 09:14:30 +0200

Hallo Philipp,

kennst du den Peter Saint-Andre? Sind "seine" Ideen obsolate?

Gruß,

i.A. Raphael Bossek
Product Manager

ESTOS GmbH
Petersbrunner Str. 3a
82319 Starnberg, Germany

Phone: +49815136856153
Fax: +49 (8151) 36856-853
Mobile: +49 (151) 59177535

Email: [email-masked]
Web: http://www.estos.de

// Jetzt anmelden zu den kostenfreien Online-Workshops ab September 2012.
Webinare zu den Themen: Mobilität, DATEV pro, Federation, u. a.

http://www.estos.de/partner/webinare.html

---
ESTOS GmbH
Registered office: Starnberg, Germany
Commercial registry Munich, HRB 133 670
Managing Directors: Dipl.-Phys. Stephan Eckbauer, Dipl.-Ing. Stefan Hobratschk, Ing. Christoph Lösch, Florian Bock
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Peter Saint-Andre
Gesendet: Dienstag, 16. Oktober 2012 17:10
An: [email-masked]
Betreff: [Simple] updated SIP-XMPP gatewaying specs

Last night I refreshed the following specifications covering protocol mappings between SIP and XMPP for addresses and errors, presence, single messages, one-to-one chat sessions, and multi-user chat...

These specs have been around in one form or another for years. More recently, a number of people have asked me whether they can be finished off and published as RFCs. I think they can, although the specs farther down the list are a bit less mature and need to be aligned with work on MSRP and SIMPLE-based chat. I've received feedback offlist in the last few months about several of these (especially the groupchat spec), which I have not yet incorporated, but I will endeavor to do that soon.

Thanks for listening,

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 13:15:20 +0200

2012/10/16 Ben Campbell <[email-masked]>:
> It seems like there are really at least two things under discussion on the
> list: SIMPLE/XMPP inter working, and whether work is needed on SIMPLE itself
> in order to facilitate interoperable implementations.

Hi Ben, some others as me propose a third vision:

Trying to revive SIMPLE for open environments (i.e. Internet) is a
no-go given the complexity of the existing specs. IMHO technical
details about this realitity have been already given during the last
mail threads, including the number of lines of high level programming
code for building all the SIMPLE specs (more than 15000, and the
result is something non interoperable with any other client or server
implementation).

A new effort 100% from scratch makes more sense for me (just my
opinion). Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 18 Oct 2012 13:51:12 +0200

[email-masked] wrote on 10/18/2012 01:15:20 PM:

> From: Iñaki Baz Castillo <[email-masked]>
> To: Ben Campbell <[email-masked]>, 
> Cc: Mary Barnes <[email-masked]>, Simple WG 
> <[email-masked]>, Paul Kyzivat <[email-masked]>
> Date: 10/18/2012 01:15 PM
> Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or 
what?
> Sent by: [email-masked]
> 

A different effort may be considered which is what will make
XMPP acceptable as an extension to SIP based systems.

This means not modifying SIMPLE but using XMPP as the
presence/IM protocol for SIP.

Usage of SIP AOR was mentioned before as an example.

thanks
avshalom

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 14:24:51 +0200

> Usage of SIP AOR was mentioned before as an example.

XMPP is not the panacea. It uses two different mechanisms for presence:

- Basic presence distribution.
- Subscription/notification for advanced presence (avatar and so).

Interoperability becomes hard for XMPP clients when implementing
something else than basic presence exchange. I don't understand why
XMPP should be the only way to go (for SIP).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 18 Oct 2012 15:29:10 +0200

I do not see the SIMPLE work being done again or fixed to the level that 
it will interoperate.
There is too much legacy and complexity including standardisation by other 
organizations that will
have to be considered.

On the other hand, having a way to add presence and IM to SIP while using 
an existing protocol that is proven to interoperate may be the way 
forward.
It may be that the MSRP work is solid enough so IM is covered but it does 
not seem that it is the state for presence.

Thanks
--Avshalom

From:   Iñaki Baz Castillo <[email-masked]>
To:     Avshalom Houri/Haifa/IBM@IBMIL, 
Cc:     Ben Campbell <[email-masked]>, Mary Barnes 
<[email-masked]>, Paul Kyzivat <[email-masked]>, Simple 
WG <[email-masked]>
Date:   10/18/2012 02:25 PM
Subject:        Re: [Simple] Should SIMPLE be rechartered, replaced, 
closed, or what?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 18 Oct 2012 15:39:04 +0200

> Usage of SIP AOR was mentioned before as an example. 

That was the project that Mary referred to earlier, that never took off and an implementation issue.

The question here, in the SIMPLE wg, is not to select another protocol, it is to judge whether

* SIMPLE is broken, which we seams to reach a consensus on
* SIMPLE can be fixed, which we are still discussion

If we conclude that we have no interoperability, the SIMPLE wg hasn't lived up to the goal of the charter.

The SIMPLE-XMPP gatewaying and SIP-XMPP ("calls") gateway is a very important discussion, but 
kind of assumes that there are working SIMPLE implementations and some basic level of interoperability
so you can write a gateway to SIMPLE, not having to write a new gateway for every SIMPLE-like
implementation. For SIMPLE-XMPP to work, we need a SIMPLE world that interoperates.

/O

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Oct 2012 09:08:53 -0500

> result is something non interoperable with any other client or server

How is that different from my second item (above)?

> A new effort 100% from scratch makes more sense for me (just my

Can you clarify what you mean by "from scratch"? Do you suggest we should start SIMPLE over from a blank slate?

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Oct 2012 09:14:28 -0500

> If we conclude that we have no interoperability, the SIMPLE wg hasn't lived up to the goal of the charter.

Before you can draw that conclusion, you have to define what level of interoperability is intended. For example:

1) Can one SIMPLE implementation exchange presence and IMs with another implementation?

2) Can you mix and match components of one "deployment cluster" with another? (For example, the ongoing discussion about being able to get your address book from any client.)

1 was a clear goal of SIMPLE. I'm not sure you would have gotten consensus on 2 as a requirement when that charter was written.

---

From: "Roy, Radhika R CIV (US)" <[email-masked]>
Date: Thu, 18 Oct 2012 14:04:29 +0000

Avshalom:

Yes, this may be another approach to use XMMP IM/Chat as another data
application as a part of SIP call (as SIMPLE IM/Chat does).

Then the question comes is this: Whether will XMPP have all the hooks for
SIP as SIMPLE does? If not, is it worthwhile to do so?

One of the key weaknesses of XMPP is the integration of XMPP with audio
and/or video. SIP is well established for integration of data applications
like IM/Chat (e.g. SIMPLE) as another applications with audio and/or video,
but XMPP is not.

At the end of the day, it appears that XMPP and SIMPLE/SIP are two competing
protocols. So, it may be such that XMPP will be used as the stand-alone data
applications for IM/Chat while SIMPLE/SIP is the one that will be used for
integration with audio/video using SIP.

So, there will be two niece markets evolving side-by-side. Of course,
SIMPLE/SIP as a stand-alone IM/Chat application will also be competing with
XMPP, but XMPP has much more market share in this segment.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Avshalom Houri
Sent: Thursday, October 18, 2012 7:51 AM
To: Iñaki Baz Castillo
Cc: Mary Barnes; Simple WG; Paul Kyzivat
Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or
what?

A different effort may be considered which is what will make XMPP acceptable
as an extension to SIP based systems. 

This means not modifying SIMPLE but using XMPP as the presence/IM protocol
for SIP. 

thanks
avshalom

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 18 Oct 2012 16:40:52 +0200

> 1) Can one SIMPLE implementation exchange presence and IMs with another implementation?

This works.

> 2) Can you mix and match components of one "deployment cluster" with another? (For example, the ongoing discussion about being able to get your address book from any client.)

This does not.

Adrian

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 18 Oct 2012 16:46:41 +0200

> 1 was a clear goal of SIMPLE. I'm not sure you would have gotten consensus on 2 as a requirement when that charter was written.

Thanks for the clarification, Ben. I was parsing the text of the charter myself, as I wasn't involved in the background work back then... 

For me, I can't even get proper presence notifications across the set of implementations I have access to. That's why I want as many as possible to come to SIPit so we can test and see where we are. After my initial mail there seems to be consensus on issues with PIDF parsing for presence and then on a bit more, but not too advanced level, a lack of interoperability in regards to server-based buddy-lists. 

"deployment cluster" was nicely put :-) Isolated island would be a politically incorrect, but correct name...

/O

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Oct 2012 09:25:55 -0600

On 10/18/12 8:04 AM, Roy, Radhika R CIV (US) wrote:
> Avshalom:
> 
> Yes, this may be another approach to use XMMP IM/Chat as another
> data application as a part of SIP call (as SIMPLE IM/Chat does).

Robert Sparks proposed just such an approach back in 2002:

http://tools.ietf.org/id/draft-sparks-simple-jabber-sessions-00.txt

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 18:04:53 +0200

> How is that different from my second item (above)?

Well, that depends on the ammount of existing specs that would be kept
when designing a new SIP presence proposal. See below please.

> Can you clarify what you mean by "from scratch"? Do you suggest we should start SIMPLE over from a blank slate?

Basically yes. I know SIMPLE specs very well and honestly I don't like
them at all. Just for mentioning some points:

- The Presence Data Model is too complex. In the world we have users
and the user has devices. I don't understand what a "service" is.
Theorically two devices managed by same AoR should not publish a
different <person> since <person> must be unique, how to do that? And
in case of various devices, how can the watcher match each <tuple> to
each device? it would make sense to use GRUU here (XMPP uses
"resources"), but we have nothing about that.

- If I subscribe using RLS I will get a very big first NOTIFY
containing all the presence bodies of all my watched contacts, so SIP
TCP is required. If so, why must I implement HTTP/XCAP for storing my
"buddy list"? Which other IM/presence protocol implements both the
protocol itself and HTTP for related stuff? This involves two servers,
two TLS certificates, two authentication points, double lines of
code... We can transfer a ISO image using MSRP but we need HTTP for
storing a simple buddy list and permissions policy?

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

- Managing a buddy list or presence authorizations should be simple
and easy. Instead we have a generic protocol (XCAP) for performing
partial modifications in remote XML documents, and when a modification
takes place the presence server and all the watchers (same AoR) must
re-evaluate all the XML documents along their relationship with all
the other XML documents, otherwise it's near imposible to detect what
such an incremental XML change involves, and this means high CPU usage
in both servers and clients.

- Blocking/allowing presence authorization for a buddy should be an
atomic/boolean operation (like in XMPP). But in SIMPLE/XCAP we have
two options:

  1) Upload the new full XML documents with all the buddies (so let
the server and others to full re-evaluate it again).
  2) Two operations: delete a buddy from some "list", and then include
it in some other "list" (partial DELETE/PUT), so double notification.

- In XMPP blocking/allowing/subscribing/desubscribing to a buddy is an
atomic operation: the user sends the full XML definition of the buddy
to the server, with all the buddy attributes. The server notifies the
buddy new properties to other resources of the same account. In SIMPLE
anyone can do whatever XCAP allows (which is really too much). Does
XMPP need so powerful control over the "XML files"? Sure not.

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

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.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Oct 2012 11:29:08 -0500

> "resources"), but we have nothing about that.

The data model could be simplified, or perhaps we could do a BCP clarifying things and recommending particular usages.

> storing a simple buddy list and permissions policy?

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

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

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

> need it (and still they are really scalable in the whole Internet).

'm open to the argument that XCAP is too complex. But that's only one piece of the bigger puzzle.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 18:46:56 +0200

> 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 penet…

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.

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

> I'm open to the argument that XCAP is too complex. But that's only one piece of the bigger puzzle.

Yes, I agree.

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

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-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 18 Oct 2012 20:23:25 +0200

As I haven't even tried to implement a full SIMPLE client I can't argue with developers, just learn from what you write. The more the better. 

I don't think we should throw away everything going down to the core SIP protocol and trying to replace SUBSCRIBE/NOTIFY and PUBLISH. There are ways to filter notifications and significant work. 

So far, I've seen a few issues brought up:

* PIDF status *may* bee too complex, especially in combination with XCAP and the operations of XCAP (non-atomic, external references with full urls etc)
* Buddy lists are too complex and unmanageable
* The IETF documents leave gaps in Buddy List management

Apart from that, there are many mails about the total complexity with 18 subscriptions, multiple XCAP formats intermingled with multiple sources of application usages from both organizations and developers. Seems like most of us that have mailed so far agree that this is too complex.

To take a naive approach to this, can we

* Dramatically reduce the number of subscriptions by implementing
  - one for synchronization of informaiton between one user's clients - presence-ua-config
  - one for presence updates from my buddy list - presence-updates

* Reduce the number of documents, possibly
  - one simple-buddy-list 
  - one auth-rules document

* FInd a way to separate device states from user states and rules on how to aggregate this
   - "This phone is busy" vs "OEJ's calendar says he is on a wine-tasting in France, so he's obviously busy"

The icon could be part of my own entry in my own buddy list, visible for all buddies

The notifications from presence-ua-config would include changes in buddy lists, auth requests and much more. An aggregation - and simplification - of a lot of the stuff that the years of work done in SIMPLE, XMPP and OMA. If you shut your eyes for the pile of XML schemas and XCAP auids, there is a lot of ideas and good functionality for applications hidden in there. I see no point in throwing it away, just trying to create something simple that is a concentrated, stream-lined and focused application. And we should not forget that it has to be extensible in some way too, so we don't end up with a new subscription, new XML schema, new URN and new AUID for every extension. Then we're going to end up quickly in the very same situation we are in now.

Let's try to focus on attacking the solution from this end and see if we can agree. I think we're done complaining over the existing solution for a while. Note that I'm not saying that we have to use XML or XCAP. Let's just talk "documents" and "subscriptions" and see where we end up.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 21:13:25 +0200

> Let's try to focus on attacking the solution from this end and see if we can agree. I think we're done complaining over the existing solution for a while. Note that I'm not saying that we have to u…

I don't agree that we should talk "documents". Why "documents"? In
XMPP there are no "documents", but a buddylist, which yes, it's
represented in XML format but the user cannot modify it in a custom
way. For example, I don't remember now the exact syntax of the XMPP
buddylist, but it's something like this (I DO not that is not like
this):

---------------------
<buddies>

  <buddy id="[email-masked]">
    <subscribe>1</subscribe>
    <allowed>1</allowed>
  </buddy>

  <buddy id="[email-masked]">
    <subscribe>1</subscribe>
    <allowed>0</allowed>
  </buddy>

</buddies>
------------------------------

Is that a XML document? humm, yes, but when the user wants to block
presence for a buddy it cannot tell the server "set the allowed field
to 0 where buddy id == "[email-masked]". Instead the user uploads
the FULL definition of the buddy to the server, now with
<allowed>0</allowed>.

So from this point of view this seems more a RPC protocol, something
like an "API", rather than "custom modification of remote XML
documents" as XCAP is designed for. Being constrained to specific
actions makes implementations much easier.

So I'm not in favour of talking about "documents". Instead I prefer
calling them "buddylist" and them provide an "API" for performing
actions over the buddylist (add, remove, block, allow, subscribe-to,
unsubscribe-to...), something "idiomatic". I don't want that my SIP
device becomes a Vi text editor. In this way, if me (a SIP device)
tells the server "block this user" the server easily knows WHAT to do
(block such a user and send him some spoofed "offline" presence
status). In SIMPLE/XCAP instead, when the user *modifies* a XCAP
document the server must recompute the whole document (by also
retrieving the "linked" external documents) to understand what the
desired operation of the user is.

"API" is the winning keyword in today's Internet services, but SIMPLE
provides no API at all, but just remote operation over XML documents,
in any custom way.

So forget documents, and let's design an *API*. Is there something
more extensible than an API (request method and parameters)?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 18 Oct 2012 21:42:49 +0200

16 okt 2012 kl. 23:12 skrev Mary Barnes <[email-masked]>:

> [MB2] Yes, we would need people willing to lead the work as well as folks that are willing to contribute to and review documents.  Yes, there are two separate things.  My comments were on the former.  I think the latter is a different beast and needs more consideration before thinking that we have something to do or whether we should do something. [/MB2]

The SIMPLE-XMPP stuff are already in documents and there are contributions. I'm sure Peter has control of the process for that.

The SIMPLE-SIMPLE discussion is way too early to take anywhere in the IETF process. Let us use the SIMPLE mailing list for brainstorming and we'll see if we can agree on issues and possible solutions that can be discussed and possibly taken down in document form. At that point, it wlll hopefully be worth the energy and your backup to get a process started, in this wg or somewhere else.

IF there's time over for an unofficial discussion in Atlanta, it would be very interesting to hear the feedback from the dispatch wg. I don't think I can attend, so I guess I'll be participating over XMPP ironically.

THanks for your interest in this issue!

/O

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 19 Oct 2012 10:03:33 +0200

> presence/IM protocol for SIP. 

What is wrong with IM? MSRP based IM works fine, I thought we were focusing on presence here.

> Usage of SIP AOR was mentioned before as an example. 

Now we also have new tools, like GRUU, which maps one-to-one with a Full JID, so exploring what XMPP did right sounds like a good idea.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 19 Oct 2012 10:32:50 +0200

> I don't think we should throw away everything going down to the core SIP protocol and trying to replace SUBSCRIBE/NOTIFY and PUBLISH. There are ways to filter notifications and significant work. 

I also lean towards not replacing those, but I may not be seeing the trees because of the forest (I'm right now working on fixing a RLS implementation).

> * PIDF status *may* bee too complex, especially in combination with XCAP and the operations of XCAP (non-atomic, external references with full urls etc)

Those are 2 different issues:

1- Ambiguous data in a PIDF: both per-person and per-device presence can be expressed, which ends un in a weird mixture where only heuristics can be used to try to draw a conclusion.
2- Use of different documents: this is what kills atomicity.

> * Buddy lists are too complex and unmanageable

They don't currently exist in SIMPLE. OMA added the oma_buddylist on top of resource-lists, but IMHO the foundation is not right, we need something new.

>  - one auth-rules document

Hum, yes and no :-) The actual buddylist could contain the policy for each buddy. There would be the need for a different entity, which is not a buddy, but holds policy information, for example when you would block someone but don't want to see him in your buddylist.

>   - "This phone is busy" vs "OEJ's calendar says he is on a wine-tasting in France, so he's obviously busy"

Yes, we need this.

> The icon could be part of my own entry in my own buddy list, visible for all buddies

This doesn't scale very well. I'd rather use a different means of storage for the icon and then have a mechanism to fetch it. Mobile devices may not want to download all icons at all times, for example. Also, documents can get really big if you start embedding icons, been there :-)

> The notifications from presence-ua-config would include changes in buddy lists, auth requests and much more. An aggregation - and simplification - of a lot of the stuff that the years of work done…

+1. This ua-config could be a base package and extensions could be implemented as sub packages (like presence and presence.winfo). They would surely need to provide a schema for the extension format, but that's ok. I need to think about new AUIDs more, but we should at least provide a working model based on 1 or 2 AUIDs.

> Let's try to focus on attacking the solution from this end and see if we can agree. I think we're done complaining over the existing solution for a while. Note that I'm not saying that we have to u…

+1.

Regards,

--
Saúl Ibarra Corretgé
AG Projects