Subject: RE: [XCON] XCON Agenda Requests

From: "Chris Boulton" <[email-masked]>
Date: Thu, 2 Mar 2006 10:18:21 -0000

This is a good list which unfortunately has not been commented on - I
believe that if we do nothing else in Dallas we must leave the room with
this resolved.  I'm pretty sure, as I originally started the main
discussion with a proposal, that folks know my feelings.  It must be
remembered that even though list activity has been low, there are folks
discussing behind the scenes who are willing and waiting to get this
work done - we just need to get over this hurdle to make the effort
worthwhile.

Chris.

I would second that and add that there are probably a number of
sub-decisions that need to be made as well in support of a final
decision on the control protocol:

1) Encoding: Binary, Text, or Both?
2) Operations: What is a reasonable list of operations that need to be
supported in the first version of the protocol? 
3) Multimedia: Is this just for audio/video or are we truly building a
multimedia capable protocol?
4) Mobile:  Is this just for mobile devices or are we truly building an
intelligent endpoint capable protocol?
5) Best Practices: What practical implementation experience using BFCP
or the conference event package can we leverage while designing the
protocol?

/sean

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Monday, February 27, 2006 3:33 AM
To: Adam Roach; [email-masked]
Cc: Alan Johnston
Subject: RE: [XCON] XCON Agenda Requests

We had an excellent discussion on the Control Protocol recently and if
this work is to move forward we just need to bite the bullet and make a
decision.  

There are folks ready and waiting to get this work completed but this is
a real sticking point for progress.

Chris.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: 26 February 2006 20:13
To: [email-masked]
Cc: Alan Johnston
Subject: [XCON] XCON Agenda Requests

[as chair]

Anyone who would like agenda time during XCON at the upcoming 65th IETF
meeting, please send me and Alan an email by Wednesday, March 8th;
include a draft name and an approximate amount of time that you believe
discussion will take. Thanks.

/a

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

Information contained in this e-mail and any attachments are intended
for the use of the addressee only, and may contain confidential
information of Ubiquity Software Corporation.  All unauthorized use,
disclosure or distribution is strictly prohibited.  If you are not the
addressee, please notify the sender immediately and destroy all copies
of this email.  Unless otherwise expressly agreed in writing signed by
an officer of Ubiquity Software Corporation, nothing in this
communication shall be deemed to be legally binding.  Thank you.

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

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

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

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 2 Mar 2006 11:34:38 -0000

I just noticed that Chris's email mentioned that one of the points for 
debate was whether the XCON 'protocol' should be Binary, Text, or Both.  I 
just wanted to mention that, as well as a text encoding, Lumas also has 
binary encoding rules.

As already mentioned, there is already code to convert a Lumas definition 
into ABNF, and conceivably code could be written to convert Lumas into 
ASCII-art style drawings similar to that used in BFCP.

Hence, by using a higher level of abstraction like Lumas you can make such 
details as text vs. binary vs. ABNF vs. ASCII-art an implementation detail!

As before, more info on Lumas is at: http://www.tech-know-ware.com/lumas

Regards,

Pete.

P.S. Further to my previous e-mail, to give you another idea of how a 
standard Lumas text message might look compared to other encodings, I've dug 
out a file I created a long time back that compares an old SIP message 
encoded using 'ABNF', Lumas and XML.  Obviously in the latter 2 cases there 
are a number of ways that the encoding could have been done, so they should 
be considered for guidance only!  Note also that in the case of Lumas and 
XML, line breaks have no significance so the line breaks shown are 
effectively pretty-print issues.  Additionally, if I was doing a Lumas 
encoding of SIP I would have used shorter tag/header names more along the 
lines of SDP, but again, that's an implementation issue.

----------------- 'ABNF' ---------------------

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:[email-masked]>
To: T. Watson <sip:[email-masked]>
Call-ID: [email-masked]
CSeq: 1 INVITE
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: 111

v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
s=Mr. Watson, come here.
c=IN IP4 kton.bell-tel.com
m=audio 3456 RTP/AVP 0 3 4 5

--------------- LUMAS ------------------------

INVITE={sip:[email-masked] SIP/2.0
Via={SIP/2.0/UDP kton.bell-tel.com}
From={sip:[email-masked] "A. Bell"}
To={sip:[email-masked] "T. Watson"}
Call-ID=[email-masked]
CSeq={1 INVITE }
Subject="Mr. Watson, come here."
Content-Type=application/sdp
}
SDP={
v=0
o={bell 53655765 2353687637 IN=IP4=128.3.4.5}
s="Mr. Watson, come here."
c={IN=IP4=kton.bell-tel.com}
m={audio 3456 RTP=AVP 0,3,4,5}
}

--------------- XML ----------------------

<SIP proto="SIP/2.0">
<INVITE uri="sip:[email-masked]">
<Via proto="SIP/2.0/UDP" return="kton.bell-tel.com"/>
<From name="A. Bell" addr="sip:[email-masked]"/>
<To name="T. Watson" addr="sip:[email-masked]"/>
<Call-ID>[email-masked]</Call-ID>
<CSeq seq="1" method="INVITE">
<Subject>Mr. Watson, come here.</subject>
<Content-Type value="application/sdp"/>
<Content-Length value="111"/>
</INVITE>
<SDP v="0"
<o username="bell" sesseionid="53655765" version="2353687637 nettype="IN" 
addrtype="IP4" address="128.3.4.5"/>
<s>Mr. Watson, come here.</s>
<c nettype="IN" addrtype="IP4" address="kton.bell-tel.com"/>
<m type="audio" port="3456" transport="RTP/AVP">
   <m>0</m><m>3</m><m>4</m><m>5</m>
</sdp>
</SIP>
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit
                         http://www.tech-know-ware.com/lmx
                         (or http://www.xml2cpp.com)
=============================================

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 3 Mar 2006 13:20:15 -0000

Hi all,

So that it is easier to experiment with, I have put a web interface version 
of the Lumas 2 ABNF converter on-line.  You can see it at:

http://tech-know-ware.com/lumas/2abnf.cgi

The output could be tarted up, and there may be some errors in it, but I 
think it shows the principle.

I've also put up an on-line definition checker at:

http://tech-know-ware.com/lumas/check.cgi

Regards,

Pete.

---

From: "Pete Cordell" <[email-masked]>
Date: Sun, 5 Mar 2006 20:23:29 -0000

Dear all,

I've now put on-line a Lumas to C compiler.  This can be accessed at:

http://tech-know-ware.com/lumas/2c.cgi

Enter a Lumas definition and it will generate a corresponding C .h file and 
C .c file.

This is far from commercial grade code (and most people would prefer Java / 
C++ / C# I guess), but once again, hopefully it shows the principle.

One of the main limitations is the lack of documentation.  Basically to 
encode a message you'd populate an instance of the C struct appropriately 
and then call the corresponding write routine.  Similarly, when decoding a 
message, you'd call the appropriate read function and then interact with the 
resulting populated struct.

If you do want to use the generated code, you will need to compile and link 
it with the code in the ZIP file mentioned when you get the C results.

Regards,

Pete.

----- Original Message ----- 
From: "Pete Cordell" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 03, 2006 1:20 PM
Subject: [XCON] On-line Lumas 2 ABNF Converter

> Hi all,
>
> So that it is easier to experiment with, I have put a web interface 
> version of the Lumas 2 ABNF converter on-line.  You can see it at:
>

---

From: "Pete Cordell" <[email-masked]>
Date: Sun, 5 Mar 2006 20:30:51 -0000

I've submitted a refreshed draft of the Lumas spec to replace the expired 
version.  Until it becomes available in the archives, you can get it here:

http://www.tech-know-ware.com/lumas/draft-cordell-lumas-04.txt

Thanks,

Pete.

---

From: Adam Roach <[email-masked]>
Date: Mon, 13 Mar 2006 16:23:25 -0600

[as chair]

While the Developer in me thinks Lumas looks really cool and would be a 
barrel of monkeys to play around with, the Working Group Chair in me 
requires me to exclude it from consideration. After floundering in this 
area for a while, we had a deadline a few months ago on new proposals 
for the conference manipulation protocol.

Consequently, we cannot take on additional candidates at this time. The 
protocol will be selected from the set of CCCP, CSCP, or some variant on 
the SOAP proposals.

/a

Pete Cordell wrote:

> debate was whether the XCON 'protocol' should be Binary, Text, or 
> Both.  I just wanted to mention that, as well as a text encoding, 
> Lumas also has binary encoding rules.
>
> As already mentioned, there is already code to convert a Lumas 
> definition into ABNF, and conceivably code could be written to convert 
> Lumas into ASCII-art style drawings similar to that used in BFCP.
>
> Hence, by using a higher level of abstraction like Lumas you can make 
> such details as text vs. binary vs. ABNF vs. ASCII-art an 
> implementation detail!
>
> standard Lumas text message might look compared to other encodings, 
> I've dug out a file I created a long time back that compares an old 
> SIP message encoded using 'ABNF', Lumas and XML.  Obviously in the 
> latter 2 cases there are a number of ways that the encoding could have 
> been done, so they should be considered for guidance only!  Note also 
> that in the case of Lumas and XML, line breaks have no significance so 
> the line breaks shown are effectively pretty-print issues.  
> Additionally, if I was doing a Lumas encoding of SIP I would have used 
> shorter tag/header names more along the lines of SDP, but again, 
> that's an implementation issue.
>
> <o username="bell" sesseionid="53655765" version="2353687637 
> nettype="IN" addrtype="IP4" address="128.3.4.5"/>

---

From: Adam Roach <[email-masked]>
Date: Mon, 13 Mar 2006 16:24:10 -0600

[as chair]

/a

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 17 Mar 2006 13:37:11 -0000

Hi Adam,

Thanks for the feedback.  However, I think you've mis-understood where Lumas 
fits in.  It is essentially a alternative for XSD and does not compete with 
the likes of CCCP, CPCP etc.  Rather these protocols could use Lumas instead 
of XSD if they wished.  Lumas is related to the encoding debate, which still 
seems very active from what I can see.

Pete.

----- Original Message ----- 
From: "Adam Roach" <[email-masked]>
To: "Pete Cordell" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 13, 2006 10:24 PM
Subject: Re: [XCON] Encoding: Binary, Text, or Both and Lumas

>> debate was whether the XCON 'protocol' should be Binary, Text, or Both. 
>> I just wanted to mention that, as well as a text encoding, Lumas also has 
>> binary encoding rules.
>>
>> such details as text vs. binary vs. ABNF vs. ASCII-art an implementation 
>> detail!
>>
>> standard Lumas text message might look compared to other encodings, I've 
>> dug out a file I created a long time back that compares an old SIP 
>> message encoded using 'ABNF', Lumas and XML.  Obviously in the latter 2 
>> cases there are a number of ways that the encoding could have been done, 
>> so they should be considered for guidance only!  Note also that in the 
>> case of Lumas and XML, line breaks have no significance so the line 
>> breaks shown are effectively pretty-print issues.  Additionally, if I was 
>> doing a Lumas encoding of SIP I would have used shorter tag/header names 
>> more along the lines of SDP, but again, that's an implementation issue.
>>