Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and… (new subject)

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 01 Nov 2012 22:08:48 +0200

Murray was the liaison person to the OMA from the IETF side. Murray recently discontinued his participation in the OMA (due to a job change). We discussed the need to appoint a new liaison person in the IAB and came to the conclusion that no new appointment is necessary; the required need to interact with the OMA had decreased over time. 

Does anyone on this list believe that there is a need for cooperation with the OMA?

Ciao
Hannes

Sent from my ASUS Pad

Ben Campbell <[email-masked]> wrote:

>
>On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson" <[email-masked]> wrote:
>
>> What is the current relationship betwen OMA and the IETF? ANy cooperation, like between 3Gpp and the IETF?
>> 
>
>
>There is a liaison, but I don't think it's been very active for a while now. 
>_______________________________________________
>Simple mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/simple

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 1 Nov 2012 22:13:05 +0100

> Does anyone on this list believe that there is a need for cooperation with the OMA?

For me, it is too early to answer. I'm just trying to assemble information about how we ended up where we are with all these organizations working with SIMPLE, not contributing back and leaving the IETF with huge gaps and a set of specs that seems uncomplete and not focused on developers being able to produce running interoperable code. 

I have no insights in the politics at that time, so I have no insight into why OMA produced all these documents without trying to feed them back to the IETF.

My opinion on OMA cooperation is that if we can kick off work in this group to complete and/or correct IETF simple into an interoperable state for buddy lists and Xcap, and we see a need for using OMA documents within the IETF we can revisit your question and produce an answer. 

Any other opinions?

/O

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 2 Nov 2012 00:00:20 +0100

So I guess that IETF has therefore abandoned RFC 5727.

OMA last asked for 6 header fields to be registered. As far as I understand they were told they needed a standards track RFC to do this. Identifying no need for cooperation tells me that IETF is quite happy they have their own version of the SIP specification.

Keith

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: 01 November 2012 20:09
> To: Ben Campbell
> Cc: Olle E. Johansson; Bernard Aboba; DRAGE, Keith (Keith);
> [email-masked]
> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject)
> 
> Murray was the liaison person to the OMA from the IETF side. Murray
> recently discontinued his participation in the OMA (due to a job change).
> We discussed the need to appoint a new liaison person in the IAB and came
> to the conclusion that no new appointment is necessary; the required need
> to interact with the OMA had decreased over time.
> 
> >> What is the current relationship betwen OMA and the IETF? ANy
> cooperation, like between 3Gpp and the IETF?
> >>
> >
> >

---

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Nov 2012 18:09:59 -0500

> So I guess that IETF has therefore abandoned RFC 5727.

I'm trying to figure out how "abandoning 5727" follows from "no liaison manager for OMA". I'm not getting it; can you elaborate?

> OMA last asked for 6 header fields to be registered. As far as I understand they were told they needed a standards track RFC to do this. Identifying no need for cooperation tells me that IETF is qu…

I don't think choosing not to assign a liaison manager implies we expect no cooperation. You don't need an IETF assigned liaison manager to someone bring a draft to the IETF, do you?

---

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Nov 2012 18:12:16 -0500

> I don't think choosing not to assign a liaison manager implies we expect no cooperation. You don't need an IETF assigned liaison manager to someone bring a draft to the IETF, do you?

Okay, that was a cut-paste disaster. s/ "to someone bring" / "for someone to bring"

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 2 Nov 2012 00:22:17 +0100

I think you got the point. I can't help it if you don't think it is an issue. 

We'll see if OMA come back or not to test if you are right or wrong.

Keith

> From: Ben Campbell [mailto:[email-masked]]
> Sent: 01 November 2012 23:12
> To: DRAGE, Keith (Keith)
> Cc: Hannes Tschofenig; Olle E. Johansson; Bernard Aboba; [email-masked]
> > I'm trying to figure out how "abandoning 5727" follows from "no liaison
> manager for OMA". I'm not getting it; can you elaborate?
> >
> >>
> >> OMA last asked for 6 header fields to be registered. As far as I
> understand they were told they needed a standards track RFC to do this.
> Identifying no need for cooperation tells me that IETF is quite happy they
> have their own version of the SIP specification.
> >>
> >
> > I don't think choosing not to assign a liaison manager implies we expect
> no cooperation. You don't need an IETF assigned liaison manager to someone
> bring a draft to the IETF, do you?
> 
> >>> Does anyone on this list believe that there is a need for cooperation
> with
> >>> the OMA?
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>> Sent from my ASUS Pad
> >>>
> >>>> There is a liaison, but I don't think it's been very active for a
> while
> >>> now.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 2 Nov 2012 09:49:03 +0100

Hi Olle,

> My opinion on OMA cooperation is that if we can kick off work in this group to complete and/or correct IETF simple into an interoperable state for buddy lists and Xcap, and we see a need for using…

OMA has its own set of documents, and some of the stuff they specified is interesting and useful, for example the support for external references in pres-rules. If we have external references in pres-rules we can create a template and then any operation is performed just in the resource-lists document, which then avoids any atomicity related problem. There are downsides, however:

  - They define their own AUID 'org.openmobilealliance.pres-rules', so managing policy for the same AoR must be done with the same kind of devices: either all pure-IETF or pure-OMA, but if you mix them, which document should the server look at? Right now all Open Source SIP server that I know of treat both documents the same, which is wrong, different AUIDs shouldn't override each other. FWIW, I'm in the process of fixing this in OpenSIPS.

  - Having a oma pres-rules document which just points to a resource-lists document means that we can no longer get the policy for a watcher by just looking at pre-rules. This makes me think that we need a single document to store a buddy-list, which also contains the  policy for each buddy. 

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 2 Nov 2012 11:46:56 +0100

> - Having a oma pres-rules document which just points to a resource-lists document means that we can no longer get the policy for a watcher by just looking at pre-rules. This makes me think that we…

SO what I say and repeat 1000 times: authorization MUST be an
*attribute* of each buddy. Period. Drop "users lists" named
"allowed-buddies" / "blocked-buddies", that's not the way to go.

buddylist:
--------------------
sip:[email-masked] {
  presence-subscribe-to: true,
  presence-allowed: true,
  presence-blocked: false
}

sip:[email-masked] {
  presence-subscribed-to: true,
  presence-allowed: true,
  presence-blocked: true
}
--------------------

And that's all. This is easy to render for the watcher and easy to
process for the server. Single "document" with buddies and their
attributes.

No need for "external references to other XCAP documents in any other
server in the world", no need for generating a coredump if the same
buddy is contained in "oma_my_buddies" list and "my_blocked_contacts"
list and "oma_PoC_contacts" list and "oma_featured_buddies" list.

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 2 Nov 2012 13:00:40 +0100

> "allowed-buddies" / "blocked-buddies", that's not the way to go.

And when did I say otherwise? :-O

> buddylist:

This is what we did in our addressbook implementation, while maintaining compatibility to the highest possible degree.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 2 Nov 2012 13:07:21 +0100

> This is what we did in our addressbook implementation, while maintaining compatibility to the highest possible degree.

And what is the point in "mantaining compatibility" if no other SIMPLE
client will understand the advanced document format of your
resource-list document? (they will probably delete it and regenerate
it).

And, if we just need a single document (based on buddies with
attributes) why do we need so many scattered XML/XCAP documents in the
server? and why does the presence server need to deal with N XML
documents and external references between them?

Why do we need a "RLS document" for presence subscription if we can
set an attribute "presence-subscribe-to" for each buddy in our
buddylist so the server already knows which users to subscribe to? Why
do we need a pres-rules documents if authorization rules are given via
buddy attributes? why do we need 95% of SIMPLE/XCAP specs if a single
document is enough?

And why to mantain "backward compatibility" if there is NO one full
working SIMPLE client out of walled gardens (apart from Blink which,
finally, works well but just when using the server infrastructure
designed for it)?

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 2 Nov 2012 13:25:42 +0100

> finally, works well but just when using the server infrastructure

You misundertood. That how we did it *for now*. I never ever mentioned there shouldn't be a better way nor that this is how I (personally) would like SIMPLE presence to look like. But I can't just simply implement a solution which only works with myself. Hence the backwards compatibility.

I'd love to see a better model endorsed by SIMPLE and then happily implement it. I think we do share this goal :-)

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 2 Nov 2012 13:27:42 +0100

> You misundertood. That how we did it *for now*. I never ever mentioned there shouldn't be a better way nor that this is how I (personally) would like SIMPLE presence to look like. But I can't just…

"backwards compatibility" with what?

> I'd love to see a better model endorsed by SIMPLE and then happily implement it. I think we do share this goal :-)

Sure we agree here. The key is: reusing SIMPLE/XCAP specs? or making
something better from scratch (after learning from current SIMPLE/XMPP
specs)?

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 2 Nov 2012 13:30:21 +0100

> "backwards compatibility" with what?

With the current specs, obviously.

> something better from scratch (after learning from current SIMPLE/XMPP

That's a different discussion.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 2 Nov 2012 13:31:09 +0100

> With the current specs, obviously.

XDDDDDDDD

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 2 Nov 2012 09:20:05 -0500

(as individual)

> something better from scratch (after learning from current SIMPLE/XMPP

Do you really believe nothing is salvageable? For example, would you jettison all of the below?

-- Using SIP in the first place
-- SIP Events
-- RLS
-- SIP Message
-- MSRP
-- XCAP
-- etc

From the discussions so far, it sounds like most of the complaints are in the area of reusing user lists between clients (e.g. contact lists, presence rules, etc). Do people really hate the entire SIMPLE suite, or is it just an XCAP issue.

If the scope of the work is "start over from scratch", then it seems like we would be better served starting with XMPP. I'd be very surprised if we could get support for creating "yet another presence and IM protocol".

We've been there before and it wasn't pretty.

---

From: "Roy, Radhika R CIV (US)" <[email-masked]>
Date: Fri, 2 Nov 2012 14:40:58 +0000

Folks:

Like Ben, I also believe that to start from the scratch is a non-starter as
people do not know yet what the "magic model" exists to have the golden
opportunity of interworking. 

No one is sure how all these interoperability problems will be solved as
people are adding a lot intelligence based on requirements what they feel
need to be added in IM and Presence.

It indicates one fundamental thing: These applications are popular and will
be used now and in the future not only as a stand-alone application, but
integration with audio, and video including emergency calls.

So, it would be prudent for all of us who have gained real in-depth
understanding after working in building specs, developing, and implementing
SIMPLE and XMPP to guide the entire commercial industry to adopt a kind of
standard-based IM and Presence model.

Let us be prepared that all of these will be a kind of learn, adopt, modify,
and create at time goes on in supporting and building the popular
application protocols like IM and Presence.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Campbell
Sent: Friday, November 02, 2012 10:20 AM
To: Iñaki Baz Castillo
Cc: Bernard Aboba; DRAGE, Keith (Keith); [email-masked]
Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and… (new subject)

(as individual)

On Nov 2, 2012, at 7:27 AM, Iñaki Baz Castillo <[email-masked]> wrote:

>> I'd love to see a better model endorsed by SIMPLE and then happily
implement it. I think we do share this goal :-)
> something better from scratch (after learning from current SIMPLE/XMPP

Do you really believe nothing is salvageable? For example, would you
jettison all of the below?

>From the discussions so far, it sounds like most of the complaints are in
the area of reusing user lists between clients (e.g. contact lists, presence
rules, etc). Do people really hate the entire SIMPLE suite, or is it just an
XCAP issue.

If the scope of the work is "start over from scratch", then it seems like we
would be better served starting with XMPP. I'd be very surprised if we could
get support for creating "yet another presence and IM protocol".

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 2 Nov 2012 15:44:45 +0100

Hi Ben,

> From the discussions so far, it sounds like most of the complaints are in the area of reusing user lists between clients (e.g. contact lists, presence rules, etc). Do people really hate the entire…

IM and SIP events are nice, the problem I've experienced with SIMPLE was letter P. The fact that a complex protocol (XCAP) was used along with multiple documents, and stretching resource-lists to contain a buddylist is what creates trouble. Actually XCAP is fine for storage, if we remove that default namespace problem and find a way to have something like xcap-diff which contains full contacts every time.

> We've been there before and it wasn't pretty.

Not sure if anybody has had problems with the IM part, but I'm pretty sure Iñaki is talking just a bout the presence part, just as I am.

Now, assuming we are just considering presence here, we could go either way: create a completely new spec which reuses nothing from the current (or maybe SIP events) or try to reuse what would "make sense" without compromising the whole design. The problem is that if we go the reusing route, is it acceptable that all specified documents are discarded,a  new document type is created and XCAP default namespace handling is fixed? I would not be backward compatible, of course.

IMHO this is the key point before starting to design any solution to the problem, because if it won't be accepted / adopted no matter how clever it is, we better do something else.

My 2 cents. Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Emil Ivov <[email-masked]>
Date: Fri, 02 Nov 2012 16:45:52 +0100

Hey all,

Since it's rant time ...

On 02.11.12, 15:20, Ben Campbell wrote:
>>> I'd love to see a better model endorsed by SIMPLE and then
>>> happily implement it. I think we do share this goal :-)
>> 
>> Sure we agree here. The key is: reusing SIMPLE/XCAP specs? or
>> making something better from scratch (after learning from current
>> SIMPLE/XMPP specs)?
> 
> -- Using SIP in the first place -- SIP Events -- RLS -- SIP Message 
> -- MSRP -- XCAP -- etc

I've never really understood how one could justify the use of a
completely different protocol to send IMs ... as if SIP was not complex
and evolved enough to handle this. And then that new protocols is just
so awesome that one can't have different chat sessions with different
people unless they setup different connections/sockets for every
conversation. Seriously?

Then, because the above was clearly not fun enough, we add yet another
completely different protocol for storing contacts lists.

I don't know the history but the result is just way beyond my understanding.

XMPP, MSN, Yahoo! Messenger, Gadu-Gadu, ICQ, AIM (before and after they
converged in OSCAR), Skype, they all managed to handle IM, presence and
contact storage with a single protocol.

SIP needed three.

Today those are implemented within different server-side applications
that then need to be deployed together. They need to be configured to
share user bases and policies. This hinders deployment and .. well ...
almost no one does it.

If there's a remake then could we please consider consolidating the
whole thing?

>> From the discussions so far, it sounds like most of the complaints
>> are in the area of reusing user lists between clients (e.g. contact
>> lists, presence rules, etc). Do people really hate the entire
>> SIMPLE suite, or is it just an XCAP issue.
> 
> If the scope of the work is "start over from scratch", then it seems
> like we would be better served starting with XMPP. 

We've seen relative ease of adoption with solutions of this kind:

draft-ivov-xmpp-cusax

I am by no means insisting that a similar model has to be adopted by a
SIMPLE successor but it has to be at least that easy to deploy.
Preferably easier.

Emil

> I'd be very
> surprised if we could get support for creating "yet another presence
> and IM protocol".

> _______________________________________________ Simple mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/simple
> 

-- 
https://jitsi.org

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 2 Nov 2012 16:53:47 +0100

> people unless they setup different connections/sockets for every

If memory serves correctly, you could stay connected with your relay and send all sessions through it, since session multiplexing over a single TCP connection is supported.

> contact storage with a single protocol.

Very good point.

> SIMPLE successor but it has to be at least that easy to deploy.

Thanks for your input Emil!

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 2 Nov 2012 17:28:38 +0100

> From the discussions so far, it sounds like most of the complaints are in the area of reusing user lists between clients (e.g. contact lists, presence rules, etc). Do people really hate the entire…

To narrow it down, again.

It is an XCAP issue that is related to storage of the presence rules. The SIP Presence Agent must be able to read it too. It should be a single document that stores both the contacts and their policy.

This is the only really issue in my opinion.

Adrian

---

From: Mary Barnes <[email-masked]>
Date: Sun, 4 Nov 2012 07:15:55 -0600

> Okay, that was a cut-paste disaster. s/ "to someone bring" / "for someone
[MB] Correct, you do not need an IETF appointed liaison manager in order to
work with another SDO/forum. There is an email address for any liaison
statements to be sent and those are generally distributed to the
appropriate parties.  The drafts run the normal course through the process.
 Note, that IETF only recently decided they did not need a liaison manager
for OMA as the individual that was in that role was no longer able to do
it.  But, the assessment at that time was that one was not needed. The onus
is not on IETF to drive the contributions from another SDO.  The onus is on
the individuals that are driving the work.  [/MB]

---

From: Mary Barnes <[email-masked]>
Date: Sun, 4 Nov 2012 07:18:54 -0600

> I think you got the point. I can't help it if you don't think it is an
[MB] It's to clear to me what point you think Ben got as he lighted there
are two separate things. [/MB]

> We'll see if OMA come back or not to test if you are right or wrong.
[MB] A message has been sent to OMA that we are not appointing a new
liaison manager:
https://datatracker.ietf.org/liaison/1213/
If OMA believes that is a problem, then they should reply to the IETF and
we can discuss if there is a need. Since it seems you have a vested
interest in this area, are you willing to serve as the IETF liaison?  One
of the issues when Murray stepped down was that there wasn't an obvious
individual that could take on the role. [/MB]

> > > On Nov 1, 2012, at 6:00 PM, "DRAGE, Keith (Keith)"
> <keith.drage@alcatel-
> > lucent.com> wrote:
> > >