Re: [MMUSIC] draft-garcia-mmusic-sdp-misc-cap-00. About "icap"

["Ingemar Johansson S" <[e-mail]>]

WARNING: contains banned part

--- Begin Message ---

Hi
 
I believe that the icap attribute can be useful, also I don't see it as controversial as it is after all as Miguel points out only meant for human consumption.
FYI icap was also inlcuded in the examples in a 3GPP SA4 submission and the reason was simply to make things easier to read (problems with email and internet connectivity makes it difficult for me to give the link to the submission right now..)
 
 
Regards
Ingemar
 
Original message below
=====================================
 
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Miguel A. Garcia
Sent: den 18 november 2008 10:06
To: mmusic
Cc: Joerg Ott
Subject: [MMUSIC] draft-garcia-mmusic-sdp-misc-cap-00. About "icap"

Yesterday we had a discussion about the Miscellaneous Capabilities
draft, and there was a question about the "icap" capability. I was
listening to the audio stream and posted some comments on the chat room,
but let me try to clarify the issue.

The "icap" capability allows to express media "i" lines as capabilities.

Bear in mind that the "i" line is intended for human consumption, so,
there are no semantics added to it, other than provide a human readable
description of the media stream. If we wanted to get a user agent to
consume the information, we should be using the "label" attribute
specified in RFC 4574.

So, considering that the i line is for human consumption, people would
ask whether there is a need for expressing it as a capability. The
authors discussed this issue and came up with a use case where a user
would offer several alternative media streams and could indicate in the
i/icap line some information about what is in that media stream. For
example, one could indicate that a video stream contains a close-up of
the presenter versus a general room, or an audio stream could contain
the original movie audio track versus the director's commentary. This
could help the answerer to select the appropriate alternative media
stream.

Obviously this require the endpoint to be able to present this
information to the end user. Honestly, I don't know of any endpoint that
allows the user to write an i line, or which displays it to the end
user.=20
  That might be the weakest selling point of this idea. But technically
it makes sense.

What do people think? What should we do in the next revision of the
document, should we keep the icap line (and add the use case
description), or should we remove it?

Thanks,

         Miguel
--
Miguel A. Garcia
[phone]
Ericsson Spain
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic

--- End Message ---

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic