Subject: [clue] Fwd: New Version Notification for draft-groves-clue-latent-config-00.txt

From: Christian Groves <[email-masked]>
Date: Sun, 26 Jan 2014 22:08:23 +1100

Hello

I've submitted a draft regarding the CLUE signalling proposing the use 
of SDP latent configurations to describe the encodings. I think there 
are some benefits over the use of a separate m-line for each encoding.

Comments?

Regards, Christian

-------- Original Message --------
Subject: 	New Version Notification for 
draft-groves-clue-latent-config-00.txt
Date: 	Sun, 26 Jan 2014 03:05:37 -0800
From: 	[email-masked]
To: 	Weiwei Yang <[email-masked]>, "Weiwei Yang" <[email-masked]>, 
"Roni Even" <[email-masked]>, Roni Even 
<[email-masked]>, Christian Groves 
<[email-masked]>, "Christian Groves" 
<[email-masked]>

A new version of I-D, draft-groves-clue-latent-config-00.txt
has been successfully submitted by Christian Groves and posted to the
IETF repository.

Name:		draft-groves-clue-latent-config
Revision:	00
Title:		CLUE and latent configurations
Document date:	2014-01-26
Group:		Individual Submission
Pages:		13
URL:            http://www.ietf.org/internet-drafts/draft-groves-clue-latent-config-00.txt
Status:         https://datatracker.ietf.org/doc/draft-groves-clue-latent-config/
Htmlized:       http://tools.ietf.org/html/draft-groves-clue-latent-config-00

Abstract:
    This document proposes to use Latent Configurations as described by
    the SDP media capability negotiation framework [RFC6871] for the
    description and negotiation of CLUE encodings.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Robert Hansen <[email-masked]>
Date: Mon, 27 Jan 2014 14:58:43 +0000

Hi Christian,

I think it looks good, though my initial question would be whether the 
benefits outweight the added complexity of CapNeg.

The 'how much of an issue are the extra m=lines of the current approach' 
question is much the same we had when we were weighing using SDP against 
putting the information in CLUE; at the time most people felt the issues 
with using SDP m=lines were not particularly onerous (particularly if 
BUNDLE is used to ameleorate ICE costs and the like). This provides an 
intriguing way of using SDP and still avoiding some of those issues 
though (at the cost of more complicated SDP syntax).

I'll have more specific comments and questions when I have had time to 
properly work through it.

Rob

On 26/01/2014 11:08, Christian Groves wrote:
> To:     Weiwei Yang <[email-masked]>, "Weiwei Yang"
> <[email-masked]>, "Roni Even" <[email-masked]>, Roni Even
> URL:
> http://www.ietf.org/internet-drafts/draft-groves-clue-latent-config-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-groves-clue-latent-config/
> Htmlized:
> http://tools.ietf.org/html/draft-groves-clue-latent-config-00
>
>
> Abstract:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Tue, 28 Jan 2014 14:09:16 +1100

Hello Rob,

Thanks for the comment. I think the difference to the question about 
extra m=lines vs putting it in CLUE is that the latest configuration 
method already exists and utilizes SDP. It means we that don't have to 
come up with our own CLUE syntax for encoding. We can simply use what is 
existing.

Regards, Christian

On 28/01/2014 1:58 AM, Robert Hansen wrote:
> The 'how much of an issue are the extra m=lines of the current 
> approach' question is much the same we had when we were weighing using 
> SDP against putting the information in CLUE; at the time most people 
> felt the issues with using SDP m=lines were not particularly onerous 
> (particularly if BUNDLE is used to ameleorate ICE costs and the like). 
> This provides an intriguing way of using SDP and still avoiding some 
> of those issues though (at the cost of more complicated SDP syntax).
>