Subject: [clue] Fwd: New Version Notification for draft-wenger-clue-transport-02.txt

From: Marshall Eubanks <[email-masked]>
Date: Mon, 12 Mar 2012 17:59:34 -0400

For your reading pleasure.

Naturally, I have already caught a typo.

Regards
Marshall

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Mon, Mar 12, 2012 at 5:28 PM
Subject: New Version Notification for draft-wenger-clue-transport-02.txt
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]

A new version of I-D, draft-wenger-clue-transport-02.txt has been
successfully submitted by Marshall Eubanks and posted to the IETF
repository.

Filename:        draft-wenger-clue-transport
Revision:        02
Title:           Transport Options for Clue
Creation date:   2012-03-12
WG ID:           Individual Submission
Number of pages: 13

Abstract:
  This memo describes the assumption and the proposed options for the
  coding and transport of CLUE messages as outlined in version 01 of
  the framework draft.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2012 19:15:19 -0400

Section 3.1.2

Title is "Using an SDP MIME body to carry the CLUE information in an 
INVITE or UPDATE exchange". This should not mention SDP. (Its a non-SDP 
MIME body that is being proposed.)

The concern about using UPDATE may be over stated. CLUE messages aren't 
negotiated - they're declarative - so there is no need to figure out 
anything before responding. There may be some desire to piggyback CLUE 
messages on the UPDATE responses to minimize traffic, but that can be 
optional, to be used if there is something ready to be sent.

Section 5: Clue Discovery

Another possibility not mentioned is to use a sip option tag for this. 
It allows signaling support using the Supported header, and required 
support using the Required header. (This can be useful if you don't want 
to call to succeed unless CLUE is supported.

Also, sip caller capabilities feature tags could be used to indicate 
support and, using callerprefs mechanisms, to direct the initial 
preferentially to a CLUE supporting device. Note that something related 
to this (a proposed "immersive" feature tag) is under discussion on the 
dispatch list.

These are not mutually exclusive.

	Thanks,
	Paul (as individual)

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Wed, 21 Mar 2012 22:39:35 +0100

The RTCWeb group are working on defining a generic data channel based on sctp, as defined in: 
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00

It seems that the data channel suggestion from rtcweb matches CLUE transport option 2. 

Has the ongoing rtcweb been considered?

Cheers 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marshall Eubanks
Sent: 12. mars 2012 23:00
To: clue
Subject: [clue] Fwd: New Version Notification fordraft-wenger-clue-transport-02.txt

Regards
Marshall

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Mon, Mar 12, 2012 at 5:28 PM
Subject: New Version Notification for draft-wenger-clue-transport-02.txt
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]

A new version of I-D, draft-wenger-clue-transport-02.txt has been successfully submitted by Marshall Eubanks and posted to the IETF repository.

Filename:        draft-wenger-clue-transport
Revision:        02
Title:           Transport Options for Clue Creation date:   2012-03-12 WG ID:           Individual Submission Number of pages: 13

Abstract:

The IETF Secretariat
_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue