Subject: RE: WG Review: Centralized Conferencing (xcon)

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 14 Aug 2003 15:28:51 -0400

[snip]
> > 
> > Description of Working Group:
> > 
> > ...
> > 
> > Initially this combination of protocols will be specified with respect
> > to session setup with SIP. The solutions developed in XCON will not
> > preclude operation with other signaling protocols; however it is
> > anticipated that the use of other protocols would require modifications
> > which are out of scope for this working group.
> > 
> > None of the protocols defined by this group will be SIP, although the
> > SIP specific event notification framework will be used. The group will
> > use the high-level requirements and framework already described by
documents
> > published by the SIPPING WG.
> 
> may i inquire as to why this working group is SIP-specific? or more
> accurately, why does this charter say it isn't SIP-specific, when the
> contrary is true.

Well, from my perspective, the first paragraph cited above does indeed
indicate that this work is oriented towards SIP, that adapting the work for
some other protocol would entail changes to the model, and that those
changes won't be considered in the proposed WG. So while one might be
concerned by the fact that XCON is SIP-specific, I don't believe the charter
is especially disingenuous about that.

As to why this proposed WG is more or less SIP-specific, the charter arises
from a set of framework, requirements and mechanism documents that were
proposed in SIPPING. It was broken out from SIPPING because the community of
interest in conferencing seemed diverse (and prolific) enough that the work
seemed to merit its own WG. Also, the security responsibilities of
conference administration require some pretty low-level selections for media
stream security, and so on, that almost necessarily make this work specific
to some set of underlying technologies.

If it turns out that the products of the group do happen to be useful in
other areas, all the better.

>     
> for example, in the xmpp commuinity, there's a robust and
> well-implemented specification for "multi-user chat" which arguably
> provides a superset of the proposed xcon work product (cf.,
> http://www.jabber.org/jeps/jep-0045.html)
>     

If this specification is a superset of the proposed work, then it should
serve as input to the group, yes (though obviously, it's a little easier for
IETF participants to work with Internet-Drafts - the status of that document
is a little unclear to me). I'm sure the group would love to be able to
declare victory at the outset. During the comment period on this charter, we
have already received a couple of notifications of existing work that is
potentially serviceable (including one from the MSEC WG). Conferencing is
certainly not a new problem; there's considerable existing work in this
space both inside the IETF and elsewhere. 

XCON would no doubt welcome participation from any members of the XMPP
community.

Jon Peterson
NeuStar, Inc.

> if the proposed working group is going to develop something for SIP,
> then the charter should say so.
>     
> if the proposed working group is going to develop something
general-purpose,
> then the charter should reflect reality by requiring an evaluation of
> existing solutions to this space, as is usual for working groups that
> are not starting with an existing specification...
>     
> thanks!
>     
> /mtr
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 14 Aug 2003 14:47:00 -0700

Jon,

PJ> So while one might be
PJ> concerned by the fact that XCON is SIP-specific, I don't believe the charter
PJ> is especially disingenuous about that.

On the other hand, it declares a statement of intended design constraint
(being sip oriented) but provides no indication of what that means or
why it is being chosen. As such, it is not possible to evaluate that
choice.

Given that a working group charter is a contract for work to be done,
the contract needs to specify its constraints in a way that provides
helpful detail.

PJ> As to why this proposed WG is more or less SIP-specific, the charter arises
PJ> from a set of framework, requirements and mechanism documents that were
PJ> proposed in SIPPING.

Working groups that are chartered with documented constraints are
expected to cite those documents. If there is a body of prior work, on
which this working group is being offered as a continuation, then a
person reading the charter needs to be able to review that work.

Otherwise it is very difficult for a public review of the charter to be
based on anything substantial.

If there is no documentation for the constraints, then there is no
substantial basis for imposing them, other than perhaps citing some
concerns or perspectives.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: "Marshall Rose" <[email-masked]>
Date: Tue, 19 Aug 2003 15:29:02 -0700

jon - sorry for the delay in replying.

fundamentally, i think it comes down to accuracy in labelling. if the sip
folks want to do conferencing, then they should have a working group to do
that. however, the charter for that working group should not imply that the
scope of the working group is anything beyond sip.

a reasonable person reading the charter would conclude that the scope of the
working group is somewhat more generic than sip.

if the goal for this working group is to be generic, then the charter is
likely unacceptable since it assumes "facts not entered into evidence",
i.e., it is sip-centric, and there is a fair body of deployed work that
manages to do conferencing very well without using that acronym. if that is
not the intention, then  i suggest that the working group be called
something like sipxcon to avoid any confusion.

as to whether the working group belongs in apps or tsv, a generic
conferencing working group clearly belongs in apps. however, a sip-specific
working group can probably comfortably reside in either.

/mtr

---

From: "vinton g. cerf" <[email-masked]>
Date: Wed, 20 Aug 2003 08:38:34 -0400

As a prospective supplier of SIP-based services, I am very interested in seeing SIP-based definitions for the support of a wide range of conferencing tools ranging from voice/video to IM and mixtures that might include a participant with only a phone and a fax machine. This is not to say that I would reject other protocol bases for such service but rather to say that we have a significant investment in SIP-based services and would like to see them expanded in standard ways so as to encourage interworking among parties offering such services. 

I leave it to the IESG and other interested parties to figure out how best to achieve that objective. Perhaps a SIP-oriented WG is the appropriate vehicle, recognizing that what ever procedures are invented, rooted in the SIP system, might well have counterparts in other signalling enviroments and could therefore be re-incarnated in them. Whether that would confer interworking between the SIP and non-SIP systems is beyond my ability to predict. 

Vint

>working group can probably comfortably reside in either.

Vint Cerf
SVP Architecture & Technology
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 20 Aug 2003 08:33:44 -0500

Given the IM background in this discussion, I fail to see why there should
be an IM-originated conferencing option to confuse everyone, when SIP
conferencing is supporting all types of media and presence and IM just as
well (plus events, user preferences, mobility etc.) in a consistent way.

It is high time the IETF should get its act together and converge on the one
single multiparty (conferencing!) multimedia session protocol: SIP. And
avoid such confusions as Marshall does in the attached.

Look at the huge penetration of SIP with wired and mobile service providers,
as well as on tens of millions of desktops: The IETF SIP work is already the
de facto standard. Let's just stay focused.

It is thus entirely appropriate XCON should be a SIP oriented WG for
centralized conferencing.

Thanks,

Henry Sinnreich
MCI

> -----Original Message-----
> From: vinton g. cerf [mailto:[email-masked]]
> Sent: Wednesday, August 20, 2003 7:39 AM
> To: Marshall Rose; Peterson, Jon
> Cc: [email-masked]
> Subject: Re: WG Review: Centralized Conferencing (xcon)
> 
> As a prospective supplier of SIP-based services, I am very interested in
> seeing SIP-based definitions for the support of a wide range of
> conferencing tools ranging from voice/video to IM and mixtures that might
> include a participant with only a phone and a fax machine. This is not to
> say that I would reject other protocol bases for such service but rather
> to say that we have a significant investment in SIP-based services and
> would like to see them expanded in standard ways so as to encourage
> interworking among parties offering such services.
> 
> I leave it to the IESG and other interested parties to figure out how best
> to achieve that objective. Perhaps a SIP-oriented WG is the appropriate
> vehicle, recognizing that what ever procedures are invented, rooted in the
> SIP system, might well have counterparts in other signalling enviroments
> and could therefore be re-incarnated in them. Whether that would confer
> interworking between the SIP and non-SIP systems is beyond my ability to
> predict.
> 
> Vint
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Aug 2003 19:43:08 -0400

> single multiparty (conferencing!) multimedia session protocol: SIP. 

Why in the world should IETF bias a conferencing solution toward the telephony
providers?  I mean, if SIP turned out to be a good solution for everyone, fine.
But the group shouldn't assume a priori that SIP is the right direction.

---

From: Richard Shockey <[email-masked]>
Date: Wed, 20 Aug 2003 20:31:10 -0400

>But the group shouldn't assume a priori that SIP is the right direction.

Keith with all due respect ..first I would not charactize SIP as having a 
bias towards telephony providers, far from it. Its now supported by a truly 
staggering list of software developers and service providers who may or may 
not have associations with the incumbent global TDM regime including 
Microsoft, Lotus/IBM, and open source providers such as iptel.org 
increasing support from Apple and I suspect AOL as well.

I think the XCON folks were trying to be inclusive in their charter 
development but frankly I don't think its necessary. The IETF now has three 
SIP related WG's operating well and producing good work and the scope of 
the XCON proposal IMHO should be directed at SIP specifically. Its a 
complex issue, there is a real problem statement and a focused WG could 
tackle the problem head on and deliver results. This was the direction we 
took with SIPPING for the specific IM problem and its what we need to do 
with SIP Conferencing.

Most sincerely,

sip:[email-masked]

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Aug 2003 21:07:38 -0400

> SIP may have been initially motivated by telephony style applications but it
> is a very general and extensible negotiation protocol - it was that aspect
> that grabbed my attention when I first heard about Schulzrinne's work on it
> several years ago. I think the point really is that SIP is extensible and
> may be a very reasonable platform on which to build a wide range of peer to
> peer and distributed application control.

SIP certainly is extensible, but I strongly suspect that we wouldn't be giving
it serious consideration for this use if there weren't already a substantial
investment in it from the telephony world.  What makes sense for telephone
providers (because of that investment) doesn't necessarily make sense for the
Internet.  SIP should of course be considered, but it shouldn't be assumed as
part of the solution path before the WG has even had a chance to consider
other, possibly less complex, alternatives.

Keith

---

From: Marshall Rose <[email-masked]>
Date: Wed, 20 Aug 2003 18:07:08 -0700

> took with SIPPING for the specific IM problem and its what we need to do 

richard - unfortunately, this isn't what the proposed charter says or
intends. 
    
i'll repeat what i've said twice before, but i'll use different words:
    
    if the sip folks want to have a working group to work on
    sip-specific conferencing, fine. we can judge the charter on its
    merits in the context of sip.
    
    the xmpp folks have a workable, deployed solution in the
    conferencing space. if they decide to take this work to the ietf,
    then that should also be accorded the same courtesy in being judged
    on its merits in the context of xmpp.
    
    the proposed charter (and jon's clarifications) have a considerably
    larger scope than doing sip-specific conferencing. further, it is
    disingenuous to say that other perspectives will be considered,
    because, to paraphrase sinnreich: "there is but one god, and it's
    name is sip".
    
so, as much as i enjoy these little skirmishes, i repeat my call for
peace:
    
    tailor the proposed charter so that it limits itself to sip-specific
    conference, and no one outside of the sip community will much care...
    
/mtr

---

From: Richard Shockey <[email-masked]>
Date: Wed, 20 Aug 2003 21:29:20 -0400

>richard - unfortunately, this isn't what the proposed charter says or

I know .. we are in total agreement the charter needs to be rewritten and 
more specific. Though again though I have no direct knowledge of the 
thinking of the charter authors I do belive they felt the obligation to be 
"inclusive" of other protocols. OK maybe they were trying to be politically 
correct..I don't know.

>     merits in the context of sip.

ack and I agree that is the best approach.

>     on its merits in the context of xmpp.

IMHO yes however I would say .. if the XMPP community can contribute a 
architectural model that might be useful to SIP than I hope ..hope they 
would be willing to share such valuable insights.

>
>so, as much as i enjoy these little skirmishes

I know you do :-) and after all its the dog days of August and we all need 
a little entertainment from time to time.  I've noticed we have'nt had a ID 
and ASCII debate in a while..

>, i repeat my call for

That very reasonable.

My very best wishes ..

---

From: Marshall Rose <[email-masked]>
Date: Wed, 20 Aug 2003 18:07:08 -0700

/mtr

---

From: Richard Shockey <[email-masked]>
Date: Wed, 20 Aug 2003 20:31:10 -0400

Most sincerely,

sip:[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Aug 2003 19:43:08 -0400

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 21 Aug 2003 10:39:52 -0500

Leaving the SIP-XMPP discussion aside (nobody will change their mind anyway)
a matter of concern is the 100% dominance of protocol experts in this
discussion and no real participation from conference service operators and
conference platform vendors. This raises several flags...

As a participant in developing IP conference services, I have seen the
challenge of integrating IP conference technology with AAA (OSS) and with
operator support services.

In this light, I believe we need to start with generic requirements for XCON
target systems (what should they be anyway?) and examine/compare the
candidate protocols later. Such a document SHOULD be co-authored by (1)
conferencing services providers first and (2) by conferencing platform
vendors, second.

Could we shift this debate from protocols to requirements?

Henry

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Thursday, August 21, 2003 9:55 AM
> To: Henry Sinnreich
> Cc: 'vinton g. cerf'; 'Marshall Rose'; 'Peterson, Jon'; [email-masked];
> Alan Johnston; Robert Sparks
> Greetings.
> Henry, If we wanted to do a SIP-only conferencing solution, we would
> have left this work in SIPPING.  However we discovered that several of
> the problems we were trying to solve were applicable to non-SIP
> signaled conferences (including mixed protocol conferences).  We also
> wanted to get wider input from the IETF community since there is a lot
> of previous work that's gone on. Just like RTP/RTCP streams are setup
> by SIP, H.323, MGCP, Megaco, and even proprietary signaling protocols,
> there is no reason that a common approach for conference policy,
> rosters, inter-conference media manipulation, and floor control can't
> be used by vendors which use any signaling protocol.  (I will remind
> you that, for example, my company has an installed base of over 2
> million phones which are using a proprietary protocol.)  Please rest
> assured however that SIPPING would make sure that any SIP-specific
> pieces get done in SIPPING in a way that works with the output of XCON.
> 
> As for Marshall's comments: there is certainly nothing nefarious about
> having a large body of source work when trying to start a Working Group
> (I cite XMPP as a recent example). What is important is for folks to
> focus on the *charter text* and the desired output, rather than make
> assumptions about the intent of those contributors. As for his
> suggestion that a generic conferencing working group should live in
> APPS instead of TSV, please consider that MMUSIC was the original host
> for conferencing work in IETF and therefore there is some precedent for
> the work to happen in TSV.  I am fine with either, but I believe this
> issue was already worked out among Ted, Ned, Allison, and Jon.
> Marshall, if there is something specific that you don't like about the
> charter as a generic conferencing working group, please propose
> alternate rewording.
> 
> thanks,
> -rohan
> co-chair SIP and SIPPING WGs
> 
> On Wednesday, August 20, 2003, at 06:33 AM, Henry Sinnreich wrote:
> >>> folks want to do conferencing, then they should have a working group
> >>> to
> >> do
> >>> that. however, the charter for that working group should not imply
> >>> that
> >> the
> >>> a reasonable person reading the charter would conclude that the
> >>> scope of
> >> the
> >>> manages to do conferencing very well without using that acronym. if
> >>> that
> >> is

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Aug 2003 13:35:37 -0400

> Leaving the SIP-XMPP discussion aside (nobody will change their mind
> anyway) a matter of concern is the 100% dominance of protocol experts
> in this discussion and no real participation from conference service
> operators and conference platform vendors. This raises several
> flags...

once again, an attempt to coerce IETF into preserving the status quo in
the market.

is it really IETF's job to legislate full employment for conference
service operators?

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 21 Aug 2003 07:55:20 -0700

Greetings.

thanks,
-rohan

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 21 Aug 2003 09:44:34 -0700

I'm also concerned that conferencing semantics could lead to 
basic interoperability problems that would be difficult to 
surmount.  If you can imagine XMPP in common usage for either
instant messaging or software agent communication (think 'bots')
and also SIMPLE in common usage for instant messaging, with 
SIP already deployed for joining conferences, then we have to 
plan for conferencing servers that can choose to support 
XMPP and SIP/SIMPLE access without crippling either protocol
suite or requiring client rewrites.

Lisa

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Keith Moore
> Sent: Wednesday, August 20, 2003 4:43 PM
> To: Henry Sinnreich
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> > It is high time the IETF should get its act together and 
> converge on 
> > the one single multiparty (conferencing!) multimedia 
> session protocol: 
> > SIP.
> 
> Why in the world should IETF bias a conferencing solution 
> toward the telephony providers?  I mean, if SIP turned out to 
> be a good solution for everyone, fine. But the group 
> shouldn't assume a priori that SIP is the right direction.
> 
> 
> 
>

---

From: Marshall Rose <[email-masked]>
Date: Thu, 21 Aug 2003 11:19:24 -0700

> assumptions about the intent of those contributors.
    
and, as has been repeatedly pointed out, the text in the proposed
charter is rather poor. we now have four sets of people with entirely
different interpretations (some from the SIP camp, some from the XMPP
camp, plus the IETF chair).

> charter as a generic conferencing working group, please propose 

that's easy:
    
    1,$s/conferencing/SIP-based conferencing/g
    
/mtr

---

From: Marshall Rose <[email-masked]>
Date: Thu, 21 Aug 2003 11:20:11 -0700

> Could we shift this debate from protocols to requirements?

something we can both agree on!
    
cheers,
    
/mtr

---

From: "vinton g. cerf" <[email-masked]>
Date: Wed, 20 Aug 2003 20:18:43 -0400

keith,

SIP may have been initially motivated by telephony style applications but it is a very general and extensible negotiation protocol - it was that aspect that grabbed my attention when I first heard about Schulzrinne's work on it several years ago. I think the point really is that SIP is extensible and may be a very reasonable platform on which to build a wide range of peer to peer and distributed application control.

vint

>But the group shouldn't assume a priori that SIP is the right direction.

Vint Cerf
SVP Technology Strategy
MCI

---

From: Alan Johnston <[email-masked]>
Date: Thu, 21 Aug 2003 14:05:40 -0500

>camp, plus the IETF chair).

Marshall,

I think the misunderstanding comes from your interpretation that when the 
charter text says "session setup using SIP" you think this means "session 
setup using SIP and IM and presence using SIMPLE".  You do understand the 
difference, no?

XCON requires a signaling protocol - that is part of the definition of the 
working group as *Centralized* conferencing.  A signaling protocol (not IM 
and presence protocol) is needed to establish, modify, tear down, and 
manipulate media sessions.  The nature of the streams will vary from RTP 
voice and video to IM text streams.  The IM text streams can be *any* 
protocol - SIMPLE, XMPP, or some proprietary IM protocol. XCON will work 
with them all.  Are you opposed to this?

If we don't use SIP as the example signaling protocol in our documents, 
should we use an ITU-T signaling protocol instead?  H.323, ISDN?  Of course 
not, we use an IETF proposed standard for session signaling, SIP.

Nothing in XCON is specific to SIP - I repeat nothing.  However, the 
documents will need to make reference to a signaling protocol, and SIP, as 
mentioned in the charter text, is it.  The likely output of XCON will be 
XML-based protocols that work at a higher level than any signaling 
protocol.  Are you perhaps opposed to the use of XML to control and create 
conferences?  This seems to be in line with the Jabber document which you 
have referenced a few times, which by the way, is exclusively limited to 
text messaging, which is a subset of the XCON problem space.

I propose wording changes to the charter which will make clear the 
distinction between SIP signaling and SIMPLE for IM - I believe this is the 
source of the technical disputes.

Thanks,
Alan Johnston
XCON BOF co-chair.

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 21 Aug 2003 16:59:35 -0500

Keith,

> is it really IETF's job to legislate full employment for conference

I find this very hard to understand. Are not service providers and network
managers the people supposed to bring these services into operation? Who
else has the operational credentials to define requirements for
conferencing?

If this was an emotional response, you need not reply.

Henry

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith
> Moore
> Sent: Thursday, August 21, 2003 12:36 PM
> To: Henry Sinnreich
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Aug 2003 19:00:34 -0400

> Are not service providers and network
> managers the people supposed to bring these services into operation? 

I certainly don't share that assumption.  Then again, I don't share the
assumption that any central coordinating authority is needed to set up
conferencing services.

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 21 Aug 2003 21:48:15 -0700

Marshall,

You got it exactly backwards.  There will not be a SIP-specific 
conferencing WG.  There was however a lot of interest in a 
non-SIP-specific conferencing WG.  If you don't like the current XCON 
charter text, then propose some alternate wording for a 
non-SIP-specific conferencing WG.  Otherwise forever hold your peace.

thanks,
-rohan

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 11:01:40 -0400

> non-SIP-specific conferencing WG. 

Well it seems like the charter authors (and IESG) have plenty of
feedback by now.  Now it's up to them to revise that charter to correct
the (mis?) impression that the group was intended to promote use of SIP
for this situation.

Until the charter is revised, is there anything left to discuss?

Keith

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 22 Aug 2003 11:15:52 -0500

> assumption that any central coordinating authority is needed to set up

This is an interesting point. The XCON WG is about _Centralized_
conferencing platforms. Who does operate such centralized systems?

Thanks, Henry

> From: Keith Moore [mailto:[email-masked]]
> Sent: Thursday, August 21, 2003 6:01 PM
> To: Henry Sinnreich
> Cc: [email-masked]; [email-masked]; [email-masked];

---

From: David Morris <[email-masked]>
Date: Fri, 22 Aug 2003 09:49:14 -0700 (PDT)

> conferencing platforms. Who does operate such centralized systems?

It seems to me that the issue isn't whether a conferencing service could
be setup without a central authority but rather if when there is a need
for central control, what are the protocols used to coordinate with the
controlling authority. I believe there is a need for both forms of
organization:
  a.  Distributed control
  b.  Centralized control

WebEx and Placeware (now owned by MS) are examples of centralized systems
which currently exist.

Dave Morris

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 22 Aug 2003 12:50:25 -0700

> conferencing platforms. Who does operate such centralized systems?

to use a specific example....

in the case of something like the IESG teleconference, I would expect the 
IETF secretariat to be in control of the conference, and that all 
participants are able to securely assert identities that the secretariat 
can verify.

The protocols should make no assumptions on whether the programs executing 
the conference authority run on machines operated by the secretariat, AT&T 
or a service provider in rural India, and should make no assumptions on 
whether the trust is rooted in Verisign or psg.com, or is brokered through 
a mechanism that doesn't need a single root for its trust mechanism.

If "centralized conference control" doesn't mean that anyone with the 
required resources can be a center, I think we're on a very wrong path.

My opinion, of course.

                            Harald

---

From: Dave Crocker <[email-masked]>
Date: Fri, 22 Aug 2003 13:34:25 -0700

Harald,

HTA> and should make no assumptions on
HTA> whether the trust is rooted in Verisign or psg.com, or is brokered through
HTA> a mechanism that doesn't need a single root for its trust mechanism.

HTA> If "centralized conference control" doesn't mean that anyone with the
HTA> required resources can be a center, I think we're on a very wrong path.

The style of protocol needed for a single, centralized control
mechanism, versus a distributed and cooperative control mechanism,
typically is quite different.

The obvious example would be centralized dns control -- as we now have
for each node in the tree -- versus efforts to create multiple
authorities for any given node, such as the root.

Did you have in mind a way to reconcile this?

d/

---

From: David Morris <[email-masked]>
Date: Fri, 22 Aug 2003 13:50:31 -0700 (PDT)

> Did you have in mind a way to reconcile this?

Different protocols ... Harald's only stipulation is that the protocol
shouldn't prevent anyone from creating a centeralized conference control
facility.

The distinction I see between centralized control and distributed control
is with centralized control, I must have a way to establish trust with the
control facility which I must trust to authenticate all other participants
in a similar fashion.  With a distributed mechanism, I must establish a
trust relationship directly with each participant.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 22 Aug 2003 14:22:14 -0700

--On 22. august 2003 13:34 -0700 Dave Crocker <[email-masked]> wrote:

> HTA> whether the trust is rooted in Verisign or psg.com, or is brokered
> through HTA> a mechanism that doesn't need a single root for its trust
> mechanism.
>

no, I was responding to Henry Sinnreich's comment on "who will operate the 
centralized functions" only. I thought it was obvious from xcon's charter 
that "multiple authority for a single conference" conference management is 
out of scope, and I'm still talking about xcon.

                        Harald

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 22 Aug 2003 16:06:04 -0700

> assumption that any central coordinating authority is needed to set up

What do you mean by central coordinating authority?  A big service 
provider, or *any* point of control?

I am certainly interested in hearing requirements from the large 
operators, but not to the exclusion of requirements for on my own 
equipment, local, or community-hosted conference services.

XCON was envisioned as a way to handle "tightly-coupled conferences" 
with a central point of control. However, there is no reason this 
central point of control has to be hosted by a service provider.  It 
could be running in your phone or IM client for example.

I believe loosely-coupled conferences bring problems with a very 
different timeline, and I do not wish to bog down XCON with these 
problems. Indeed, I believe that much of the interest at the XCON BOF 
was because we weren't trying to boil the ocean.

thanks,
-rohan