Re: SIMPLE and OMA and 3Gpp and RCS and… (new subject)

Hi Olle,

On Nov 1, 2012, at 10:13 PM, Olle E. Johansson wrote:

> =

> 1 nov 2012 kl. 21:08 skrev Hannes Tschofenig <[email protected]>:
> =

>> Murray was the liaison person to the OMA from the IETF side. Murray rece=
ntly discontinued his participation in the OMA (due to a job change). We di=
scussed 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 inte=
ract with the OMA had decreased over time. =

>> =

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

> For me, it is too early to answer. I'm just trying to assemble informatio=
n about how we ended up where we are with all these organizations working w=
ith 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 abl=
e to produce running interoperable code. =

> =

> I have no insights in the politics at that time, so I have no insight int=
o 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 gro=
up to complete and/or correct IETF simple into an interoperable state for b=
uddy lists and Xcap, and we see a need for using OMA documents within the I=
ETF we can revisit your question and produce an answer. =

> =


OMA has its own set of documents, and some of the stuff they specified is i=
nteresting and useful, for example the support for external references in p=
res-rules. If we have external references in pres-rules we can create a tem=
plate and then any operation is performed just in the resource-lists docume=
nt, which then avoids any atomicity related problem. There are downsides, h=
owever:

  - They define their own AUID 'org.openmobilealliance.pres-rules', so mana=
ging policy for the same AoR must be done with the same kind of devices: ei=
ther 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 tre=
at both documents the same, which is wrong, different AUIDs shouldn't overr=
ide 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 l=
ooking 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=FAl Ibarra Corretg=E9
AG Projects