Subject: Re: [clue] New Version Notification for draft-ietf-clue-signaling-02.txt

From: Paul Kyzivat <[email-masked]>
Date: Sat, 05 Jul 2014 12:38:41 -0400

Thanks Rob!

Just a couple of little things in the new version:

Section 4.5.2.3:

I question whether anything in this section should be normative.

As best I can tell this section simply discusses implementation choices 
that may be made. Ultimately the receiver might choose to accept the 
initial media or not. And what it does with the media is its business. 
Nothing normative to test here.

The one thing that perhaps should be normative is that the endpoints 
SHOULD NOT get upset and drop the call simply because the initial media 
has been rejected.

Section 5.1:

    ... A CLUE-capable implementation MUST
    not reject CLUE protocol messages that contain <encID> elements that
    do not match an id in SDP.

While it seems evident what this is intended to mean, when taken 
literally it might seem to say that if there are encID elements that 
don't match, then the message must not be rejected even for some other 
reason. Also, "MUST not" isn't good form. I suggest

    ... A CLUE-capable implementation MUST
    NOT reject a CLUE protocol message solely because it contains
    <encID> elements that do not match an id in SDP.

	Thanks,
	Paul

---

From: Robert Hansen <[email-masked]>
Date: Mon, 07 Jul 2014 14:01:59 +0100

Hi Paul,

Comments in-line,
On 05/07/14 17:38, Paul Kyzivat wrote:
> As best I can tell this section simply discusses implementation 
> choices that may be made. Ultimately the receiver might choose to 
> accept the initial media or not. And what it does with the media is 
> its business. Nothing normative to test here.
>
> SHOULD NOT get upset and drop the call simply because the initial 
> media has been rejected.

Fair enough - the aim was to make clear to readers that some 
implementations might want to display an initial audio/video stream 
before the CLUE media was sorted out, while others might want to wait 
until CLUE media was sorted out before starting it up. And that in the 
latter case the initial answer was  a good place to not accept this media.

As you say, there's not much normative that can be said there, and it 
might be best to just ensure that people don't drop the call if they are 
in one mode and the far end is in the other.

>    <encID> elements that do not match an id in SDP.

[Rob] Agreed - didn't consider this interpretation, will go with your 
suggested text.

>     Thanks,
>     Paul
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue