Subject: Re: [Simple] draft-ietf-simple-simple-05

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Oct 2010 12:31:09 -0400

If there is still interest in this document, I can fold in any comments 
and finish it up.

Thanks,
Jonathan R.

On 9/24/2010 10:59 AM, Ben Campbell wrote:
> Hi,
>
> The SIMPLE working group has a milestone for an annotated guide to the SIMPLE specifications. The work item for this is draft-ietf-simple-simple-05. Some time ago, we put that draft on the back burner, on the reasoning that we could not complete it until the SIMPLE working group was otherwise winding down. It seems like we've reached that point.
>
> Do people still have an interest in this milestone? Do the author (Jonathan) and other participants intend to invest the time needed to generate text and offer detailed feedback? If so, please respond as soon as possible--we will interpret silence to mean no interest.
>
> Thanks!
>
> Ben.

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Chief Technology Strategist                    Mobile: +1 (732) 766-2496
Skype                                          SkypeIn: +1 (408) 465-0361
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Oct 2010 12:37:09 -0500

(as individual)

I'd personally like to see us finish this one. I don't think its that far from being done, particularly since some of the work that this was pending on has been removed from our plate.

Thanks!

Ben.

On Oct 13, 2010, at 11:31 AM, Jonathan Rosenberg wrote:

> If there is still interest in this document, I can fold in any comments and finish it up.
> 
> Thanks,
> Jonathan R.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 26 Oct 2010 23:38:05 +0200

2010/9/24 Ben Campbell <[email-masked]>:
> The SIMPLE working group has a milestone for an annotated guide to the SIMPLE specifications [...]
> Do people still have an interest in this milestone?

Please, don't take me wrong but:

- draft-ietf-simple-intradomain-federation  =>  recently "dead" state

- draft-ietf-simple-interdomain-scaling-analysis  =>  recently "dead" state

- draft-ietf-simple-simple  =>  no interest

- Interest of Internet community in SIMPLE specs   =>  nothing (big
telcos/vendors
  are not "Internet community")

- Interest of Internet community in XMPP  =>  a lot

draft-ietf-simple-simple claims "SIMPLE made Simple" but it references
more than 40 RFC's, and many of those RFC's reference various RFC's as
normative specifications. How can it be called "simple"?

In Internet there is more interest about Twitter API than about SIMPLE
specs. Perhaps it is time to recognize that the whole SIMPLE specs are
over-enginered, are too much complex and require too much exotic stuff
(who wants to receive a XML document containing partial modifications?
who wants to manipulate a remote XML document in order to create a
buddy instead of using a single like-API function "create buddy"? why
should a presence server inspect which exact incremental changes I've
done in a XML document in order to know if I want to create a buddy,
update it or give him presence watching permissions?

Before a presence server deliveries a NOTIFY to a watcher it must
merge various XML documents (following unclear rules), filter some
nodes based on exotic privacy rules and compose the final XML
document. In the other side XMPP just works and people love it.

How is possible that XCAP is based on XPATH 1.0 but it's not compliant
with it due to the "application default namespace" feature (just to
save a few bytes in the HTTP request !!!)? So forget using the widely
used libxml library (except if you do a dirty hack as I did).

As I said before please don't take me wrong. It's not my intention to
offend SIMPLE group, but... really, is not clear enough that SIMPLE
has failed (especially in presence area)? How can you expect that
people out there could be interested in "SIMPLE interdomain scaling
analysis / federation"?

Best regards.

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 27 Oct 2010 16:08:07 +1100

Inaki,

Let me address some of your points.

The internet drafts you refer to as dead or "no interest" have nothing to do
with the SIMPLE protocols that enable the presence and IM services. Those
IDs are informational in nature and do not contribute to the protocols or
their interoperability. Your interpretation of the lack of interest in
finishing those IDs is negative. My intepretaion is positive. I interpret
that as the community has enough knowledge about the protocols and their
implementations and does not require "informational" documents telling them
how to utilise those protocols.

You say the internet community has no interest in SIMPLE but have a lot of
interest in XMPP. Well, I guess you can say the internet omminity is Google,
Twitter and Facebook, all utilise the "basic" IM capabilities and some
utilise the "basic" presence capabilities. Well, SIMPLE protocols are much
more capable, much more feature rich and much more advanced in their
functionality. Let me add that SIMPLE's lack of use by the internet
community came from its own creators taking way too long in completing the
protocols and not becuase the protocols are too complex. If it wasn't for
certain individual contributors to the SIMPLE standards causing delays,
controversies and having strong backing by their employer to do so, the
SIMPLE standards would have by far outweighed any other standards in usage
and distribution. But in the end, we ended up with feature rich protocols
that walk all over other protocols in terms of capabilities.

Now we are back at IETF with XMPP trying to add features to it.

You say who wants to update XML documents where API calls are better suited.
IETF is not in the business of standardising APIs, and XMPP is a protocol.
How you store and modify information in a database is a matter of taste. I
think you lack knowledge about presence data manipulation and your comments
about XML document manipulation are ill informed and critisises features are
annoyances. Do you prefer to upload a whole XML document every time you want
to add a buddy? If that is the case then feel free to do so in your
implementation. Also you're picking of the XPATH 1.0 feature, what's this
about XMPP using restriced XML?

The point here is that both have pros and cons.

You refer to telcos and big vendors as insegnificant entities. Like it or
not, they are big multi-billion dollar players in the industry and make use
of many, many IETF protocols in their networks. And they just happen to
choose SIMPLE as their IM and presence protocols. Is Microsoft a telco or
part of the internet community?

XMPP has its market and SIMPLE has its market. There is no proof to argue or
think otherwise.

BTW, what Unified Communications products does your company use?

Hisham

On 27 October 2010 08:38, Iñaki Baz Castillo <[email-masked]> wrote:

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

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 27 Oct 2010 16:08:48 +1100

by the way, please don't get me wrong.

On 27 October 2010 16:08, Hisham Khartabil <[email-masked]>wrote:

> The internet drafts you refer to as dead or "no interest" have nothing to
> do with the SIMPLE protocols that enable the presence and IM services. Those
> You say who wants to update XML documents where API calls are better
> suited. IETF is not in the business of standardising APIs, and XMPP is a
> protocol. How you store and modify information in a database is a matter of
> taste. I think you lack knowledge about presence data manipulation and your
> comments about XML document manipulation are ill informed and critisises
> features are annoyances. Do you prefer to upload a whole XML document every
> time you want to add a buddy? If that is the case then feel free to do so in
> your implementation. Also you're picking of the XPATH 1.0 feature, what's
> this about XMPP using restriced XML?
>
> XMPP has its market and SIMPLE has its market. There is no proof to argue
> or think otherwise.
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 27 Oct 2010 12:07:46 +0200

> Inaki,

Hi Hisham. First of all thanks a lot for your detailed response. It's
more or less the first time I can debate about SIMPLE status :)

> their interoperability.

Being honest I meant "interest in SIMPLE". I don't care too much about
the interest in those informational drafts.

> I interpret

Such interpretation is too much optimistic IMHO.

When there is interest in a protocol/specification you can see traffic
in users/implementors maillist (let's say "community"). How much
traffic about SIMPLE is there in sip-implementors maillist?

I just see some traffic in this maillist ([email-masked]) and most of
the mails come from ID authors. No doubts, no questions, no debates...
IMHO SIMPLE is complex enough (more than 40 RFC's referencing more and
more RFC's) so we cannnot expect, in any way, that "no more help or
guidelines are required".

> Twitter and Facebook,

I didn't mean that. I meant that there are a lot of XMPP clients (many
of them open source) which interoperate very well. Compared to SIMPLE
reality XMPP wins.

> all utilise the "basic" IM capabilities and some utilise the "basic" presence capabilities.

I don't agree. Google implements "invisible status" (a XEP of XMPP),
an useful feature that doesn't exist in SIMPLE (can you tell the
presence server not to show presence status for all your online
devices?).

> Well, SIMPLE protocols are much
> functionality.

I strongly don't agree.

- In XMPP Alice can be online in two devices (two resources) so Bob
can see status of both resources (device "Android" and device
"Pidgin"). Bob can also choose which exact device to communicate with
(without the need of generating parallel forking in Alice's server).
This last feature could be implemented in SIMPLE by adding GRUB to the
presentity.

In SIMPLE the equivalent is NOT clear, not at all. You can receive a
NOTIFY with various <tuple> or <device> even <person> but it's fully
unclear how to interpret them. Also in SIMPLE you can get a NOTIFY
with status "open" and "<contact>mailto:[email-masked]</contact>".
What is it? people is *always* "online" in his mail as it's
asynchronous communication. I just want to know if you are "online" in
SIP protocol as I want to call/IM you.

- In XMPP you can send direct presence to a specific user (to appear
as "bussy" just for him).

These two features are included in what you name "basic presence
capabilities" (RFC 3921).

About budylist management I can say nothing good about
"resource-lists" specification, a complete pain IMHO. Not powerful at
all (just "uri" and "display-name" per buddy). It's not possible to
assign N groups to a buddy (as buddies belong to groups instead of
groups being attributes of each buddy). And better if we forget the
"useful" feature of "nested lists".

Finally we get with OMA/RCS resource-lists specifications in which the
XML document contains lots of http absolute references to itself
(<external anchor="http://...".>). Also "logic" groups
("granted-contacts", "blocked-contacts"....) are mixed with
descriptive groups ("friends", "workers", "family"...).

Even worse: in RCS specification for resource-lists (an extra layer
over OMA specs, being OMA specs an extra layer of SIMPLE RFC's and so
on...) the final resource-lists document is "so powerful" that just
allows "allowed users" and "blocked users". Don't try to set a
descriptive group for each buddy in your buddylist or you will break
the document constrains imposed by RCS. Can it be called "feature
rich"?

> IETF is not in the business of standardising APIs, and XMPP is a protocol.

I don't want IETF to define "API calls":

In XMPP when you want to create a buddy you send a message to the
server in which it's fairly *clear* that you want to create (or update
if it exists) a buddy. I imagine it as an API function:
  - Class: Roster  => XMPP buddylist is called "roster"
  - Method:  set

It's easy and obvious. If you inspect the request you already know the
meaning of such request.

In the other side, in XCAP there is no semantics. To create a new
buddy you perform a remote incremental change in a XML document. By
inspecting the sole request you cannot know its exact purpose (you
must wait to see the resulting XML whole document to interpret "what
has happened"). For example:

- I want to block Bob ("presence" event).
- Then I can send an incremental DELETE to remove Bob from "granted-list".
- Then an incremental PUT to add Bob in "blocked-list".

Is it enough? NOT!!

- Now it's required to check if Bob is also included in other list or
nested list into the too-much-flexible "resource-list" document
(perhaps Bob is included in a list referenced from "granted-list" so
it would remain allowed).

- And also the complex pres-rules (full of <external anchor> entries)
must be inspected. There could be a rule in pres-rules pointing to
"blocked-contacts" with action "block", but there could also be an
individual <entry uri="sip:[email-masked]"> with action "allow" in
pres-rules document, so the modification in resource-lists is not
enough.

And do we expect that the client device can render all the exotic
possibilities to the human? can we expect that device-A sharing AoR
with device-B will interpret the same by inspecting the relationship
between resource-lists and pres-rules documents? and also the same as
the presence server interprets? and also the same as the XCAP server
interprets when receives a HTTP GET to retrieve the photo/icon of
Alice?

Instead in XMPP blocking a contact is EASY and RELIABLE. And it works.

> implementation.

I didn't mean this. I hope I've replied to this question just in my
text above :)

> Also you're picking of the XPATH 1.0 feature, what's this

It's not the same:
"Restricted XML" means that you can reuse any existing XML library
(but must include constrains at application level).
This is not the case with XCAP with includes a unneeded feature which
breaks compatibility with XPATH 1.0 so you *cannot* resue any existing
xpath-1.0 library.

> of many, many IETF protocols in their networks.

Yes sure. I cannot discuss that. But from my point of view an OPEN
specification/protocol is successful when it also wins in Internet
community (this is: there are implementations, clients, servers,
open-source software.... so far from closed big telcos/vendors). This
is not the case of SIMPLE, sure. And honestly I cannot understand that
SIMPLE group doesn't care it.

> And they just happen to choose SIMPLE as their IM and presence protocols.

Yes, and after that there are already various drafts trying to define
how to integrate XMPP with SIP in order to get something reliable.

> Is Microsoft a telco or part of the internet community?

I don't think Microsoft can be a good example of nothing. And I don't
consider it as "Internet community", but neither Google or Facebook.

> XMPP has its market and SIMPLE has its market.

Sure, but the market of SIMPLE seems to be hidden for now :)

> BTW, what Unified Communications products does your company use?

Custom solution using open SIP servers/proxies for voice integrated
with open XMPP servers. Voice works, IM and presence just work.

IMHO it's a hack, I strongly desire to use a pure 100% SIP based
solution for presence, but after spending lot of time in SIMPLE specs
I don't believe in SIMPLE anymore.

Best regards and thanks a lot for your response.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 27 Oct 2010 12:08:25 +0200

> by the way, please don't get me wrong.

Not at all.

PS: I ask the same to you :)

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

---

From: Bruno von Niman <[email-masked]>
Date: Wed, 27 Oct 2010 12:25:13 +0200

I'm a newcomer to SIMPLE (following up a liaison issue from ETSI, to work
with you on) - so, probably the ultimate proof of life:-)!

I also wish there was more activity - certainly in the addressing of
important user requirements (such as the "invisible" status, being a good
example), if we wish to provide communication in a user-centric way.

Best regards,
Bruno von Niman

> 2010/10/27 Hisham Khartabil <[email-masked]>:

Hi Hisham.
> First of all thanks a lot for your detailed response. It's
more or less the
> first time I can debate about SIMPLE status :)

> The internet drafts you
> refer to as dead or "no interest" have nothing to do
> with the SIMPLE
> protocols that enable the presence and IM services. Those
> IDs are
> informational in nature and do not contribute to the protocols or
> their
> interoperability.

Being honest I meant "interest in SIMPLE". I don't care too
> much about

> I interpret
> that
> as the community has enough knowledge about the protocols and their
>

Such interpretation is too much optimistic
> IMHO.

When there is interest in a protocol/specification you can see
> traffic
in users/implementors maillist (let's say "community"). How
> much

I just see
> some traffic in this maillist ([email-masked]) and most of
the mails come
> from ID authors. No doubts, no questions, no debates...
IMHO SIMPLE is complex
> enough (more than 40 RFC's referencing more and
more RFC's) so we cannnot
> expect, in any way, that "no more help or

> You
> say the internet community has no interest in SIMPLE but have a lot of
>

I didn't mean that. I meant that there are a lot of
> XMPP clients (many
of them open source) which interoperate very well. Compared
> to SIMPLE
reality XMPP wins.

> all utilise the "basic" IM capabilities and
> some utilise the "basic" presence capabilities.

I don't agree. Google
> implements "invisible status" (a XEP of XMPP),
an useful feature that doesn't
> exist in SIMPLE (can you tell the
presence server not to show presence status
> for all your online
devices?).

> more
> capable, much more feature rich and much more advanced in their
>
> functionality.

I strongly don't agree.

- In XMPP Alice can be online in two
> devices (two resources) so Bob
can see status of both resources (device
> "Android" and device
"Pidgin"). Bob can also choose which exact device to
> communicate with
(without the need of generating parallel forking in Alice's
> server).
This last feature could be implemented in SIMPLE by adding GRUB to
> the
presentity.

In SIMPLE the equivalent is NOT clear, not at all. You can
> receive a
NOTIFY with various <tuple> or <device> even <person> but it's
> fully
with
> status "open" and "<contact>mailto:[email-masked]</contact>".
What is it?
> people is *always* "online" in his mail as it's
asynchronous communication. I
> just want to know if you are "online" in
SIP protocol as I want to call/IM
> you.

as
> "bussy" just for him).

These two features are included in what you name
> "basic presence

About budylist management I can
> say nothing good about
"resource-lists" specification, a complete pain IMHO.
> Not powerful at
all (just "uri" and "display-name" per buddy). It's not
> possible to
assign N groups to a buddy (as buddies belong to groups instead
> of
groups being attributes of each buddy). And better if we forget
> the

Finally we get with OMA/RCS
> resource-lists specifications in which the
XML document contains lots of http
> absolute references to itself
(<external anchor="http://...".>). Also "logic"
> groups
descriptive
> groups ("friends", "workers", "family"...).

Even worse: in RCS specification
> for resource-lists (an extra layer
over OMA specs, being OMA specs an extra
> layer of SIMPLE RFC's and so
on...) the final resource-lists document is "so
> powerful" that just
allows "allowed users" and "blocked users". Don't try to
> set a
the
> document constrains imposed by RCS. Can it be called "feature
rich"?

> Now
> we are back at IETF with XMPP trying to add features to it.
>
> You say who
> wants to update XML documents where API calls are better suited.
> IETF is not
> in the business of standardising APIs, and XMPP is a protocol.

I don't want
> IETF to define "API calls":

In XMPP when you want to create a buddy you send
> a message to the
server in which it's fairly *clear* that you want to create
> (or update
  - Class:
> Roster  => XMPP buddylist is called "roster"
  - Method:  set

It's easy and
> obvious. If you inspect the request you already know the
meaning of such
> request.

In the other side, in XCAP there is no semantics. To create a
> new
buddy you perform a remote incremental change in a XML document.
> By
must
> wait to see the resulting XML whole document to interpret "what
has
> happened"). For example:

- Then I
> can send an incremental DELETE to remove Bob from "granted-list".
- Then an
> incremental PUT to add Bob in "blocked-list".

Is it enough? NOT!!

- Now it's
> required to check if Bob is also included in other list or
nested list into
> the too-much-flexible "resource-list" document
(perhaps Bob is included in a
> list referenced from "granted-list" so

- And also
> the complex pres-rules (full of <external anchor> entries)
must be inspected.
> There could be a rule in pres-rules pointing to
"blocked-contacts" with action
> "block", but there could also be an
individual <entry
> uri="sip:[email-masked]"> with action "allow" in
pres-rules document, so the
> modification in resource-lists is not
enough.

And do we expect that the
> client device can render all the exotic
possibilities to the human? can we
> expect that device-A sharing AoR
with device-B will interpret the same by
> inspecting the relationship
between resource-lists and pres-rules documents?
> and also the same as
the presence server interprets? and also the same as the
> XCAP server
interprets when receives a HTTP GET to retrieve the photo/icon
> of
Alice?

Instead in XMPP blocking a contact is EASY and RELIABLE. And it
> works.

> to add a buddy? If that is the case then feel free to do so in

I didn't mean this. I hope I've replied to this
> question just in my
text above :)

> about XMPP using restriced XML?

It's not the
> same:
(but
> must include constrains at application level).
This is not the case with XCAP
> with includes a unneeded feature which
breaks compatibility with XPATH 1.0 so
> you *cannot* resue any existing
xpath-1.0 library.

> You refer to telcos
> and big vendors as insegnificant entities. Like it or
> not, they are big
> multi-billion dollar players in the industry and make use
> of many, many IETF

Yes sure. I cannot discuss that. But from my
> point of view an OPEN
specification/protocol is successful when it also wins
> in Internet
community (this is: there are implementations, clients,
> servers,
open-source software.... so far from closed big telcos/vendors).
> This
is not the case of SIMPLE, sure. And honestly I cannot understand
> that

> as their IM and presence protocols.

Yes, and after that there are already
> various drafts trying to define
how to integrate XMPP with SIP in order to get
> something reliable.

> Is Microsoft a telco or part of the internet

I don't think Microsoft can be a good example of nothing. And I
> don't
consider it as "Internet community", but neither Google or
> Facebook.

> XMPP has its market and SIMPLE has its market.

Sure, but the
> market of SIMPLE seems to be hidden for now :)

> BTW, what Unified
> Communications products does your company use?

Custom solution using open SIP
> servers/proxies for voice integrated
with open XMPP servers. Voice works, IM
> and presence just work.

IMHO it's a hack, I strongly desire to use a pure
> 100% SIP based
solution for presence, but after spending lot of time in SIMPLE
> specs

Best regards and thanks a lot for
> your response.

-- 
Iñaki Baz
> Castillo
<[email-masked]>
Simpl
> e mailing list
[email-masked]

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 27 Oct 2010 14:37:35 +0200

I was involved in the two drafts that were declared dead (scaling analysis 
and intradoman).
While both were informational in IETF status their intent was more then 
informational.

The scaling analysis intention was to drive optimizations in the SIMPLE 
protocol
the intradomain had a specific intention of defining how presence server 
from the
same vendor could work in tandem in the same domain. There was zero 
interest on both.

Anyone can interperet this lack of interest as they wish.

tnx
Avshalom

From:   Iñaki Baz Castillo <[email-masked]>
To:     Hisham Khartabil <[email-masked]>
Cc:     Simple WG <[email-masked]>
Date:   27/10/2010 12:08 PM
Subject:        Re: [Simple] draft-ietf-simple-simple-05
Sent by:        [email-masked]

Not at all.

---

From: Brian McColgan <[email-masked]>
Date: Wed, 27 Oct 2010 12:36:28 -0400

I 100% agree with Hisham

SIP/SIMPLE Presence is built on top of CPIM/PIDF presence which has a very useful data model that reflects the real world (i.e. the person->service->device) and is fully extensible.

The biggest issue (pointed out very accurately by Avshalom's draft regarding inter-domain scaling) is reducing overhead of notifications (and processing resources) required to process PIDF.  

I would advise you have a look at the OMA Presence Access Layer (PAL) which is based on SIP/SIMPLE and OMA SIMPLE/Presence.  The industry is moving towards interoperable indicators based on an underlying real world sevice/usage model.  Ultimately the power in reflecting indications accurately and efficiently is a function of being able to provide repeatable contracts (or interfaces) around underlying sensory inputs on behalf of a presentity.  

Those inputs will undoubtedly cross-cut different areas, which is being taken into account by PIDF.  I don't see any similar mechanism 'in play' with XMPP presence stanzas.

Cheers,
Brian.

Date: Wed, 27 Oct 2010 16:08:07 +1100
From: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: [Simple] draft-ietf-simple-simple-05

Inaki,

The internet drafts you refer to as dead or "no interest" have nothing to do with the SIMPLE protocols that enable the presence and IM services. Those IDs are informational in nature and do not contribute to the protocols or their interoperability. Your interpretation of the lack of interest in finishing those IDs is negative. My intepretaion is positive. I interpret that as the community has enough knowledge about the protocols and their implementations and does not require "informational" documents telling them how to utilise those protocols.

You say the internet community has no interest in SIMPLE but have a lot of interest in XMPP. Well, I guess you can say the internet omminity is Google, Twitter and Facebook, all utilise the "basic" IM capabilities and some utilise the "basic" presence capabilities. Well, SIMPLE protocols are much more capable, much more feature rich and much more advanced in their functionality. Let me add that SIMPLE's lack of use by the internet community came from its own creators taking way too long in completing the protocols and not becuase the protocols are too complex. If it wasn't for certain individual contributors to the SIMPLE standards causing delays, controversies and having strong backing by their employer to do so, the SIMPLE standards would have by far outweighed any other standards in usage and distribution. But in the end, we ended up with feature rich protocols that walk all over other protocols in terms of capabilities.

You say who wants to update XML documents where API calls are better suited. IETF is not in the business of standardising APIs, and XMPP is a protocol. How you store and modify information in a database is a matter of taste. I think you lack knowledge about presence data manipulation and your comments about XML document manipulation are ill informed and critisises features are annoyances. Do you prefer to upload a whole XML document every time you want to add a buddy? If that is the case then feel free to do so in your implementation. Also you're picking of the XPATH 1.0 feature, what's this about XMPP using restriced XML?

You refer to telcos and big vendors as insegnificant entities. Like it or not, they are big multi-billion dollar players in the industry and make use of many, many IETF protocols in their networks. And they just happen to choose SIMPLE as their IM and presence protocols. Is Microsoft a telco or part of the internet community?

XMPP has its market and SIMPLE has its market. There is no proof to argue or think otherwise.

Hisham

telcos/vendors

analysis / federation"?

Best regards.

Simple mailing list

[email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 27 Oct 2010 19:04:18 +0200

2010/10/27 Brian McColgan <[email-masked]>:
> SIP/SIMPLE Presence is built on top of CPIM/PIDF presence which has a very
> useful data model that reflects the real world (i.e. the
> person->service->device) and is fully extensible.

"Extensible" doesn't meant "interoperable".

And also, this model fails when there are two devices publishing
presence for same AoR as both of them will publish < person> section.
However there is no way to determine which device each person belongs
to, so there is no way to realize that "Bob is away in his softphone
but online in his mobile device".
Both devices will publish <person> information generating a
race-condition. Theorically just one <person> should appear in a final
composed presentity, but how to decide which one?

> The biggest issue (pointed out very accurately by Avshalom's draft regarding
> inter-domain scaling) is reducing overhead of notifications (and processing
> resources) required to process PIDF.

Ok, so all the other items I've pointed in my previous mails are just
"perfect". Complexity and ambiguity seems not to be a problem here.

> I would advise you have a look at the OMA Presence Access Layer (PAL) which
> is based on SIP/SIMPLE and OMA SIMPLE/Presence.

OMA it's not based on IETF SIMPLE. OMA has tried to complete IETF
specs, that are incomplete, unclear and undefined.

OMA presence specs wouldn't be needed if SIMPLE RFC's would cover all
the presence items in a better and more *specific* way.

Does Google use an extra layer of specifications over XMPP? No, the
fact is that I can interoperate with Google's XMPP using any XMPP
client, and can federate from other domains and all works perfect.

>  The industry is moving
> towards interoperable indicators based on an underlying real world
> sevice/usage model.  Ultimately the power in reflecting indications
> accurately and efficiently is a function of being able to provide repeatable
> contracts (or interfaces) around underlying sensory inputs on behalf of a
> presentity.
>
> Those inputs will undoubtedly cross-cut different areas, which is being
> taken into account by PIDF.  I don't see any similar mechanism 'in play'
> with XMPP presence stanzas.

And what about all the XMPP features not present in SIMPLE I've told
in my previous mails??

Regards.

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

---

From: Brian McColgan <[email-masked]>
Date: Wed, 27 Oct 2010 13:47:49 -0400

> Date: Wed, 27 Oct 2010 19:04:18 +0200
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]
> 
Extensible means individuals or entities may enhance at their discretion.
No standardized effort is going to cover every scenario so yes PIDF/CPIM isn't perfect, but it gets us a lot closer than XMPP stanzas!

> "perfect". Complexity and ambiguity seems not to be a problem here.
Bang!  You _nailed_ the reasons why OMA developed PAL - to eliminate the ambiguity, and reduce the complexity while still leveraging the useful model. 
Glad to see your paying attention 8^)

> client, and can federate from other domains and all works perfect.
Okay, when you get to the point of trying to relay some status beyond (avail, busy, and offline) re-read the above paragraph.
The rest of the industry would like to move beyond 'simple simon status' Inaki.

> And what about all the XMPP features not present in SIMPLE I've told
Features or 'accidental artifacts of a hastily derived protocol', perhaps you can clarify?

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 28 Oct 2010 07:57:19 +1100

> guidelines are required".

I guess you weren't around a few years ago when mailing list traffic was
reflective of the interest in this work. The working group has completed the
core protocol work long ago and obviously mailing list traffic has dropped
considerably since.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 28 Oct 2010 00:04:52 +0200

2010/10/27 Brian McColgan <[email-masked]>:
> Bang!  You _nailed_ the reasons why OMA developed PAL - to eliminate the
> ambiguity, and reduce the complexity while still leveraging the useful
> model.

If OMA specs are so good and so simple, why doesn't RCS reuse OMA's
resource-list and instead RCS has created its own specification?

So, we have a set of specifications (SIMPLE) but such documents
require an extra layer of specifications over them (OMA) to make then
feasible. And do you think this is "normal"?

In XMPP I just need to read RFC 3920 and RFC 3921 (along with having
XML knowledge) and I already can implement a working client or server.
Of course there are extensions with new features (XEP's) but I don't
need an "extra-specification" to get the core protocol working.

> Okay, when you get to the point of trying to relay some status beyond
> (avail, busy, and offline) re-read the above paragraph.

Could you set out it please?

> Features or 'accidental artifacts of a hastily derived protocol', perhaps

In my previous mails I've exposed various cases and features existing
in XMPP and not in SIMPLE, along with several issues in SIMPLE itself.
If you take your time to reply them I'll also take my time to reply
your questions.

Anyhow, if you consider "accidental artifacts" features like "global
invisible status", "resource identification in presence notifications"
or an "easy-to-use buddylist" then, definitely, SIMPLE belongs to
other galaxy.

Best regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 28 Oct 2010 00:15:02 +0200

2010/10/27 Hisham Khartabil <[email-masked]>:

> The working group has completed the core protocol work long ago

Please, define "(SIMPLE) core protocol". Do you think that RFC 4826
(resource-lists) is part of the core protocol?
If I create a XCAP client implementing RFC 4826 and you implement your
own client, most probably we could not interoperate because the
document specification is so wide that your client won't be capable of
interpreting/rendering a resource-lists document generated by my
client (imagine I use nested and subnested lists). How can it be part
of the core protocol?

> and obviously mailing list traffic has dropped considerably since.

Yes, but such traffic should then take place in users or implementors
maillists (as sip-implementors maillist is full of questions about
SIP-voice). Where are the questions about SIMPLE? must I ask
permission to OpenMobileAlliance for participating in their private
forums (as they are not public)?

Best regards.

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

---

From: Brian McColgan <[email-masked]>
Date: Wed, 27 Oct 2010 18:53:54 -0400

Best of luck to you Inaki.  Lets see where things lie (e.g. in 2-3 more years), when the market has matured a bit more.

BR/Brian.

> Date: Thu, 28 Oct 2010 00:04:52 +0200

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 28 Oct 2010 01:23:36 +0200

I thought the original question being asked of the mailing list was whether the group wanted to proceed with a taxonomy of the SIMPLE related work as indicated in simple-simple.

I'm not sure how this discussion is getting us to an answer to that question - or indeed to anything else left in the SIMPLE charter.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian McColgan
Sent: Wednesday, October 27, 2010 11:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Simple] draft-ietf-simple-simple-05

BR/Brian.

---

From: David Viamonte <[email-masked]>
Date: Thu, 28 Oct 2010 01:46:49 +0200

Hi all,

While I do not want to add additional noise about SIMPLE vs. XMPP and 
simplicity / complexity of SIMPLE (I think some of Iñaki's points might 
be arguable, but others -such as some features he mentions or the number 
of nested references across RFC's and I-D's are simply objective facts 
he is raising). The fact that there are four refining-spec bodies (IETF, 
3GPP, OMA, GSMA) in some environments may also mean something in itself. 
I will leave for others to discuss that. Let me just say that plain 
comparison of XMPP vs. SIMPLE is also arguable: both frameworks have 
been conceived with quite different approaches from day one, and are 
being adopted by not exactly the same communities of users and Service 
Providers. Hence, things are not probably "right" or "wrong" with SIMPLE 
or XMPP, I think they are probably what they are, and if some of them 
are broken, they'll have to be fixed.

However, I made some early comments to the interdomain scaling drafts a 
long while ago. I was not in time to trigger any feedback to the calls 
made when the drafts were eventually declared "dead". This hence seems 
to be a second chance, so I will take it :-)

What I do want to comment is that, to me, the lack of list response 
related to these drafts is not completely related to the community 
having "enough" knowledge about these "mature" protocols, and hence 
being "confortable" with things "as they are". Nobody has real life 
experience today in interconnecting large SIP domains with millions of 
users from domain A subscribing to millions of users of domain B and 
generating frequent Presence updates due to sharing their "note" element 
in a Twitter-like way.

The topic might not be easy to handle, not attractive enough as it is 
not defining some completely new protocol (just trying to understand how 
defined protocols work), it might not be easy to monetize (carriers and 
Service Providers buy "features" rather than "optimizations"), or maybe 
given 3GPP/OMA/GSMA work around SIMPLE, the right forum for interdomain 
analysis is considered not to be IETF anymore.... Some of these might be 
good reasons for lack of interest, but I would doubt that everyone out 
there is completely confortable on how real-life interconnection of 
really large SIP domains will work, particularly in the Smartphone era, 
with users becoming more and more chatty, and operators getting more and 
more scared of the flat fee models they made so popular.

My two cents,

David

On 28/10/2010 00:15, Iñaki Baz Castillo wrote:
> 2010/10/27 Hisham Khartabil<[email-masked]>:
>

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 28 Oct 2010 09:06:57 +0200

I agree with your observations

Thanks for the input the you gave to the scaling analysis
and really sorry that the draft was not published as an RFC.

As someone that has experience in the field I must say that
the issues that were raised by the draft are still very real
issues.

Note that the draft went through several WGLCs and IETF
last calls but at the last moment at the IESG it got
input that should have been made long time before it
was made.

Note also that when trying to get "real numbers"
(that was one of the major comments of the IESG)
on packet sizes etc. we could not get anything. Is this an
indication to the lack of deployments or is it just that
all deployments do not want to reveal numbers? I do not know.

Avshalom 

From:   David Viamonte <[email-masked]>
To:     [email-masked]
Date:   28/10/2010 01:47 AM
Subject:        Re: [Simple] draft-ietf-simple-simple-05
Sent by:        [email-masked]

Hi all,

My two cents,

David

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 28 Oct 2010 14:38:09 +0200

2010/10/28 David Viamonte <[email-masked]>:
> The fact that there are four refining-spec bodies (IETF, 3GPP,
> OMA, GSMA) in some environments may also mean something in itself.

That's important IMHO. SIP presence area is mostly governed by 3GPP,
OMA, GSMA, whose target is more related to mobile world than to pure
Internet.
Also, such new specifications are designed in a closed forum (must I
work in Nokia if I want to join OMA maillist?).

These are important items helping us to understand why SIMPLE doesn't
success at all in "Internet".

> leave for others to discuss that. Let me just say that plain comparison of
> XMPP vs. SIMPLE is also arguable: both frameworks have been conceived with
> quite different approaches from day one, and are being adopted by not
> exactly the same communities of users and Service Providers. Hence, things
> are not probably "right" or "wrong" with SIMPLE or XMPP, I think they are
> probably what they are, and if some of them are broken, they'll have to be
> fixed.

The spirit of SIP is "intelligence in endpoints". This is as least
what I learned in RFC 3261 and related RFC's.
In fact, no RFC defines the concept of "B2BUA" (just a forgotten
draft), but there are B2BUA's everywhere.

Now when coming to presence area the philosophy changes dramatically
and we end with the most intelligent servers ever seen, so far from
routing, authentication or authorization purposes, but also involved
in documents inspection/composing/filtering/delivering. And we also
end with SIP devices having to speak XCAP (HTTP) protocol.

In OMA world we have XCAP servers (HTTP protocol) also speaking SIP to
behave as subscription server for "subscription to changes in
documents" (wow !).
And we also have an XCAP proxy (HTTP) delivering a request from a
client to various XCAP servers and merging the responses of each one
(WOW !!!).

According to those specs, a SIP device behaves as the most intelligent
manipulator of XML documents, receiving XML diffs (wow), performing
remote and incremental modifications over XML documents, and analyzing
the relationship between diferent XML documents to know if a buddy is
finally allowed or denied to watch our presence status.

Where is the original spirit of SIP? Doesn't the whole picture seem
enough complex in opinion of this working group? Perhaps the following
diagram helps a bit:
  http://oversip.net/public/SIP_SIMPLE_OMA.jpeg

> the lack of list response related to these drafts is not completely related to the community having "enough"
> knowledge about these "mature" protocols, and hence being "confortable" with
> things "as they are".

100% agreed. Assuming "silence" means "knowledge" is always wrong.

Best regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 30 Oct 2010 17:00:10 +0200

> This last feature could be implemented in SIMPLE by adding GRUB to the

Of course I meant GRUU :)

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 30 Oct 2010 12:27:34 -0400

> forums (as they are not public)?

For what it's worth, I'm not a big fan of SIMPLE presence stuff, but there is plenty of it being used in deployments, and it's growing every day.  In fact, the scaling stuff is now starting to hit the fan in some deployments.

But my point is I wouldn't take the lack of traffic on sip-implementers as a sign of anything.  The vendors that appear to be using SIMPLE a lot, rarely show up on that mailing list for even voice.  Generally I find the people on sip-implementers to be those who don't participate in the standards process and don't have teams of experts to ask internally - which is great, but the vendors that are doing SIMPLE right now are big dogs who send teams of people to the standards bodies, and either already know it or wouldn't ask questions publicly on that list anyway. 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 30 Oct 2010 12:59:11 -0400

OK, I'll interpret it my own way then: we have scaling problems, the interdomain-scaling-analysis draft showed calculations of the problems in various scenarios/optimizations... and no one wants to work on more *analysis* of the problems.  That doesn't mean people don't want to *fix* the problems.

I know this is unfair to you, because you spent a LOT of time on that draft and it shows... but I don't know what spending more time addressing the IESG's DISCUSS just so we can publish it as an RFC really buys us.  Going through the exercise and having it in a draft form is useful, but what difference does it make if it's an RFC or not?

The real question is if there are people in the IETF interested in *fixing* the problems.  I don't know that there are - I know some vendors who are experiencing these problems now, but I don't know if they'll come here or go to 3gpp/oma/rcs/etc. instead. :(

-hadriel

On Oct 27, 2010, at 8:37 AM, Avshalom Houri wrote:

> I was involved in the two drafts that were declared dead (scaling analysis and intradoman). 
> While both were informational in IETF status their intent was more then informational. 
> 
> The scaling analysis intention was to drive optimizations in the SIMPLE protocol 
> the intradomain had a specific intention of defining how presence server from the 
> same vendor could work in tandem in the same domain. There was zero interest on both. 
>

---

From: Avshalom Houri <[email-masked]>
Date: Sat, 30 Oct 2010 19:16:28 +0200

I think that having this as an RFC is useful as it will be a reference for 
further work.

I will be happy to complete the draft if the working group will become 
interested again or maybe
it should move it to different group as dispatch.

I assume that the willingness to work on optimizations will become 
stronger
as the scaling issues will be more and more evident.

-Avshalom

From:   Hadriel Kaplan <[email-masked]>
To:     Avshalom Houri/Haifa/IBM@IBMIL
Cc:     Simple WG <[email-masked]>
Date:   30/10/2010 06:59 PM
Subject:        [Simple] interdomain scaling analysis (was: 
draft-ietf-simple-simple-05)
Sent by:        [email-masked]

OK, I'll interpret it my own way then: we have scaling problems, the 
interdomain-scaling-analysis draft showed calculations of the problems in 
various scenarios/optimizations... and no one wants to work on more 
*analysis* of the problems.  That doesn't mean people don't want to *fix* 
the problems.

I know this is unfair to you, because you spent a LOT of time on that 
draft and it shows... but I don't know what spending more time addressing 
the IESG's DISCUSS just so we can publish it as an RFC really buys us. 
Going through the exercise and having it in a draft form is useful, but 
what difference does it make if it's an RFC or not?

The real question is if there are people in the IETF interested in 
*fixing* the problems.  I don't know that there are - I know some vendors 
who are experiencing these problems now, but I don't know if they'll come 
here or go to 3gpp/oma/rcs/etc. instead. :(

-hadriel

informational. 
protocol 
from the 
interest on both.