Subject: Re: [clue] purpose attribute - Review of framework-03

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 13 Feb 2012 07:47:16 -0800

Hi Roni,

Thanks for all the comments.  We'll start addressing different topics in different email threads.

I was thinking the media capture purpose attribute really should mean the same thing as the SDP content attribute in RFC4796.  Can CLUE just refer to RFC4796 for the definition of the purpose attribute values?  RFC4796 already has an extension mechanism, so we can add new values when needed.

Mark

===================================
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Wednesday, February 08, 2012 8:49 AM
To: [email-masked]
Subject: [clue] Review of draft-ietf-clue-framework-03

6.  In section 6.1.1 I suggest adding one more purpose "SL" for sign language indicating that this is the sign language representation of the audio stream, see RFC4796.

Thanks
Roni Even

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 29 Feb 2012 06:53:30 -0800

Does anybody have a comment or suggestion about this idea?
For the framework document, I'm proposing that instead of defining our own values for the media capture purpose attribute, instead we refer to RFC4796 and use those values that are already defined.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Duckworth, Mark
> Sent: Monday, February 13, 2012 10:47 AM
> To: Roni Even; [email-masked]
> Subject: Re: [clue] purpose attribute - Review of framework-03
> 
> Hi Roni,
> 
> I was thinking the media capture purpose attribute really should mean the
> same thing as the SDP content attribute in RFC4796.  Can CLUE just refer to
> RFC4796 for the definition of the purpose attribute values?  RFC4796 already
> has an extension mechanism, so we can add new values when needed.
> 
> Mark
> 
> 6.  In section 6.1.1 I suggest adding one more purpose "SL" for sign language
> indicating that this is the sign language representation of the audio stream,
> see RFC4796.
> 
> Thanks
> Roni Even
> 
> 
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Roni Even" <[email-masked]>
Date: Wed, 29 Feb 2012 17:01:10 +0200

Mark,
I am OK with this.
Roni

> Sent: Wednesday, February 29, 2012 4:54 PM
> To: [email-masked]
> For the framework document, I'm proposing that instead of defining our
> own values for the media capture purpose attribute, instead we refer to
> RFC4796 and use those values that are already defined.
> 
> Mark
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Duckworth, Mark
> > I was thinking the media capture purpose attribute really should mean
> > the same thing as the SDP content attribute in RFC4796.  Can CLUE
> just
> > refer to
> > RFC4796 for the definition of the purpose attribute values?  RFC4796
> > already has an extension mechanism, so we can add new values when
> needed.
> >
> > Mark
> >
> > 6.  In section 6.1.1 I suggest adding one more purpose "SL" for sign
> > language indicating that this is the sign language representation of
> > the audio stream, see RFC4796.
> >
> > Thanks
> > Roni Even
> >
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Feb 2012 10:48:19 -0500

> For the framework document, I'm proposing that instead of defining our own values for the media capture purpose attribute, instead we refer to RFC4796 and use those values that are already defined.

It appears 4796 is no less vague about the semantics of the values as we 
have been so far. And 4796 has an IANA registry and provision to add new 
values via another RFC, so we can add new ones if we need them.

But its not enough if we want individual implementations and/or 
deployments to be able to specify their own values.

Note that 4795 allows multiple instances of mediacnt-tag to be attached 
to a single stream. (E.g. "a=content: main, speaker") This could help 
when more than one apply to the stream. So clue might need to also allow 
this.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Wed, 29 Feb 2012 18:38:47 +0200

Hi,
RFC 4795 defines an attribute that can be used to specify the semantics of
the stream. The usage is left for application specific document that will
provide the interoperability specification.
It will be good to use the defined values and the IANA registry since we are
also talking in CLUE about multiple streams with different content. The
framework should explain how to use the values from RFC 4795
Roni

> Paul Kyzivat
> Sent: Wednesday, February 29, 2012 5:48 PM
> To: [email-masked]
> > For the framework document, I'm proposing that instead of defining
> our own values for the media capture purpose attribute, instead we
> refer to RFC4796 and use those values that are already defined.
> 
> It appears 4796 is no less vague about the semantics of the values as
> we have been so far. And 4796 has an IANA registry and provision to add
> new values via another RFC, so we can add new ones if we need them.
> 
> when more than one apply to the stream. So clue might need to also
> allow this.
> 
> 	Thanks,
> 	Paul
> 
> > Mark
> >
> >> Thanks for all the comments.  We'll start addressing different
> topics
> >> in different email threads.
> >>
> >> just refer to
> >> Of Roni Even

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Wed, 29 Feb 2012 19:42:47 +0100

I agree that we should reuse the definition from RFC4796. 

Maybe CLUE should change the name of the purpose attribute to content to
follow RFC4796. Avoiding confusion is important. 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: 29. februar 2012 17:39
To: 'Paul Kyzivat'; [email-masked]
Subject: Re: [clue] purpose attribute - Review of framework-03

Hi,
RFC 4795 defines an attribute that can be used to specify the semantics
of the stream. The usage is left for application specific document that
will provide the interoperability specification.
It will be good to use the defined values and the IANA registry since we
are also talking in CLUE about multiple streams with different content.
The framework should explain how to use the values from RFC 4795 Roni

> Of Paul Kyzivat
> we have been so far. And 4796 has an IANA registry and provision to 
> add new values via another RFC, so we can add new ones if we need
them.
> Note that 4795 allows multiple instances of mediacnt-tag to be 
> attached to a single stream. (E.g. "a=content: main, speaker") This 
> could help when more than one apply to the stream. So clue might need 
> to also allow this.
> 
> 	Thanks,
> 	Paul
> 
> > Mark
> >
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Duckworth, Mark
> >> RFC4796 for the definition of the purpose attribute values?  
> >> RFC4796 already has an extension mechanism, so we can add new 
> >> values when
> needed.
> >>
> >> Mark
> >>
> >> 6.  In section 6.1.1 I suggest adding one more purpose "SL" for 
> >> sign language indicating that this is the sign language 
> >> representation of the audio stream, see RFC4796.
> >>
> >> Thanks
> >> Roni Even
> >>
> >>
> >>