Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian comments

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 19 Feb 2015 15:41:19 -0800

A couple of Christian's items remain in discussion...

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, February 16, 2015 7:39 AM
> To: Duckworth, Mark; [email-masked]
> Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20
> 
> >> 4. Section 5 pg15 2nd para: It says all CLUE protocol mechanisms are
> >> optional in the consumer and that it is free to ignore the information.
> >> Whilst its true for the Advertisement I don't think this is generally
> >> true. It shouldn't ignore the Options message.
> > [Duckworth, Mark] I think it's okay the way it is.  The protocol document
> has the details.
> [CNG] Then why don't we remove the sentence and really leave it up to
> the protocol document? I think we're really only talking about the
> Advertisement and even for that is it true. i.e. the Consumer shouldn't
> ignore the "allow subset choice" parameter.

[Duckworth, Mark] The sentence we are talking about is:
" All CLUE  protocol mechanisms are OPTIONAL in the Consumer in the sense that,
   while the Consumer MUST be able to receive (and, potentially,
   gracefully acknowledge) CLUE messages, it is free to ignore the
   information provided therein."
[Duckworth, Mark] On second thought, I think it is good to remove this
sentence.  But I'm hoping to get more people to agree before I take it out.
The signaling document says the Provider can't send media until it receives
a Configure message.  So I think it really isn't optional at all, and a Consumer
must send a valid Configure message if it wants to receive media.

> >> 6. Section 7.1.1.13: "This attribute is only applicable to video
> >> Captures and presentation streams with visual information." Could this
> >> also be applicable to audio captures? i.e. lyrics along with audio.
> > [Duckworth, Mark] I don't remember why that restriction was added.  Was
> that in your original proposal for this attribute?  It is okay with me to remove
> this sentence.
> [CNG] Yes it was the original based on a comment I received. In
> hindsight I don't think I should have proposed it.

[Duckworth, Mark] We are talking about the "embedded text" attribute.
Based on the description " a Capture provides embedded textual information.
For example the video Capture MAY contain speech to text information
composed with the video image," it still seems to me this applies only to video.
I don't understand how embedded text could be added to an audio encoding in
this sense, as I understood it to mean the text would just appear in the decoded
and rendered media without any additional processing.
Does anybody else want to comment?

---

From: "Roni Even" <[email-masked]>
Date: Fri, 20 Feb 2015 18:56:10 +0200

Hi,
Inline
Roni as individual

> From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
> Sent: 20 February, 2015 1:41 AM
> To: Christian Groves; [email-masked]
> Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian
> comments
> 
> > >> 4. Section 5 pg15 2nd para: It says all CLUE protocol mechanisms
> > >> are optional in the consumer and that it is free to ignore the
information.
> > >> Whilst its true for the Advertisement I don't think this is
> > >> generally true. It shouldn't ignore the Options message.
> > Advertisement and even for that is it true. i.e. the Consumer
> > shouldn't ignore the "allow subset choice" parameter.
> 
> The signaling document says the Provider can't send media until it
receives a
> Configure message.  So I think it really isn't optional at all, and a
Consumer
> must send a valid Configure message if it wants to receive media.
[Roni Even] I am not sure what is discussed, the example " allow subset
choice" given by Christian is sent by the provider and the consumer may
ignore it and not ask for subsets. 
Having said that, reading the paragraph it talks about the renderer in the
consumer and the consumer. I am not sure why we have the distinction since
we are talking about the consumer and it looks to me like the last sentence
in the paragraph is the same as the sentence before that talks about the
renderer in the consumer.
 My reading is that the consumer MUST send at least advertisement
acknowledge (as defined in the CLUE protocol) and may send a configure, this
means the an advertisement may be ignore and not require a configure
message.

Roni 

> > >> Captures and presentation streams with visual information." Could
> > >> this also be applicable to audio captures? i.e. lyrics along with
audio.
> > that in your original proposal for this attribute?  It is okay with me
> > to remove this sentence.
[Roni Even] Looking at previous discussion it said that if we will need
something for audio it will be a new attribute. Anyhow I do not have any
objection to remove the restriction.

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

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 20 Feb 2015 15:04:31 -0800

I plan to submit an updated framework draft around March 3. I'll be on vacation until then. I have several minor updates done, based on latest feedback from Christian and Paul. 

I'm not sure about the first issue about protocol mechanisms being optional.  I've asked Stephan about it, as I think he wrote that part.

I expect for the second issue below, I will remove the restriction (as both Christian and Roni suggest) unless people start objecting.

Mark

> From: Roni Even [mailto:[email-masked]]
> Sent: Friday, February 20, 2015 11:56 AM
> To: Duckworth, Mark; 'Christian Groves'; [email-masked]
> Subject: RE: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian
> comments
> 
> Hi,
> Inline
> Roni as individual
> 
> > " All CLUE  protocol mechanisms are OPTIONAL in the Consumer in the
> sense
> > that,
> > I don't understand how embedded text could be added to an audio
> encoding
> in

---

From: "Roni Even" <[email-masked]>
Date: Sun, 22 Feb 2015 09:19:28 +0200

Mark thanks,
My comment about the first issue was that a consumer getting a new
advertisement have to acknowledge it but is not required to send a configure
if no change is needed.  I agree that the text is not clear enough, so maybe
clarifying what optional means is another way to address the issue and it
will be good to get more opinions specially from Stephan

Roni

> From: Duckworth, Mark [mailto:[email-masked]]
> Sent: 21 February, 2015 1:05 AM
> To: Roni Even; 'Christian Groves'; Stephan Wenger ([email-masked])
> Cc: [email-masked]
> I plan to submit an updated framework draft around March 3. I'll be on
> vacation until then. I have several minor updates done, based on latest
> feedback from Christian and Paul.
> 
> I'm not sure about the first issue about protocol mechanisms being
optional.
> I've asked Stephan about it, as I think he wrote that part.
> 
> I expect for the second issue below, I will remove the restriction (as
both
> Christian and Roni suggest) unless people start objecting.
> 
> Mark
> 
> > Subject: RE: [clue] short WGLC on draft-ietf-clue-framework-20 -
> > Christian comments
> >
> > Hi,
> > Inline
> > Roni as individual
> >
> > > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 -
> > > Christian comments
> > >
> > > > >> 4. Section 5 pg15 2nd para: It says all CLUE protocol
> > > > >> mechanisms are optional in the consumer and that it is free to
> > > > >> ignore the
> > information.
> > > > [CNG] Then why don't we remove the sentence and really leave it up
> > > > to the protocol document? I think we're really only talking about
> > > > the Advertisement and even for that is it true. i.e. the Consumer
> > > [Duckworth, Mark] On second thought, I think it is good to remove
> > > this sentence.  But I'm hoping to get more people to agree before I
> > > take it
> > out.
> > [Roni Even] I am not sure what is discussed, the example " allow
> > subset choice" given by Christian is sent by the provider and the
> > consumer may ignore it and not ask for subsets.
> > Having said that, reading the paragraph it talks about the renderer in
> > the consumer and the consumer. I am not sure why we have the
> > distinction since we are talking about the consumer and it looks to me
> > like the last sentence in the paragraph is the same as the sentence
> > before that talks about the renderer in the consumer.
> > acknowledge (as defined in the CLUE protocol) and may send a
> > configure, this means the an advertisement may be ignore and not
> > require a configure message.
> >
> > Roni
> >
> > >
> > > > >> 6. Section 7.1.1.13: "This attribute is only applicable to
> > > > >> video Captures and presentation streams with visual
> > > > >> information." Could this also be applicable to audio captures?
> > > > >> i.e. lyrics along with
> > audio.
> > > > that in your original proposal for this attribute?  It is okay
> > > > with me to remove this sentence.
> > > composed with the video image," it still seems to me this applies
> > > only to
> > video.
> > > this sense, as I understood it to mean the text would just appear in
> > > the
> > decoded
> > [Roni Even] Looking at previous discussion it said that if we will
> > need something for audio it will be a new attribute. Anyhow I do not
> > have any objection to remove the restriction.
> >
> > >