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

[Dean Willis <[e-mail]>]

Dean Willis wrote:
> 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

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

--
Dean


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




X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4JPT3PFN; Mon, 13 Oct 2003 12:20:02 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9DGH9GU002657 for <[e-mail]>; Mon, 13 Oct 2003 12:17:10 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9DGJnTu014084 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 13 Oct 2003 11:19:50 -0500
Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id h9DGJnqT014082; Mon, 13 Oct 2003 11:19:49 -0500
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to [e-mail] using -f
Subject: RE: [XCON] Candidate floor control message definition language
From: Dean Willis <[e-mail]>
To: Adam Roach <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5
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; [e-mail]; Jonathan Rosenberg; [e-mail]
CC: [e-mail]
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: [e-mail] [mailto:[e-mail]]
> Sent: Saturday, October 11, 2003 3:00
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: 11 October, 2003 02:22
> To: 'Pete Cordell'; Jonathan Rosenberg; Eric Burger
> Cc: [e-mail]
> 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
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4JPT3KA6; Sat, 11 Oct 2003 03:59:57 -0400
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9B7v7KW002442; Sat, 11 Oct 2003 03:57:08 -0400 (EDT)
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9B7xoZ28814; Sat, 11 Oct 2003 10:59:51 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Sat, 11 Oct 2003 10:59:50 +0300
Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 11 Oct 2003 10:59:50 +0300
Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 11 Oct 2003 10:59:50 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: RE: [XCON] Candidate floor control message definition language
Date: Sat, 11 Oct 2003 10:59:49 +0300
Message-ID: <[e-mail]>
Thread-Topic: [XCON] Candidate floor control message definition language
Thread-Index: AcOPhiheoug7OzzYS4SC4+VHqyz6LAARdqow
From: [e-mail]
To: [e-mail],  [e-mail],  [e-mail],  [e-mail]
Cc: [e-mail]
X-OriginalArrivalTime: 11 Oct 2003 07:59:50.0005 (UTC) FILETIME=[A540A250:01C38FCD]

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:[e-mail]]
> Sent: 11 October, 2003 02:22
> To: 'Pete Cordell'; Jonathan Rosenberg; Eric Burger
> Cc: [e-mail]
> 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
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4JPT3J2F; Fri, 10 Oct 2003 19:24:12 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9ANLMKW001015; Fri, 10 Oct 2003 19:21:22 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9ANMcTv019331; Fri, 10 Oct 2003 18:22:39 -0500
Received: from mail4.dynamicsoft.com (dyn-tx-bapp-001.dfw.dynamicsoft.com [63.110.3.100]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9ANMYTt019328 for <[e-mail]>; Fri, 10 Oct 2003 18:22:35 -0500
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9ANMIiM000785; Fri, 10 Oct 2003 19:22:18 -0400 (EDT)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4JSRJRT2>; Fri, 10 Oct 2003 18:22:18 -0500
Message-ID: <[e-mail]>
From: Adam Roach <[e-mail]>
To: "'Pete Cordell'" <[e-mail]>,  Jonathan Rosenberg <[e-mail]>, Eric Burger <[e-mail]>
Subject: RE: [XCON] Candidate floor control message definition language
Date: Fri, 10 Oct 2003 18:22:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

(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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4JPT3JBS; Fri, 10 Oct 2003 17:49:55 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9ALl5KW000672; Fri, 10 Oct 2003 17:47:06 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9ALmxTv018950; Fri, 10 Oct 2003 16:49:02 -0500
Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9ALmwTt018947 for <[e-mail]>; Fri, 10 Oct 2003 16:48:58 -0500
Received: from host213-122-184-234.in-addr.btopenworld.com ([213.122.184.234] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #23) id 1A857x-0004CE-00; Fri, 10 Oct 2003 22:48:50 +0100
Message-ID: <001a01c38f78$76ed0c40$0200000a@tkw>
From: "Pete Cordell" <[e-mail]>
To: "Jonathan Rosenberg" <[e-mail]>,  "Eric Burger" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: [XCON] Candidate floor control message definition language
Date: Fri, 10 Oct 2003 22:49:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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
[e-mail]
http://www.tech-know-ware.com
[phone]
=============================================

----- Original Message -----
From: "Jonathan Rosenberg" <[e-mail]>
To: "Eric Burger" <[e-mail]>
Cc: "Pete Cordell" <[e-mail]>; <[e-mail]>
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:[e-mail]]
> >>Sent: Fri, October 10, 2003 6:31 AM
> >>To: [e-mail]
> >>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
> >>[e-mail]
> >>http://www.tech-know-ware.com
> >>[phone]
> >>=============================================
> >>
> >>_______________________________________________
> >>XCON mailing list
> >>[e-mail]
> >>http://www.softarmor.com/mailman/listinfo/xcon
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > XCON mailing list
> > [e-mail]
> > http://www.softarmor.com/mailman/listinfo/xcon
> >
>
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [e-mail]                     FAX:   [phone]
> http://www.jdrosen.net                      PHONE: [phone]
> http://www.dynamicsoft.com
>

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4JPT325H; Fri, 10 Oct 2003 16:37:59 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9AKYmFh026766; Fri, 10 Oct 2003 16:34:49 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9AKasTv018535; Fri, 10 Oct 2003 15:36:55 -0500
Received: from mail3.dynamicsoft.com ([63.113.44.69]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9AKarTt018532 for <[e-mail]>; Fri, 10 Oct 2003 15:36:53 -0500
Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9AKatUg029160;  Fri, 10 Oct 2003 16:36:56 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2003 16:36:48 -0400
From: Jonathan Rosenberg <[e-mail]>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Burger <[e-mail]>
Subject: Re: [XCON] Candidate floor control message definition language
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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:[e-mail]]
>>Sent: Fri, October 10, 2003 6:31 AM
>>To: [e-mail]
>>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
>>[e-mail]
>>http://www.tech-know-ware.com
>>[phone]
>>=============================================
>>
>>_______________________________________________
>>XCON mailing list
>>[e-mail]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
>>
> 
> 
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4JPT32R5; Fri, 10 Oct 2003 15:17:12 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9AJELKW029800; Fri, 10 Oct 2003 15:14:21 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9AJF6Tv018026; Fri, 10 Oct 2003 14:15:07 -0500
Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h9AJF2Tt018023 for <[e-mail]>; Fri, 10 Oct 2003 14:15:03 -0500
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap  id 23611; Fri, 10 Oct 2003 15:21:35 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1252; format=flowed
Subject: RE: [XCON] Candidate floor control message definition language
Date: Fri, 10 Oct 2003 15:15:01 -0400
Message-ID: <[e-mail]>
Thread-Topic: [XCON] Candidate floor control message definition language
Thread-Index: AcOPGlVI61QcjNDYQCW2ZVVxyLrt/gASEKNw
From: "Eric Burger" <[e-mail]>
To: "Pete Cordell" <[e-mail]>,  [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h9AJF2Tt018023
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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:[e-mail]]
> Sent: Fri, October 10, 2003 6:31 AM
> To: [e-mail]
> 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
> [e-mail]
> http://www.tech-know-ware.com
> [phone]
> =============================================
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
> 


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


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4JPT3HD7; Fri, 10 Oct 2003 06:31:36 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h9AASQFh023962; Fri, 10 Oct 2003 06:28:27 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9AAUTTv015489; Fri, 10 Oct 2003 05:30:31 -0500
Received: from einsteinium.btinternet.com (einsteinium.btinternet.com [194.73.73.147]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h9AAUMTt015477 for <[e-mail]>; Fri, 10 Oct 2003 05:30:27 -0500
Received: from dial81-135-30-179.in-addr.btopenworld.com ([81.135.30.179] helo=tkw) by einsteinium.btinternet.com with smtp (Exim 3.22 #23) id 1A7uWw-00023H-00 for [e-mail]; Fri, 10 Oct 2003 11:29:54 +0100
Message-ID: <009201c38f19$a0cf4b40$0200000a@tkw>
From: "Pete Cordell" <[e-mail]>
To: [e-mail]
Date: Fri, 10 Oct 2003 11:31:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [XCON] Candidate floor control message definition language
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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
[e-mail]
http://www.tech-know-ware.com
[phone]
=============================================

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


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4JPTN8VR; Tue, 7 Oct 2003 15:53:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h97JoE2V009052 for <[e-mail]>; Tue, 7 Oct 2003 15:50:14 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19561; Tue, 7 Oct 2003 15:53:05 -0400 (EDT)
Message-Id: <[e-mail]>
From: The IESG <[e-mail]>
To: "IETF-Announce: ;"
Cc: [e-mail],  [e-mail],  [e-mail]
Subject: WG Action: Centralized Conferencing (xcon)
Date: Tue, 07 Oct 2003 15:53:05 -0400
Sender: [e-mail]
Content-type: text/plain; charset=windows-1252; format=flowed
MIME-Version: 1.0
Content-transfer-encoding: 8bit

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 <[e-mail]>
Alan Johnston <[e-mail]>

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

Transport Area Advisor:
Allison Mankin <[e-mail]>

Mailing Lists:
General Discussion: [e-mail]
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