Subject: [XCON] Maintenance on softarmor web site Thursday 30Oct2003

From: "Dean Willis" <[email-masked]>
Date: Thu, 30 Oct 2003 13:23:04 -0600

1:30 PM USCST

The main server (www.softarmor.com) will be down for the next few hours
while I replace the OS.

In the interim, if you need web content, it's available at
http://kevlar.softarmor.com/

Anybody using the main box as a relay for email will also be affected.

Cheers,

--
Dean

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Dean Willis <[email-masked]>
Date: Thu, 30 Oct 2003 23:59:06 -0600

> Anybody using the main box as a relay for email will also be affected.

Everything should be back in working order, I think. Maybe. Note that 
everything has been rekeyed.

--
Dean

Subject: RE: [XCON] Candidate floor control message definition language
From: Dean Willis <[email-masked]>
To: Adam Roach <[email-masked]>
Cc: [email-masked]
Date: Mon, 13 Oct 2003 11:19:49 -0500

On Sat, 2003-10-11 at 23:52, Adam Roach wrote:
> Whoops. I obviously forgot that this work had already been started.
> For some reason, sometime between Vienna and now, my brain must
> have translated "no floor control proposals yet" into "the floor
> control work hasn't started yet."

Probably my fault -- Tom Hiller and I have been teasing you with a
potentially seperate requirements draft specific to CDMA-2000 1XRTT
short-data-burst usage.

And no, we don't think "Anything text plus sigcomp" is always adequate
for this particularly demanding usage.

--
Dean

X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
To: "@nokia.com'; Adam Roach; [email-masked]; Jonathan Rosenberg; [email-masked]
CC: [email-masked]
Date: Sun, 12 Oct 2003 04:52:22 -0600
Subject: RE: [XCON] Candidate floor control message definition language
From: "Adam Roach"
Content-type: text/plain; charset=windows-1252; format=flowed
MIME-Version: 1.0
Content-transfer-encoding: 8bit

Whoops. I obviously forgot that this work had already been started.
For some reason, sometime between Vienna and now, my brain must
have translated "no floor control proposals yet" into "the floor
control work hasn't started yet."

Sorry about that.

/a

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, October 11, 2003 3:00
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [XCON] Candidate floor control message 
> definition language
> 
> 
> 
> First version of floor control requirements document is available at:
> http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-flo
or-control-req-00.txt

Comments are welcome..

--
Petri

> -----Original Message-----
> From: ext Adam Roach [mailto:[email-masked]]
> Sent: 11 October, 2003 02:22
> To: 'Pete Cordell'; Jonathan Rosenberg; Eric Burger
> Cc: [email-masked]
> Subject: RE: [XCON] Candidate floor control message 
> definition language
> 
> 
> (As chair)
> 
> Thanks for taking some initiative on this issue. However,
> I think we're jumping a little too far ahead.
> 
> >From a charter perspective, we have two deliverables on the
> topic of floor control:
> 
>   1) Floor Control Protocol Requirements
>   2) Floor Control Protocol Specification
> 
> Of course, the requirements need to be nailed down before
> the specification is completed. There have been several
> microphone, hallway, and e-mail discussions in which people
> have suggested various requirements on the floor control
> protocol; we need someone to volunteer to compile these
> in a document that we can form some consensus around. I
> would think that having at least a -00 draft of such
> requirements is a necessary first step before we start
> discussing syntax and semantics of the actual protocol.
> 
> /a
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

content-class: urn:content-classes:message
Subject: RE: [XCON] Candidate floor control message definition language
Date: Sat, 11 Oct 2003 10:59:49 +0300
From: [email-masked]
To: [email-masked],  [email-masked],  [email-masked],  [email-masked]
Cc: [email-masked]

First version of floor control requirements document is available at:
http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-floor-control-req-00.txt

Comments are welcome..

--
Petri

> -----Original Message-----
> From: ext Adam Roach [mailto:[email-masked]]
> Sent: 11 October, 2003 02:22
> To: 'Pete Cordell'; Jonathan Rosenberg; Eric Burger
> Cc: [email-masked]
> Subject: RE: [XCON] Candidate floor control message 
> definition language
> 
> 
> (As chair)
> 
> Thanks for taking some initiative on this issue. However,
> I think we're jumping a little too far ahead.
> 
> >From a charter perspective, we have two deliverables on the
> topic of floor control:
> 
>   1) Floor Control Protocol Requirements
>   2) Floor Control Protocol Specification
> 
> Of course, the requirements need to be nailed down before
> the specification is completed. There have been several
> microphone, hallway, and e-mail discussions in which people
> have suggested various requirements on the floor control
> protocol; we need someone to volunteer to compile these
> in a document that we can form some consensus around. I
> would think that having at least a -00 draft of such
> requirements is a necessary first step before we start
> discussing syntax and semantics of the actual protocol.
> 
> /a
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

From: Adam Roach <[email-masked]>
To: "'Pete Cordell'" <[email-masked]>,  Jonathan Rosenberg <[email-masked]>, Eric Burger <[email-masked]>
Subject: RE: [XCON] Candidate floor control message definition language
Date: Fri, 10 Oct 2003 18:22:17 -0500
Cc: [email-masked]
Sender: [email-masked]

(As chair)

Thanks for taking some initiative on this issue. However,
I think we're jumping a little too far ahead.

>>From a charter perspective, we have two deliverables on the
topic of floor control:

  1) Floor Control Protocol Requirements
  2) Floor Control Protocol Specification

Of course, the requirements need to be nailed down before
the specification is completed. There have been several
microphone, hallway, and e-mail discussions in which people
have suggested various requirements on the floor control
protocol; we need someone to volunteer to compile these
in a document that we can form some consensus around. I
would think that having at least a -00 draft of such
requirements is a necessary first step before we start
discussing syntax and semantics of the actual protocol.

/a
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Pete Cordell" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>,  "Eric Burger" <[email-masked]>
Subject: Re: [XCON] Candidate floor control message definition language
Date: Fri, 10 Oct 2003 22:49:52 +0100
Cc: [email-masked]
Sender: [email-masked]

That was my point - If you don't feel using XML Schema from the off is the
right thing to do, use Lumas as an abstract definition and then switch to
what ever feels the right thing once you know what you're trying to code up.
The tools are there to help you make that transition, or you could do it
manually if you prefer.  Of course you could invent your own abstract
syntax, or you could mandate XML Schema (or maybe RELAX NG) from the start.

(Just in case Eric was not understanding what I was saying, the ABNF
generation stuff is just doing the handle turning that you could quite
easily do manually if you chose to.  A bit like you can use ABNF directly or
you can run it through yacc and lex to save some of your coding effort
depending on your fancy.)

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
http://www.tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Eric Burger" <[email-masked]>
Cc: "Pete Cordell" <[email-masked]>; <[email-masked]>
Sent: 10 October 2003 21:36
Subject: Re: [XCON] Candidate floor control message definition language

> Can we please not start out this working group with the never-ending
> debate on protocol syntax? I would rather focus on the protocol
> semantics and functionality.
>
> -Jonathan R.
>
> Eric Burger wrote:
>
> > I would offer that anything plus sigcomp would have a message size on
the order of a hand-coded binary format.
> >
> > Given that, I would offer an "anything" that was at least text based, so
we can work out the protocol without lots and lots and lots of custom tools,
and optimize it (sigcomp) later.
> >
> >
> >>-----Original Message-----
> >>From: Pete Cordell [mailto:[email-masked]]
> >>Sent: Fri, October 10, 2003 6:31 AM
> >>To: [email-masked]
> >>Subject: [XCON] Candidate floor control message definition language
> >>
> >>
> >>Dear All,
> >>
> >>I've recently joined this this list, but I was looking
> >>through the archives
> >>and noticed that there was mention that XML might not be the
> >>best thing for
> >>the floor control protocol and some sort of exercise might be
> >>undertaken to
> >>look for alternatives.
> >>
> >>I would like to put forward a candidate for consideration called Lumas
> >>(Language for Universal Message Abstraction and Specification).
> >>
> >>The message definition language is along the lines of C, with
> >>ideas stolen
> >>from UML, Java, XML plus extras where appropriate.  The goal
> >>is to have a
> >>compact representation that is easy for most regular programmers to
> >>understand.  For example, you might have:
> >>
> >>struct my-floor-control {
> >>    int<0..65535>    participant-id as ?;    // 'as ?' means
> >>'do not tag'
> >>    Operation        operation as ?;
> >>};
> >>
> >>Union Operation pluggable {
> >>    void    request-floor as reqf;
> >>    void    release-floor as relf;
> >>};
> >>
> >>A resulting message would be:
> >>
> >>12 reqf
> >>
> >>The language is highly extensible.  For example in another
> >>module you could
> >>define:
> >>
> >>plug
> >>    union     vote { void yes; void no; };
> >>into Operation;
> >>
> >>which would make the above union above (the pluggable keyword
> >>declared it as
> >>a site where this was allowed) to be treated as if it was:
> >>
> >>Union Operation pluggable {
> >>    void    request-floor as reqf;
> >>    void    release-floor as relf;
> >>    union     vote { void yes; void no; };
> >>};
> >>
> >>and an encoding would be:
> >>
> >>12 vote=yes
> >>
> >>There is more of a summary at:
> >>
> >>      http://www.tech-know-ware.com/lumas/lumas-example.html
> >>
> >>I have a full specification at:
> >>
> >>      http://www.ietf.org/internet-drafts/draft-cordell-lumas-01.txt
> >>
> >>which I am progressing as an individual submission so that it
> >>is available
> >>to move to standards track if and when someone finds it
> >>useful (otherwise I
> >>think there is a bit of a chicken and egg type problem with
> >>this sort of
> >>thing).
> >>
> >>Currently there is a definition of how to encode messages
> >>defined in Lumas
> >>using text (as alluded above), but it would be equally
> >>possible to define
> >>rules for a binary conversion if required (I have notes on
> >>this, but the
> >>rules might be more extensible than you require).
> >>
> >>But the real benefit to this group maybe to simply use Lumas as an
> >>information set representation language as an aid to evolving
> >>the protocol.
> >>I'm part way through developing a tool that converts the
> >>message set in ABNF
> >>(just need to make it a bit prettier!), and intend to do the
> >>same for XML
> >>Schema.  So you could start out using Lumas and then at the
> >>last minute, rip
> >>all the Lumas out and insert automatically generated ABNF or
> >>XML Schema
> >>(although you might want to do a few tweaks to the output I
> >>guess - target
> >>namespace declarations etc).  (In theory the same approach
> >>could get it to
> >>draw ASCII art TLV type pictures, but I'm not quite sure how
> >>that would work
> >>at the moment.)
> >>
> >>I have some free tools such as a validator and parsers for C
> >>and Perl at:
> >>
> >>    http://www.tech-know-ware.com/lumas/
> >>
> >>I intend to add the ABNF generator and then the XML Schema
> >>generator to this
> >>group soon.  I also have a Lumas/C binding compiler that I'm
> >>working on.
> >>
> >>I hope this can be of help to you.  All the best,
> >>
> >>Pete.
> >>
> >>=============================================
> >>Pete Cordell
> >>Tech-Know-Ware
> >>[email-masked]
> >>http://www.tech-know-ware.com
> >>+44 1473 635863
> >>=============================================
> >>
> >>[email-masked]
> >>http://www.softarmor.com/mailman/listinfo/xcon
> >>
> >>
> >
> >
> >
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> >
>
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Fri, 10 Oct 2003 16:36:48 -0400
From: Jonathan Rosenberg <[email-masked]>
Organization: dynamicsoft
To: Eric Burger <[email-masked]>
Subject: Re: [XCON] Candidate floor control message definition language
Cc: [email-masked]
Sender: [email-masked]

Can we please not start out this working group with the never-ending 
debate on protocol syntax? I would rather focus on the protocol 
semantics and functionality.

-Jonathan R.

Eric Burger wrote:

> I would offer that anything plus sigcomp would have a message size on the order of a hand-coded binary format.
> 
> Given that, I would offer an "anything" that was at least text based, so we can work out the protocol without lots and lots and lots of custom tools, and optimize it (sigcomp) later.
> 
> 
>>-----Original Message-----
>>From: Pete Cordell [mailto:[email-masked]]
>>Sent: Fri, October 10, 2003 6:31 AM
>>To: [email-masked]
>>Subject: [XCON] Candidate floor control message definition language
>>
>>
>>Dear All,
>>
>>I've recently joined this this list, but I was looking 
>>through the archives
>>and noticed that there was mention that XML might not be the 
>>best thing for
>>the floor control protocol and some sort of exercise might be 
>>undertaken to
>>look for alternatives.
>>
>>I would like to put forward a candidate for consideration called Lumas
>>(Language for Universal Message Abstraction and Specification).
>>
>>The message definition language is along the lines of C, with 
>>ideas stolen
>>from UML, Java, XML plus extras where appropriate.  The goal 
>>is to have a
>>compact representation that is easy for most regular programmers to
>>understand.  For example, you might have:
>>
>>struct my-floor-control {
>>    int<0..65535>    participant-id as ?;    // 'as ?' means 
>>'do not tag'
>>    Operation        operation as ?;
>>};
>>
>>Union Operation pluggable {
>>    void    request-floor as reqf;
>>    void    release-floor as relf;
>>};
>>
>>A resulting message would be:
>>
>>12 reqf
>>
>>The language is highly extensible.  For example in another 
>>module you could
>>define:
>>
>>plug
>>    union     vote { void yes; void no; };
>>into Operation;
>>
>>which would make the above union above (the pluggable keyword 
>>declared it as
>>a site where this was allowed) to be treated as if it was:
>>
>>Union Operation pluggable {
>>    void    request-floor as reqf;
>>    void    release-floor as relf;
>>    union     vote { void yes; void no; };
>>};
>>
>>and an encoding would be:
>>
>>12 vote=yes
>>
>>There is more of a summary at:
>>
>>      http://www.tech-know-ware.com/lumas/lumas-example.html
>>
>>I have a full specification at:
>>
>>      http://www.ietf.org/internet-drafts/draft-cordell-lumas-01.txt
>>
>>which I am progressing as an individual submission so that it 
>>is available
>>to move to standards track if and when someone finds it 
>>useful (otherwise I
>>think there is a bit of a chicken and egg type problem with 
>>this sort of
>>thing).
>>
>>Currently there is a definition of how to encode messages 
>>defined in Lumas
>>using text (as alluded above), but it would be equally 
>>possible to define
>>rules for a binary conversion if required (I have notes on 
>>this, but the
>>rules might be more extensible than you require).
>>
>>But the real benefit to this group maybe to simply use Lumas as an
>>information set representation language as an aid to evolving 
>>the protocol.
>>I'm part way through developing a tool that converts the 
>>message set in ABNF
>>(just need to make it a bit prettier!), and intend to do the 
>>same for XML
>>Schema.  So you could start out using Lumas and then at the 
>>last minute, rip
>>all the Lumas out and insert automatically generated ABNF or 
>>XML Schema
>>(although you might want to do a few tweaks to the output I 
>>guess - target
>>namespace declarations etc).  (In theory the same approach 
>>could get it to
>>draw ASCII art TLV type pictures, but I'm not quite sure how 
>>that would work
>>at the moment.)
>>
>>I have some free tools such as a validator and parsers for C 
>>and Perl at:
>>
>>    http://www.tech-know-ware.com/lumas/
>>
>>I intend to add the ABNF generator and then the XML Schema 
>>generator to this
>>group soon.  I also have a Lumas/C binding compiler that I'm 
>>working on.
>>
>>I hope this can be of help to you.  All the best,
>>
>>Pete.
>>
>>=============================================
>>Pete Cordell
>>Tech-Know-Ware
>>[email-masked]
>>http://www.tech-know-ware.com
>>+44 1473 635863
>>=============================================
>>
>>[email-masked]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
>>
> 
> 
> 
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] Candidate floor control message definition language
Date: Fri, 10 Oct 2003 15:15:01 -0400
From: "Eric Burger" <[email-masked]>
To: "Pete Cordell" <[email-masked]>,  [email-masked]
Sender: [email-masked]

I would offer that anything plus sigcomp would have a message size on the order of a hand-coded binary format.

Given that, I would offer an "anything" that was at least text based, so we can work out the protocol without lots and lots and lots of custom tools, and optimize it (sigcomp) later.

> -----Original Message-----
> From: Pete Cordell [mailto:[email-masked]]
> Sent: Fri, October 10, 2003 6:31 AM
> To: [email-masked]
> Subject: [XCON] Candidate floor control message definition language
> 
> 
> Dear All,
> 
> I've recently joined this this list, but I was looking 
> through the archives
> and noticed that there was mention that XML might not be the 
> best thing for
> the floor control protocol and some sort of exercise might be 
> undertaken to
> look for alternatives.
> 
> I would like to put forward a candidate for consideration called Lumas
> (Language for Universal Message Abstraction and Specification).
> 
> The message definition language is along the lines of C, with 
> ideas stolen
> from UML, Java, XML plus extras where appropriate.  The goal 
> is to have a
> compact representation that is easy for most regular programmers to
> understand.  For example, you might have:
> 
> struct my-floor-control {
>     int<0..65535>    participant-id as ?;    // 'as ?' means 
> 'do not tag'
>     Operation        operation as ?;
> };
> 
> Union Operation pluggable {
>     void    request-floor as reqf;
>     void    release-floor as relf;
> };
> 
> A resulting message would be:
> 
> 12 reqf
> 
> The language is highly extensible.  For example in another 
> module you could
> define:
> 
> plug
>     union     vote { void yes; void no; };
> into Operation;
> 
> which would make the above union above (the pluggable keyword 
> declared it as
> a site where this was allowed) to be treated as if it was:
> 
> Union Operation pluggable {
>     void    request-floor as reqf;
>     void    release-floor as relf;
>     union     vote { void yes; void no; };
> };
> 
> and an encoding would be:
> 
> 12 vote=yes
> 
> There is more of a summary at:
> 
>       http://www.tech-know-ware.com/lumas/lumas-example.html
> 
> I have a full specification at:
> 
>       http://www.ietf.org/internet-drafts/draft-cordell-lumas-01.txt
> 
> which I am progressing as an individual submission so that it 
> is available
> to move to standards track if and when someone finds it 
> useful (otherwise I
> think there is a bit of a chicken and egg type problem with 
> this sort of
> thing).
> 
> Currently there is a definition of how to encode messages 
> defined in Lumas
> using text (as alluded above), but it would be equally 
> possible to define
> rules for a binary conversion if required (I have notes on 
> this, but the
> rules might be more extensible than you require).
> 
> But the real benefit to this group maybe to simply use Lumas as an
> information set representation language as an aid to evolving 
> the protocol.
> I'm part way through developing a tool that converts the 
> message set in ABNF
> (just need to make it a bit prettier!), and intend to do the 
> same for XML
> Schema.  So you could start out using Lumas and then at the 
> last minute, rip
> all the Lumas out and insert automatically generated ABNF or 
> XML Schema
> (although you might want to do a few tweaks to the output I 
> guess - target
> namespace declarations etc).  (In theory the same approach 
> could get it to
> draw ASCII art TLV type pictures, but I'm not quite sure how 
> that would work
> at the moment.)
> 
> I have some free tools such as a validator and parsers for C 
> and Perl at:
> 
>     http://www.tech-know-ware.com/lumas/
> 
> I intend to add the ABNF generator and then the XML Schema 
> generator to this
> group soon.  I also have a Lumas/C binding compiler that I'm 
> working on.
> 
> I hope this can be of help to you.  All the best,
> 
> Pete.
> 
> =============================================
> Pete Cordell
> Tech-Know-Ware
> [email-masked]
> http://www.tech-know-ware.com
> +44 1473 635863
> =============================================
> 
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Pete Cordell" <[email-masked]>
To: [email-masked]
Date: Fri, 10 Oct 2003 11:31:09 +0100
Subject: [XCON] Candidate floor control message definition language
Sender: [email-masked]

Dear All,

I've recently joined this this list, but I was looking through the archives
and noticed that there was mention that XML might not be the best thing for
the floor control protocol and some sort of exercise might be undertaken to
look for alternatives.

I would like to put forward a candidate for consideration called Lumas
(Language for Universal Message Abstraction and Specification).

The message definition language is along the lines of C, with ideas stolen
from UML, Java, XML plus extras where appropriate.  The goal is to have a
compact representation that is easy for most regular programmers to
understand.  For example, you might have:

struct my-floor-control {
    int<0..65535>    participant-id as ?;    // 'as ?' means 'do not tag'
    Operation        operation as ?;
};

Union Operation pluggable {
    void    request-floor as reqf;
    void    release-floor as relf;
};

A resulting message would be:

12 reqf

The language is highly extensible.  For example in another module you could
define:

plug
    union     vote { void yes; void no; };
into Operation;

which would make the above union above (the pluggable keyword declared it as
a site where this was allowed) to be treated as if it was:

Union Operation pluggable {
    void    request-floor as reqf;
    void    release-floor as relf;
    union     vote { void yes; void no; };
};

and an encoding would be:

12 vote=yes

There is more of a summary at:

      http://www.tech-know-ware.com/lumas/lumas-example.html

I have a full specification at:

      http://www.ietf.org/internet-drafts/draft-cordell-lumas-01.txt

which I am progressing as an individual submission so that it is available
to move to standards track if and when someone finds it useful (otherwise I
think there is a bit of a chicken and egg type problem with this sort of
thing).

Currently there is a definition of how to encode messages defined in Lumas
using text (as alluded above), but it would be equally possible to define
rules for a binary conversion if required (I have notes on this, but the
rules might be more extensible than you require).

But the real benefit to this group maybe to simply use Lumas as an
information set representation language as an aid to evolving the protocol.
I'm part way through developing a tool that converts the message set in ABNF
(just need to make it a bit prettier!), and intend to do the same for XML
Schema.  So you could start out using Lumas and then at the last minute, rip
all the Lumas out and insert automatically generated ABNF or XML Schema
(although you might want to do a few tweaks to the output I guess - target
namespace declarations etc).  (In theory the same approach could get it to
draw ASCII art TLV type pictures, but I'm not quite sure how that would work
at the moment.)

I have some free tools such as a validator and parsers for C and Perl at:

    http://www.tech-know-ware.com/lumas/

I intend to add the ABNF generator and then the XML Schema generator to this
group soon.  I also have a Lumas/C binding compiler that I'm working on.

I hope this can be of help to you.  All the best,

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
http://www.tech-know-ware.com
+44 1473 635863
=============================================

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: The IESG <[email-masked]>
To: "IETF-Announce: ;"
Cc: [email-masked],  [email-masked],  [email-masked]
Subject: WG Action: Centralized Conferencing (xcon)
Date: Tue, 07 Oct 2003 15:53:05 -0400
Sender: [email-masked]

A new IETF working group has been formed in the Transport Area.  
For additional information, please contact the Area Directors or the WG Chairs.

Centralized Conferencing (xcon)
-------------------------------

Current Status: Active Working Group  

Chair(s):
Adam Roach <[email-masked]>
Alan Johnston <[email-masked]>

Transport Area Director(s):
Allison Mankin <[email-masked]>
Jon Peterson <[email-masked]>

Transport Area Advisor:
Allison Mankin <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: http://www.softarmor.com/mailman/listinfo/xcon
Archive: http://www.softarmor.com/pipermail/xcon

Description of Working Group:

The focus of this working group is to develop a standardized suite of
protocols for tightly-coupled multimedia conferences, where strong
security and authorization requirements are integral to the solution.
Tightly-coupled conferences have a central point of control and
authorization (known as a focus) so they can enforce specific media and
membership relationships, and provide an accurate roster of 
participants. The media mixing or combining function of a 
tightly-coupled conference need not be performed centrally, however.

The scope of this effort is intentionally more narrow than previous
attempts to standardize conferencing (e.g. centralized control), and is
intended to enable interoperability in a commercial environment which
already has a number of non-standard implementations using some of the
protocols.

Privacy, security, and authorization mechanisms are integral to the
solution generated by the working group. This includes allowing
participants to be invisible to all but the conference owner, or to be
visible but participate anonymously with respect to some or all of
the other participants.

Authorization rules allow for participants and non-participants
to have roles (ex: speaker, moderator, owner), and to be otherwise
authorized to perform membership and media manipulation for or on
behalf of other participants. In order to preserve these properties,
the protocols used will require implementation of channel security
and authentication services.

Due to the centralized architecture of the WG, XCON's mechanisms will 
place requirements on the signaling protocol used between the focus and 
the participants. At a high level, the signaling protocol must be able 
to establish, tear down, modify, and perform call control operations on
multimedia streams, including voice, video, and instant messaging, in 
both a centralized and distributed mixing architecture. SIP will be the 
reference session signaling protocol used for examples; however, none of 
the XCON solutions themselves will be signaling protocols, nor will XCON 
extend existing signaling protocols. Other signaling protocols than SIP 
may be used between the focus and participants, including non-IETF 
protocols, but the requirements and possible extensions needed for other 
signaling protocols to utilize the full functionality of the XCON 
architecture is outside the scope of XCON.

The deliverables for the group will be:
- A mechanism for membership and authorization control
- A mechanism to manipulate and describe media "mixing" or "topology" 
  for multiple media types (audio, video, text)
- A mechanism for notification of conference related events/changes (for
  example a floor change)
- A basic floor control protocol

The initial set of protocols will be developed for use in unicast media
conferences. The working group will perform a second round of work to
enhance the set of protocols as necessary for use with multicast media
after their initial publication.

The following items are specifically out-of-scope:
- Voting
- Fully distributed conferences
- Loosely-coupled conferences (no central point of control)
- Far-end device control
- Protocol used between the conference controller and the mixer(s)
- Capabilities negotiation of the mixer(s)
- Master-slave cascaded conferences

The working group will coordinate closely with the SIPPING and
MMUSIC working groups. In addition the working group will cooperate
with other groups as needed, including SIP, MSEC, AVT, and the W3C
SMIL working groups. In addition, the working group will consider
a number of existing drafts as input to the working group.

Goals and Milestones:

       Oct 2003 Submit Requirements for Membership Manipulation for
                         publication as Informational

       Oct 2003 Submit Requirements for Basic Floor Control for
                         publication as Informational

       Nov 2003 Submit Conferencing Scenarios document for publication
                         as Informational

       Nov 2003 Submit Use Cases for Media Topology Control for publication
                         as Informational

       Dec 2003 Submit Requirements for Media Topology Control for
                         publication as Informational

       Feb 2004 Submit Basic Floor Control Protocol for publication as PS

       Mar 2004 Submit Notification Event package extension for conference
                         related events for publication as PS

       May 2004 Submit Membership Manipulation Protocol for publication
                         as PS

       Jul 2004 Submit Protocol for Media Topology Control for publication
                         as PS