Jabber BOF afterthoughts

[aki . niemi]

Hi Folks,

I happened to be at the Jabber BOF, which since has turned out to be a hot topic, at 
least judging from the discussions at the IESG plenary. As far as I understood, the 
objectives of the Jabber community were, that they mainly wanted a place for the 
protocol documentation to be published, and needed some expert review and help in 
sorting out the security services for the protocol. I didn't see an overwhealming 
desire to release the control for the development of the protocol to the IETF, but I 
may have misinterpreted things.

My perhaps a rather simplistic suggestion at the BOF was that the Jabber community 
submit their protocol specifications to the IESG to be published as Informational 
RFCs. After an addmittedly quick skim through the I-Ds, in my opinion they seemed to 
describe a pretty mature protocol which arguably works. And my understanding of the 
IETF process has also been that the IESG does commit to a fairly thorough review for 
even documents intended as Informational, i.e., give expert review, possibly referring 
to relevant WGs in the process.

The answer to this suggestion at the BOF was, that the Informational would get blocked 
because of an existing IETF WG working on the same area of Instant Messaging and 
Presence. I was surprised to see that this same issue didn't seem to block a Standards 
Track approach.

Why is that? After all, the Informational RFC should work equally well for the Jabber 
community, and would even allow them to retain control for the development of the 
protocol. I understand the Internet Relay Chat is in fact Informational, but that 
doesn't seem to have hampered its adoption in the Internet. 

My point finally is, that perhaps the IETF should embrace these entrant application 
layer protocols as Informational RFCs, rather than applying the "we will assimilate 
you" paradigm to them. ;)

Cheers,
Aki  

Re: Jabber BOF afterthoughts

[Randall Gellens]

At 1:06 PM -0500 7/20/02, Pete Resnick wrote:

>  Anyway, given that they actually want to get work done under the
> auspices of the IETF, I see no justification for turning them away.

Given that this is a deployed product, I tend to agree.  The work is
going to get done; we may as well help it to get done as well as
possible.

Re: Jabber BOF afterthoughts

[Randy Bush]

>> Anyway, given that they actually want to get work done under the
>> auspices of the IETF, I see no justification for turning them
>> away.
> Given that this is a deployed product, I tend to agree.  The work
> is going to get done; we may as well help it to get done as well
> as possible.

i have no useful knowledge or opinion on the actual technical
subject, so my points may already have been answered.  but the
reasons given above seem sufficient to put us in the paperclip
standards making business.  i submit that relevance, expertise,
non-conflict with other standards groups, change control, etc. are
important criteria.

randy

Re: Jabber BOF afterthoughts

[Dave Crocker]

At 08:18 AM 7/23/2002 -0700, Randy Bush wrote:
> >> Anyway, given that they actually want to get work done under the
> >> auspices of the IETF, I see no justification for turning them
> >> away.
> > Given that this is a deployed product, I tend to agree.  The work
> > is going to get done; we may as well help it to get done as well
> > as possible.
>
>  but the
>reasons given above seem sufficient to put us in the paperclip
>standards making business.


Indeed.

Proven technical base, motivated workers and ready market for products 
using a specification.

Those certainly are a lousy basis for forming an IETF working group.

d/

--
Dave Crocker 
TribalWise, Inc. 
tel +1.408.246.8253; fax +1.408.850.1850

Re: Jabber BOF afterthoughts

[Pete Resnick]

On 7/23/02 at 8:18 AM -0700, Randy Bush wrote:

>>>Anyway, given that they actually want to get work done under the 
>>>auspices of the IETF, I see no justification for turning them away.
>>Given that this is a deployed product, I tend to agree.  The work 
>>is going to get done; we may as well help it to get done as well as 
>>possible.
>
>i have no useful knowledge or opinion on the actual technical 
>subject, so my points may already have been answered.  but the 
>reasons given above seem sufficient to put us in the paperclip
>standards making business.  i submit that relevance, expertise, 
>non-conflict with other standards groups, change control, etc. are 
>important criteria.

I certainly agree that relevance, expertise, change control, etc. are 
important criteria for the IESG to review. I believe a review of the 
discussion here and the minutes of the BOF session will reveal that 
each of those criteria are well met: This is an application protocol 
deployed on the Internet, folks with the relevant expertise in the 
Jabber community and in the IETF community have expressed the desire 
to work on the problems with the protocol, and none of them are 
asserting the desire to have change control lie anywhere but within 
the IETF.

However, I'm not clear why "non-conflict with other standards groups" 
is a criteria. Care to explain?

pr
-- 
Pete Resnick 
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Re: Jabber BOF afterthoughts

[Randy Bush]

 Anyway, given that they actually want to get work done under the
 auspices of the IETF, I see no justification for turning them
 away.
>>> Given that this is a deployed product, I tend to agree.  The work
>>> is going to get done; we may as well help it to get done as well
>>> as possible.
>> but the reasons given above seem sufficient to put us in the paperclip
>> standards making business.
> Proven technical base, motivated workers and ready market for products 
> using a specification.
> Those certainly are a lousy basis for forming an IETF working group.

you have an impressive talent for omitting text, twisting people's
words, etc.  you should run for political office.

i also said

>> i submit that relevance, expertise, non-conflict with other
>> standards groups, change control, etc. are important criteria.

randy

Re: Jabber BOF afterthoughts

[Randy Bush]

> I certainly agree that relevance, expertise, change control, etc. are 
> important criteria for the IESG to review. I believe a review of the 
> discussion here and the minutes of the BOF session will reveal that 
> each of those criteria are well met

cool!

> However, I'm not clear why "non-conflict with other standards groups" 
> is a criteria. Care to explain?

sure.  i'll even do it for free!  :-)

we don't make ethernet standards, ieee does.  we don't make sdh
standards, itu does.  etc. etc.  in this case, i would be careful
not to encroach on w3's toes.  i have no idea if we would be or
not.

as to why we are careful not to step on other sdos' toes, well we
do not want them to step on ours.  there have been incidents of
this kind of issue with other sdos, and we try to be careful.  make
sense?

randy

Re: Jabber BOF afterthoughts

[Dave Crocker]

At 10:01 AM 7/23/2002 -0700, Randy Bush wrote:
> > Proven technical base, motivated workers and ready market for products
> > using a specification.
> > Those certainly are a lousy basis for forming an IETF working group.
>
>you have an impressive talent for omitting text, twisting people's
>words, etc.  you should run for political office.
>
>i also said
>
> >> i submit that relevance, expertise, non-conflict with other
> >> standards groups, change control, etc. are important criteria.

Randy,

Thanks for the ad hominem.  For my own part, I had refrained from noting 
your own accomplishment at invention.

There was nothing in the note you were supposedly responding to that hinted 
at the IETF's being a rubber stamp, yet that is the interpretation that you 
chose to create for it.

And you forgot to note that besides being ignorant of the technical issues, 
you apparently had no knowledge of the process-related history of this and 
were, therefore, ignorant of the fact that all of the issues you were 
voicing concern about had been addressed quite thoroughly.

Yet still you chose to post such a constructive, informed note.

Silly me, I thought area directors were expected to be careful about their 
activities concerning a matter they will be expected to pass judgement on, 
especially one about which there has already been such stellar, public IETF 
process achievement.

d/


--
Dave Crocker 
TribalWise, Inc. 
tel +1.408.246.8253; fax +1.408.850.1850

Re: Jabber BOF afterthoughts

[Randy Bush]

thanks for your ever-constructive contribution dave.

for actual content, see my conversation with pete.

randy

Re: Jabber BOF afterthoughts

[Graham Klyne]

At 08:18 AM 7/23/02 -0700, Randy Bush wrote:
>...  i submit that relevance, expertise,
>non-conflict with other standards groups, change control, etc. are
>important criteria.

Mostly, that seems quite reasonable.  But I'm interested to understand what 
constitutes "non conflict" here.

#g


---
Graham Klyne
<[EMAIL PROTECTED]>

Re: Jabber BOF afterthoughts

[Randy Bush]

> Mostly, that seems quite reasonable.  But I'm interested to understand
> what constitutes "non conflict" here.

was my reply to pete on this sufficiently helpful?  if not, i will
beg the help of our sdo lawyers like scott, so you had better be
happy with what i said :-).

sometimes we have X come to us to move their work through our
process after they have not gotten what they wanted from the more
appropriate sdo.  so, if we were to take it on, we could be badly
stepping on someone else's turf.  what goes around comes around,
and we don't want sdo turf wars.  do we want itu to 'help' with
smtp?

i have no idea if this is an issue here, as i am not in contact
with w3c or whomever else.  i expect you, pete, etc. will know far
better than i if we are nearing hot water here.  i am just asking
you to please be conscious of the issue.

fwiw i have nothing against jabber.  some of my best friends jabber
:-).  i am even trying to get a secure jabber server working (and
am hitting problems).  i am just concerned about process and
precedent.

randy

Re: Jabber BOF afterthoughts

[John Stracke]

Randy Bush wrote:

>we don't make ethernet standards, ieee does.  we don't make sdh
>standards, itu does.  etc. etc.  in this case, i would be careful
>not to encroach on w3's toes.
>  
>
What would Jabber have to do with the W3C? It's a protocol, not a 
document format.  Furthermore, we already have two efforts in this 
space; if the W3C were likely to object, they would've by now.

-- 
/\
|John Stracke|Principal Engineer |
|[EMAIL PROTECTED]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
||
|This is the .sig that says... Ni!   |
\/

Re: Jabber BOF afterthoughts

[Marshall Rose]

randy - hi. i'm a little confused about the exchanges this morning, so bear
with me.


> i have no idea if this is an issue here, as i am not in contact
> with w3c or whomever else.  i expect you, pete, etc. will know far
> better than i if we are nearing hot water here.  i am just asking
> you to please be conscious of the issue.

this is a fair point. there is no w3c effort on instant messaging, while
soap is certainly a w3c effort, i think most folks would be hard-pressed to
find much overlap between it and jabber, other than the fact that they both
use xml at different points in their stack.


> fwiw i have nothing against jabber.  some of my best friends jabber
> :-).  i am even trying to get a secure jabber server working (and
> am hitting problems).  i am just concerned about process and
> precedent.

send me a private note explaining the difficulty, and maybe i can help.

/mtr

Re: Jabber BOF afterthoughts

[Randy Bush]

> On this point I'm in total agreement with Randy ... I've still have a 
> problem with this ...why come to IETF with this work ?

note that i do not have the expertise to have a position on this
with respect to jabber.  this whole sub-thread was really my
*process* reaction to randall's

> Given that this is a deployed product, I tend to agree.  The
> work is going to get done; we may as well help it to get done
> as well as possible.

being quite unbounded.  and i suggested some bounds

> relevance, expertise, non-conflict with other standards
> groups, change control, etc. are important criteria.

i was merely raising a formal process issue, and not necessarily an
issue i have with jabber per se.

> it is perfectly reasonable to kill off or delay WG charting
> because of the current IESG work load, especially in the
> applications area.

i don't buy this.  if the wannabe-wg is appropriate ietf work, the
folk are there with their homework done and ready to roll, the
drafts are in play with change control in the ietf, there is an
active constructive mailing list, and a charter is close to being
good, then iesg load is no excuse.  if this is a problem, then we
need to, and will, fix it.

randy

Re: Jabber BOF afterthoughts

[Randy Bush]

>> we don't make ethernet standards, ieee does.  we don't make sdh
>> standards, itu does.  etc. etc.  in this case, i would be careful
>> not to encroach on w3's toes.
> What would Jabber have to do with the W3C? It's a protocol, not a 
> document format.  Furthermore, we already have two efforts in this 
> space; if the W3C were likely to object, they would've by now.

i do not know how much clearer i could be than

>> i have no idea if this is an issue here, as i am not in contact
>> with w3c or whomever else.  i expect you, pete, etc. will know
>> far better than i if we are nearing hot water here.  i am just
>> asking you to please be conscious of the issue.

randy

Re: Jabber BOF afterthoughts

[Pete Resnick]

On 7/23/02 at 10:09 AM -0700, Randy Bush wrote:

>we don't make ethernet standards, ieee does.  we don't make sdh 
>standards, itu does.  etc. etc.

Ah, you're talking about competing with other standards bodies, not 
groups within the IETF! OK, that I understand.

>in this case, i would be careful not to encroach on w3's toes.  i 
>have no idea if we would be or not.

Everything that I've seen indicates nothing in any of the potential 
work items which would step on any W3C toes. So I think Jabber is 
cool there too.

>as to why we are careful not to step on other sdos' toes, well we do 
>not want them to step on ours.  there have been incidents of this 
>kind of issue with other sdos, and we try to be careful.  make sense?

Absolutely.

pr
-- 
Pete Resnick 
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Re: Jabber BOF afterthoughts

[Graham Klyne]

At 10:43 AM 7/23/02 -0700, Randy Bush wrote:
>fwiw i have nothing against jabber.  some of my best friends jabber
>:-).  i am even trying to get a secure jabber server working (and
>am hitting problems).  i am just concerned about process and
>precedent.

In the IETF that I know, the issue is not so much one of process and 
precedent, but core competence.  And if that isn't clear, or is distributed 
across organizations, there are plenty of examples of collaborative efforts.

#g


---
Graham Klyne
<[EMAIL PROTECTED]>

Re: Jabber BOF afterthoughts

[Richard Shockey]

>
>sometimes we have X come to us to move their work through our
>process after they have not gotten what they wanted from the more
>appropriate sdo.  so, if we were to take it on, we could be badly
>stepping on someone else's turf.  what goes around comes around,
>and we don't want sdo turf wars.  do we want itu to 'help' with
>smtp?

On this point I'm in total agreement with Randy ... I've still have a
problem with this ...why come to IETF with this work ?... this is XML
messaging ...why didnt the Jabber community choose OASIS or W3C..which
strikes me as a more logical home for these kind of things and there is a
larger community of XML expertise there.

Just because there is a community that has a good idea and wants to work on
it does not mean the IETF should take it on.  Randy is right about process
and precedent. we kill off BOF's all the time for any number of
irrational reasons even when there is a strongly committed core or people
willing to work the issue. And, contrary to popular opinion,  it is
perfectly reasonable to kill off or delay WG charting because of the
current IESG work load, especially in the applications area.

That said ..at the BOF the Jabber folks remarked and I pointed out that
there may be a larger issue of asynchronous XML messaging that may or may
not have relevance in the IETF.  Patrik's comments at the plenary were
quiet appropriate that we are beginning to deal with lots of XML things and
how we move these things around and where these fit into the general IETF
view of Architecture is rather relevant.

Jabber MAY or MAY NOT be part of that ..I don't know and I say that as a
certifiable SIP bigot and on that basis I'm personally willing to keep a
open mind on the issue.

I'm still trying to discover how Jabber might be complimentary to SIMPLE in
much the same way IMAP is complementary to POP3. ( ok maybe a bad analogy).

But I wish that those proponents of a Jabber WG would understand that some
of us in the SIP community have some real concerns about the effect or
perceptions in the marketplace that chartering this work in the IETF might
have. They are real and probably cloud our thinking ..but simply dismissing
them as irrelevant or stupid is not going to help gain consensus on
chartering this work.

I'll be real blunt here the difference between asynchronous XML messaging
and asynchronous XML signalling is really fine and that really worries me.

>fwiw i have nothing against jabber.  some of my best friends jabber
>:-).

ditto ...blabber, slobber depending on time of day..

>i am even trying to get a secure jabber server working (and
>am hitting problems).  i am just concerned about process and
>precedent.




 >
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8 Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
 or



<

Re: Jabber BOF afterthoughts

[Marshall Rose]

[ lots of stuff deleted that was designed to distract... ]

> But I wish that those proponents of a Jabber WG would understand that some
> of us in the SIP community have some real concerns about the effect or
> perceptions in the marketplace that chartering this work in the IETF might
> have. They are real and probably cloud our thinking ..but simply
dismissing
> them as irrelevant or stupid is not going to help gain consensus on
> chartering this work.

richard - whether simple succeeds or fails will have nothing to do with
whether the ietf helps out the jabber folks. each will succeed or fail on
their own merits.

i am at a loss to understand the extraordinary amount of fear and loathing
from the simple camp that i witnessed in the jabber bof. i could be more
unkind here, but i'm making an extraordinary effort to be inoffensive.

regardless, there are numerous precedents to invalidate your position that
we can work on only one. the most obvious is cpim, which explicitly
acknowledges the existence of many.

however, if you insist that there can be only one, then perhaps the logical
thing to do is for the iesg to put eveything on hold while we do a detailed
analysis of the technical merits of the various approaches.

oh, wait, we already did that, and the result was that we did cpim. go back
two paragraphs.

for myself, i think that the simple folks would be much better served by
focusing on their work product than on political posturing.

/mtr

Re: Jabber BOF afterthoughts

[Valdis . Kletnieks]

On Tue, 23 Jul 2002 23:21:40 BST, Lloyd Wood said:

> XML! XML! it's XML! whatever happened to Java?

Any hammer, once it's used for pounding enough screws and bolts, starts
looking rather dented and abused.  The obvious solution is to buy an new
bright shiny hammer with which to pound screws and bolts.

(Note - I think XML and Java are both *wonderful* for certain tasks - but
if there's anything I've learned in 20+ years of this, it's that *nothing*
is The Next Great Thing To Fix Everything)
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg08899/pgp0.pgp
Description: PGP signature

Re: Jabber BOF afterthoughts

[John Stracke]

Richard Shockey wrote:

> this is XML
> messaging ...why didnt the Jabber community choose OASIS or W3C..which
> strikes me as a more logical home for these kind of things and there is a
> larger community of XML expertise there. 

But using XML is not the hard part.  Using XML is nearly trivial; it's 
just an encoding.  Protocols are hard, and that's where the IETF has 
expertise.

-- 
/\
|John Stracke|Principal Engineer |
|[EMAIL PROTECTED]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
||
|This is the .sig that says... Ni!   |
\/

RE: Jabber BOF afterthoughts

[Peterson, Jon]

I believe that the industry, the press and even some governments have
consistently looked to the IETF to produce a single standard for instant
messaging and presence precisely because IM&P is an unusually balkanized
application on the Internet - unlike email and the web and so on instant
messaging is carried mostly by proprietary protocols; it grew up as a
product rather than an interoperable standard. It would be nice if we were
part of the solution rather than part of the problem.

Starting from the idealistic conceit that we could eventually arrive at
consensus on one IM&P protocol, the IETF went through a lengthy, bitter
process (echoes of which were the root cause of much of the ugliness at the
Jabber BoF) to arrive eventually at CPIM - which was a significant
accomplishment - and three competing WGs that were CPIM-compliant. By most
measures SIMPLE has been more successful than the other children of IMPP,
and for that reason many outside consortia and major companies that
previously espoused proprietary solutions have adopted a direction towards
SIMPLE as the product of the IETF's attempt to standardize instant
messaging. I don't think it is unreasonable to suggest that chartering a new
WG today that competes directly with SIMPLE would be taken by many to mean
that the IETF still has not arrived at a workable solution (and no doubt
some proponents of XMPP feel that to be the case). Will other protocols
that, like Jabber, did not advance to WG status after the selection process
in July of 2000 in IMPP (there were 15, IIRC) also come forward now
requesting their own WGs? Should the IESG have chosen 7 IMPP child WGs to go
forward instead of 3?

All that said, I actually support the chartering of an XMPP WG, but I would
prefer that it adopt a charter that is not just a "me too" for IM&P
(competing directly with APEX, SIMPLE and PRIM) but rather one that focuses
on unique competencies of the Jabber approach. Chartering something along
the lines of general XML transport, as was discussed at the Jabber BoF,
could be quite complementary to SIP, SIMPLE and no doubt many other groups
in the IETF, and this would most certainly satisfy the goal of "helping
Jabber out". In any event, I doubt that chartering a fifth (!) currently
active working group specifically focused on IM&P is likely to shed much new
light on the problem.

Jon Peterson
NeuStar, Inc.
(admittedly) SIMPLE co-chair

> -Original Message-
> From: Marshall Rose [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 23, 2002 4:55 PM
> To: Richard Shockey
> Cc: [EMAIL PROTECTED]; Marshall Rose
> Subject: Re: Jabber BOF afterthoughts
>
>
> [ lots of stuff deleted that was designed to distract... ]
>
> > But I wish that those proponents of a Jabber WG would
> understand that some
> > of us in the SIP community have some real concerns about
> the effect or
> > perceptions in the marketplace that chartering this work in
> the IETF might
> > have. They are real and probably cloud our thinking ..but simply
> dismissing
> > them as irrelevant or stupid is not going to help gain consensus on
> > chartering this work.
>
> richard - whether simple succeeds or fails will have nothing
> to do with
> whether the ietf helps out the jabber folks. each will
> succeed or fail on
> their own merits.
>
> i am at a loss to understand the extraordinary amount of fear
> and loathing
> from the simple camp that i witnessed in the jabber bof. i
> could be more
> unkind here, but i'm making an extraordinary effort to be inoffensive.
>
> regardless, there are numerous precedents to invalidate your
> position that
> we can work on only one. the most obvious is cpim, which explicitly
> acknowledges the existence of many.
>
> however, if you insist that there can be only one, then
> perhaps the logical
> thing to do is for the iesg to put eveything on hold while we
> do a detailed
> analysis of the technical merits of the various approaches.
>
> oh, wait, we already did that, and the result was that we did
> cpim. go back
> two paragraphs.
>
> for myself, i think that the simple folks would be much
> better served by
> focusing on their work product than on political posturing.
>
> /mtr
>
>

Re: Jabber BOF afterthoughts

[Richard Shockey]

A
>regardless, there are numerous precedents to invalidate your position that
>we can work on only one. the most obvious is cpim, which explicitly
>acknowledges the existence of many.

Understood.. but Marshall I never wrote there should only be one. I am
keeping a open mind on this as I noted in my previous message. I just have
reasonable concern, as a SIP bigot, that multiple IM/P protocols coming out
of the IETF could cause confusion in the market and that would be a bad
thing for IM/P in general. I could be wrong.

The contrary argument, of course, is that the SIP architecture of uniting
multiple forms of real-time communications is so inherently powerful that
it can withstand any competing approach.


>however, if you insist that there can be only one, then perhaps the logical
>thing to do is for the iesg to put eveything on hold while we do a detailed
>analysis of the technical merits of the various approaches.

Again ... I'm not dismissing the idea of working on Jabber ..ist just that
there may be some larger issues here  surrounding the general case of XML
transport as we discussed at the BOF and  Patrik raised in the plenary.

Pete asked at the BOF ..."well could you support the work if it was part of
a larger effort on XML transport"  Well my answer to that is yes.


>for myself, i think that the simple folks would be much better served by
>focusing on their work product than on political posturing.

Well I suspect we are much closer to agreement than you might imagine and I
wholeheartedly agree with the comments posted by my colleague Jon Peterson
on the matter...and after all he is the co-chair of SIMPLE.


>/mtr


 >
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8 Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
 or



<

RE: Jabber BOF afterthoughts

[Dave Crocker]

At 09:49 PM 7/23/2002 -0400, Peterson, Jon wrote:
>I believe that the industry, the press and even some governments have
>consistently looked to the IETF to produce a single standard for instant
>messaging and presence precisely because IM&P is an unusually balkanized
>application on the Internet

Jon (et al)

The IETF does technical work.  It does not do marketing work.  We let the 
market do marketing work.

The primary criteria for doing work in the IETF are:

 - our having adequate technical competence for the task

 - the proposed work having adequate clarity and feasibility

 - a sufficient pool of people willing to work on it

 - a reasonable indication that there will be suppliers of the result

 - some indication that there will be consumers of the result

All of these conditions are satisfied by Jabber, pending a working group 
charter that is clear, tight and practical.  I'm not too worried about the 
charter satisfying these requirements.

When the IETF tries to stifle competition, it usually does a bad job all 
around.

When the IETF tries to listen to "market" factors with any more subtlety 
than "there appear to be some ready suppliers and consumers of the work" 
then it usually does a bad job.

Sometimes, yes, the IETF stifles competition, but the only times it does 
that constructively is when there is a good technical basis.  Otherwise, it 
lets the work of the constituencies and the reaction of the market do the 
filtering.

The IETF has been working on IM&P for 4 years.  You may have noticed that 
the balkanization of the IM&P world has not been reduced after all that 
time.  One might even take the recent AOL announcement that it is backing 
off from interoperability efforts as a good indication of just how bad the 
situation remains.


>Starting from the idealistic conceit that we could eventually arrive at
>consensus on one IM&P protocol, the IETF went through a lengthy, bitter
>process (echoes of which were the root cause of much of the ugliness at the
>Jabber BoF) to arrive eventually at CPIM

and we should all remember that CPIM represents a very explicit 
acknowledgement that there are -- and will be -- multiple IM&P protocols.


>- which was a significant
>accomplishment - and three competing WGs that were CPIM-compliant. By most
>measures SIMPLE

In terms of my own understanding of IETF culture, priorities and rules, 
with respect to the Jabber initiative, the accuracy of your assessment is 
frankly irrelevant.  And the failure to recognize that it is irrelevant is 
the core of the problem with the misbehavior by a number of SIMPLE 
advocates.


>  I don't think it is unreasonable to suggest that chartering a new
>WG today that competes directly with SIMPLE would be taken by many to mean
>that the IETF still has not arrived at a workable solution (and no doubt

People often choose to interpret things in a way that has nothing to do 
with reality.  Another thing the IETF does very badly is try to 
second-guess inaccurate interpretations of things.  For that matter, most 
people outside the IETF do that rather badly too.

d/

--
Dave Crocker 
TribalWise, Inc. 
tel +1.408.246.8253; fax +1.408.850.1850

Re: Jabber BOF afterthoughts

[Jeremie]

> I happened to be at the Jabber BOF, which since has turned out to be a
> hot topic, at least judging from the discussions at the IESG plenary.
> As far as I understood, the objectives of the Jabber community were,
> that they mainly wanted a place for the protocol documentation to be
> published, and needed some expert review and help in sorting out the
> security services for the protocol.

A simple misunderstanding: they are some of the motivations, but not the
main ones.  We "mainly" want to keep the protocol from fragmenting into
disarray, diverging implementations, lack of agreeance, poorly
implemented/upgraded security additions as they come along, just all
around poor support for a multi-domain multi-use protocol, where that poor
support can directly impact the effectiveness and usability of other parts
of the network.

> I didn't see an overwhealming desire to release the control for the
> development of the protocol to the IETF, but I may have misinterpreted
> things.

I never got my chance at the mic to explain my viewpoint on this.  The
protocol is based on namespaces, and the JSF is primarily a forum where
people create NEW namespaces, which is as separate from HTTP as is new
content types served over it.  There is very little activity in the JSF
around the core protocol, nor has there been any "change control" asserted
beyond independently updated software releases.  The "core" protocol, that
primarily documented best by the drafts, isn't controlled by anyone at
this point, you could say the JSF is the closest, but it has not taken
that role.

Again, we're coming to the IETF because we *need* a strong and
proven process for managing this important layer in the Jabber
architecture.  We're not giving up any control, we simply don't have it.

> My perhaps a rather simplistic suggestion at the BOF was that the
> Jabber community submit their protocol specifications to the IESG to
> be published as Informational RFCs. After an addmittedly quick skim
> through the I-Ds, in my opinion they seemed to describe a pretty
> mature protocol which arguably works. And my understanding of the IETF
> process has also been that the IESG does commit to a fairly thorough
> review for even documents intended as Informational, i.e., give expert
> review, possibly referring to relevant WGs in the process.

Another angle on the same theme: it's not the documents or publications
themselves that help force consensus and stabilize a growing-unwieldy
network protocol, it's the process of involving all the interested parties
in a WG to iron out issues from their varied perspectives and having
control of the protocol exist in the hands of a recognized standards body.

I didn't say it very clearly at the BOF, but the reason we weren't doing
this two years ago was because we didn't care about the protocol (our
focus has always been open interoperability and accessibility), and had
the expectation that anything the IMPP could come up with would be a
superset of what we had and we could migrate to it, after all the IMPP
architecture descriptions were almost identical to Jabber.

That didn't happen, there is no protocol with comparable characteristics,
and now we're faced with the popularity of our own protocol and the
implications of new quasi-implementations on the network when nobody has
the ability to say or enforce anything.

> Why is that? After all, the Informational RFC should work equally well
> for the Jabber community, and would even allow them to retain control
> for the development of the protocol. I understand the Internet Relay
> Chat is in fact Informational, but that doesn't seem to have hampered
> its adoption in the Internet.

Funny that you should mention IRC, that's exactly what we're trying to
avoid, a protocol full of problems and holes with only patchwork fixes and
"get a better implementation" solutions to work around it's deficiencies,
and numerous extensions that aren't exactly optimal :)

Jer

RE: Jabber BOF afterthoughts

[Harald Tveit Alvestrand]

--On 23. juli 2002 21:49 -0400 "Peterson, Jon" <[EMAIL PROTECTED]> 
wrote:

> I don't think it is unreasonable to suggest that chartering a new
> WG today that competes directly with SIMPLE would be taken by many to mean
> that the IETF still has not arrived at a workable solution (and no doubt
> some proponents of XMPP feel that to be the case).

I think the single step most useful to stem this perception is to get the 
CPIM documents out the door and published, have at least one IM-transport 
protocol publish its interface to CPIM, and having running code that proves 
that the resulting functionality is in fact useful.

Pair of facts beats house of prediction.

Harald