Let's fix THE PROBLEM
"Rob Batchelder" <[email protected]> Sat, 12 Jul 2003 22:08:54 -0400
| Newsgroups | gmane.ietf.impp |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C348C2.2F4F7E60 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Dear IETF Contributors: To this point I have refrained from editorializing on the collective activities of the IMPP / SIMPLE / XMPP working groups. Admittedly, I have not attended many of the IETF meetings - or actively contributed to the working groups. Nevertheless, I am extremely active in the IM vendor community and do provide high level strategic counsel to the leading firms in this field. That being said, I feel confident that I can articulate some of their concerns with IETF IM initiatives. First of all, I would like to point out the obvious overlap in the three groups charters. As previous threads (and history) show there are a plethora of reasons for this. My goal is not to analyze how the IETF got to where it is today - but to suggest where the IETF needs to go in order to credibly meet the needs of IM vendors and enterprise users. To those of us who are knowledgeable in this field - it is patently obvious that "presence" is a capability which should become part of the intrinsic operation of the Internet AND that instant messaging is but one of many messaging / collaborative applications which can be enabled by presence. Regrettably, working group efforts to date have not separated presence from IM within their scope and goals. Although some would argue that IM is so closely related to presence that such a division does not make sense. I and my peers disagree. We suggest that presence so fundamental, far-reaching in impact, and involved technology that it deserves a working group of its own. Concomitantly, IM (and other presence-enabled applications) should then have their own separate, clearly defined working groups - which leverage advances made on the presence front. Today, to the contrary, presence is still tangled up with IM and continues to be a political football - the "ownership" of which is being contested by multiple working groups. This is "THE PROBLEM." There are those who argue that Presence is a natural extension of SIP's signaling capabilities - and thus SIP should be extended to define how presence should operate. There are those who counter that XMPP's federated presence model is sufficient for building a global presence infrastructure. I submit there is some validity to both points of view. The problem is that there are two (or more) points of view that have not converged - and that each working group continues to bang away at BOTH presence and IM issues in its own way. And for the record - few in industry give any credibility to (IETF) platitudes that these efforts are collaborative and integrative. I submit that what is needed in the Internet is a Global Presence Architecture (GPA) which builds upon and extends all that we have learned from running DNS. What needs to be recognized in developing a GPA is that presence will act like a next generation "dial-tone" upon which a wide variety of near "real-time" applications will be built. As such, this dial-tone should be such that companies can privately employ it to serve their internal needs - as well as securely extend it between enterprises. The presumption is that such a capability must be run at carrier-class (five-nines) reliability levels - and employ a universally agreed-upon name-space and security infrastructure. Candidly, I and my peers in the industry believe that the IETF has failed to grasp this reality. Rather, the IETF seems bent on forging ahead with well-intentioned but fundamentally misdirected efforts of sincere, intelligent, hard-working volunteers. Many of us view the current state of affairs as a reflection of an IETF "face-saving" exercise - because no one has the temerity to stand up and say that defining and specifying how presence should manifest itself has been fundamentally mis-understood, mis-scoped, and mis-managed. The time has come to confront this issue candidly - lest the industry continue to be paralyzed by IETF managerial ineptitude. Presence deserves its own working group. It should start with a clean sheet of paper, and not be unduly influenced by the SIP and XMPP camps. And to the retort that key members of the IM industry should put aside their partisan issues and contribute to such a process I say, "Get your act together and they will!" Yours truly, Rob Batchelder President - Relevance ------=_NextPart_000_0001_01C348C2.2F4F7E60 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DWindows-1252"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.0.4630.0"> <TITLE>Let's fix THE PROBLEM</TITLE> </HEAD> <BODY> <!-- Converted from text/rtf format --> <P><FONT SIZE=3D2 FACE=3D"Arial">Dear IETF Contributors:</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">To this point I have refrained from = editorializing on the collective activities of the IMPP / SIMPLE / XMPP = working groups. Admittedly, I have not attended many of the IETF = meetings - or actively contributed to the working groups. = Nevertheless, I am extremely active in the IM vendor community and do = provide high level strategic counsel to the leading firms in this = field. That being said, I feel confident that I can articulate = some of their concerns with IETF IM initiatives.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">First of all, I would like to point out = the obvious overlap in the three groups charters. As previous = threads (and history) show there are a plethora of reasons for = this. My goal is not to analyze how the IETF got to where it is = today - but to suggest where the IETF needs to go in order to credibly = meet the needs of IM vendors and enterprise users.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">To those of us who are knowledgeable in = this field - it is patently obvious that "presence" is a = capability which should become part of the intrinsic operation of the = Internet AND that instant messaging is but one of many messaging / = collaborative applications which can be enabled by presence.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">Regrettably, working group efforts to = date have not separated presence from IM within their scope and = goals. Although some would argue that IM is so closely related to = presence that such a division does not make sense. I and my peers = disagree. We suggest that presence so fundamental, far-reaching in = impact, and involved technology that it deserves a working group of its = own. Concomitantly, IM (and other presence-enabled applications) = should then have their own separate, clearly defined working groups - = which leverage advances made on the presence front. </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">Today, to the contrary, presence is = still tangled up with IM and continues to be a political football - the = "ownership" of which is being contested by multiple working = groups. This is "THE PROBLEM." </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">There are those who argue that Presence = is a natural extension of SIP's signaling capabilities - and thus SIP = should be extended to define how presence should operate. There = are those who counter that XMPP's federated presence model is sufficient = for building a global presence infrastructure. I submit there is = some validity to both points of view. The problem is that there = are two (or more) points of view that have not converged - and that each = working group continues to bang away at BOTH presence and IM issues in = its own way. And for the record - few in industry give any = credibility to (IETF) platitudes that these efforts are collaborative = and integrative. </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">I submit that what is needed in the = Internet is a Global Presence Architecture (GPA) which builds upon and = extends all that we have learned from running DNS. What needs to = be recognized in developing a GPA is that presence will act like a next = generation "dial-tone" upon which a wide variety of near = "real-time" applications will be built. As such, this = dial-tone should be such that companies can privately employ it to serve = their internal needs - as well as securely extend it between = enterprises. The presumption is that such a capability must be run = at carrier-class (five-nines) reliability levels - and employ a = universally agreed-upon name-space and security infrastructure. = </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">Candidly, I and my peers in the = industry believe that the IETF has failed to grasp this reality. = Rather, the IETF seems bent on forging ahead with well-intentioned but = fundamentally misdirected efforts of sincere, intelligent, hard-working = volunteers. Many of us view the current state of affairs as a = reflection of an IETF "face-saving" exercise - because no one = has the temerity to stand up and say that defining and specifying how = presence should manifest itself has been fundamentally mis-understood, = mis-scoped, and mis-managed. </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">The time has come to confront this = issue candidly - lest the industry continue to be paralyzed by IETF = managerial ineptitude. Presence deserves its own working = group. It should start with a clean sheet of paper, and not be = unduly influenced by the SIP and XMPP camps. And to the retort = that key members of the IM industry should put aside their partisan = issues and contribute to such a process I say, "Get your act = together and they will!"</FONT></P> <BR> <P><FONT SIZE=3D2 FACE=3D"Arial">Yours truly,</FONT> </P> <BR> <P><FONT SIZE=3D2 FACE=3D"Arial">Rob Batchelder</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">President - Relevance</FONT> </P> </BODY> </HTML> ------=_NextPart_000_0001_01C348C2.2F4F7E60-- [reminder: [email protected] for non-technical discussions, please]