Re: [MMUSIC] RTP taxonomy draft review [Re: Updated MSID draft - version -06]

["DRAGE, Keith (Keith)" <[e-mail]>]

As an individual, I see the taxonomy document as the document other documents will reference for the definitions they use.

i.e. the CLUE, MMUSIC and RTCWEB documents might well have paragraphs in their near the start of their documents that says:

"xx	Definitions

<term1>: see draft-ietf-avtext-taxonomy
<term2>: see draft-ietf-avtext-taxonomy

Therefore it really needs to be published as soon as we want to publish the first of those other documents. That first document may well not be a CLUE document.

Some of the backward type references you identify could well be examples, so these will be informative (as currently given), and therefore not necessary to hold in relation to publication.

Regards

Keith

> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of 
> Paul Kyzivat
> Sent: 30 June 2014 18:53
> To: [e-mail]
> Subject: Re: [MMUSIC] RTP taxonomy draft review [Re: Updated 
> MSID draft - version -06]
> 
> I haven't fully reviewed it. But I've been checking alignment 
> with clue usage. And one question I have is which way 
> references should point.
> 
> Right now the taxonomy has a section called Mapping from 
> Existing Terms. 
> This has come CLUE terms in it, and effectively defines them 
> relative to the terms defined in the concepts section. Some 
> of these definitions are different in detail from those in 
> the CLUE documents, though for the most part the same in spirit.
> 
> Obviously this can only be done for usages that are known 
> before the taxonomy is finally published as an RFC. After 
> that, documents that define their own terms relative to the 
> taxonomy will have to publish the relationship in their own document.
> 
> What should we do in our effort to rationalize the clue 
> terminology with the taxonomy?
> 
> - copy the description of the clue term from the taxonomy into the
>    clue documents, and retain it in the taxonomy.
> 
> - remove the description of the clue term from the taxonomy and put
>    an appropriate definition into the clue docs, relating to the
>    terms defined in the concepts section of the taxonomy.
> 
> Note that we may want to delay the publication of the 
> taxonomy until this can be completed.
> 
> Also, CLUE has been using the term MCU, which wasn't defined 
> in the taxonomy, but has since been added. The taxonomy 
> definition looks good, better than the one currently in clue. 
> But the clue definition is specialized to clue, in that we 
> assume the MCU is capable of supporting the CLUE features.
> 
> ISTM that for this one the "right" answer is for clue to 
> define a new term (e.g., CLUE-MCU) that is a specialization 
> of the taxonomy definition of MCU. That unfortunately means 
> we will have to update all of our documents.
> 
> This seems to be something that will come up a lot in general 
> - specializations of concepts that are generic in the 
> taxonomy.  I wonder if the taxonomy should talk about this.
> 
> 	Thanks,
> 	Paul
> 
> On 6/27/14 11:18 AM, Flemming Andreasen wrote:
> > [updated subject]
> >
> > Per Keith's question below, has anybody in the MMUSIC group 
> reviewed 
> > the RTP taxonomy draft:
> >
> > 
> https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxono
> > my/
> >
> > If so, please let the group and chairs know.
> >
> > Thanks
> >
> > -- Flemming
> >
> >
> > On 6/27/14, 9:46 AM, DRAGE, Keith (Keith) wrote:
> >> The timeline for the taxonomy draft is that it is 
> essentially ready 
> >> for WGLC as soon as enough CLUE, RTCWEB and MMUSIC people 
> have looked 
> >> at it to say it is consistent with the documentation in that WG.
> >>
> >> Is anyone reviewing (or indeed has reviewed it) from the MMUSIC 
> >> perspective, or in respect of specific documents in the MMUSIC 
> >> working group.
> >>
> >> Keith
> >>
> >>> -----Original Message-----
> >>> From: mmusic [mailto:[e-mail]] On Behalf Of Harald 
> >>> Alvestrand
> >>> Sent: 27 June 2014 09:42
> >>> To: Suhas Nandakumar; Flemming Andreasen
> >>> Cc: [e-mail]
> >>> Subject: Re: [MMUSIC] Updated MSID draft - version -06
> >>>
> >>> Just a quick reply to the general comments...
> >>>
> >>>
> >>> On 06/27/2014 09:56 AM, Suhas Nandakumar wrote:
> >>>
> >>>
> >>>     Hello Harald
> >>>
> >>>       Thanks for the work on this draft. Below are few thoughts 
> >>> inline
> >>>
> >>>     * General Comment:
> >>>          + We might want to use RTP Taxonomy throughout
> >>>
> >>>
> >>> Yes. When the concepts are the same, we should. (what's 
> the timeline 
> >>> for the RTP taxonomy?) Can you help find terms that are not used 
> >>> identically with Taxonomy?
> >>>
> >>>
> >>>
> >>>          + Replace MediaStream with "WebRTC MediaStream" 
> for clarity
> >>>          + Replace MediaStreamTrack with "WebRTC 
> MediaStreamTrack" 
> >>> clarity
> >>>
> >>>
> >>> I would push back on that in any section where the 
> section title or 
> >>> the same sentence includes "WebRTC".
> >>>
> >>> So far "MediaStreamTrack" is used in the intro (WebRTC in 
> the same 
> >>> sentence), section 1.1 (ditto), section 1.3 (WebRTC in heading), 
> >>> section 4 (WebRTC in heading).
> >>>
> >>> So the only usage concerned would be in Appendix B.
> >>>
> >>>
> >>>
> >>>          + m-line usage , can it be changed to m=line instead
> >>>
> >>>
> >>> I don't understand this comment - it is highly unusual to 
> use the = 
> >>> sign to denote compound words.
> >>> It is possible that most occurences should be replaced 
> with "media 
> >>> section". Would that be more readable?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 1.1
> >>>     This document adds a new Session Description Protocol
> >>> (SDP) Grouping[RFC5888]
> >>> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC58
> >>> 88>  relation between SDP m-lines [RFC4566]
> >>> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC45
> >>> 66>  that can associate application layer identifiers with
> >>> the binding between media streams, attaching identifiers to the 
> >>> media streams and attaching identifiers to the groupings 
> they form.
> >>>
> >>>
> >>>     [Suhas] I am assuming we are referring to RTP Stream here
> >>>
> >>>
> >>> Since "RTP Stream" is not a defined term in 
> >>> draft-ietf-avtext-rtp-grouping-taxonomy - yes, I mean a packet 
> >>> stream, which RFC 3550 sometimes refers to as "media stream".
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Section 1.2
> >>>     SDP gives a description based on m-lines. According 
> to the model 
> >>> used in [I-D.ietf-rtcweb-jsep] 
> >>> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> >>> etf-rtcweb-jsep> , each m-line describes exactly one media
> >>> source, and if mulitple media sources are carried in an 
> RTP session, 
> >>> this is signalled using BUNDLE 
> >>> [I-D.ietf-mmusic-sdp-bundle-negotiation]
> >>> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> >>> etf-mmusic-sdp-bundle-negotiation> ; if BUNDLE is not used,
> >>> each media source is carried in its own RTP session.
> >>>
> >>>     [Suhas] suggest updating the above para as
> >>>
> >>>
> >>>     " SDP gives a description based on m-lines. According to the 
> >>> model used in [I-D.ietf-rtcweb-jsep] 
> >>> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> >>> etf-rtcweb-jsep> , each m-line describes exactly one media
> >>> source (WebRTC MediaStreamTrack), and if multiple media 
> sources are 
> >>> carried in an RTP session, this is signaled using BUNDLE 
> >>> [I-D.ietf-mmusic-sdp-bundle-negotiation]
> >>> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> >>> etf-mmusic-sdp-bundle-negotiation>  mechanism ; if BUNDLE is
> >>> not used, each media source is carried in its own RTP session."
> >>>
> >>>
> >>>
> >>> Section 1.2 is not WebRTC specific, so should not use 
> WebRTC terms. 
> >>> The model used in JSEP doesn't have an independent formulation, 
> >>> unfortunately, but the main thrust of the argument for 
> adopting it 
> >>> is that this is the model used by a significant portion 
> of existing 
> >>> applications, so adopting that model for JSEP enhances 
> >>> interoperability.
> >>>
> >>> "Media source" is a defined term in -taxonomy-.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Section 1.2 Para 4
> >>>     [Suhas] Para 3 doesn't force the need for a new 
> mechanism and it 
> >>> is probably a good idea to add more clarity in Para4 to 
> clarify the 
> >>> need as below"
> >>>
> >>>
> >>>     "The SDP grouping framework [RFC5888]
> >>> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC58
> >>> 88>  can be used to group m-lines. When an m-line describes
> >>> one and only one RTP Packet stream, it is possible to 
> associate RTP 
> >>> media streams across different m-lines.
> >>> However, cases such as when a m-line has multiple RTP Packets 
> >>> streams or the need for an application to specify 
> application-level 
> >>> information about the association between the m-line and 
> the group, 
> >>> the SDP grouping framework cannot be used for this purpose"
> >>>
> >>> This seems good. I'll adopt and/or adapt.
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 1.3 Para 3
> >>>     WebRTC defines a mapping (documented in 
> [I-D.ietf-rtcweb-jsep] 
> >>> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> >>> etf-rtcweb-jsep> ) where one SDP m-line is used to describe
> >>> each MediaStreamTrack, and that the BUNDLE mechanism 
> >>> [I-D.ietf-mmusic-sdp-bundle-negotiation]
> >>> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> >>> etf-mmusic-sdp-bundle-negotiation>  is used to group
> >>> MediaStreamTracks into RTP sessions.
> >>>
> >>>     [Suhas] we might want to say "MediaStreamTracks into a RTP 
> >>> Session" instead of "MediaStreamTracks into RTP Sessions"
> >>>
> >>>
> >>> No, because in the case of less than total Bundling, 
> >>> MediaStreamTracks will be grouped into multiple RTP 
> sessions, not a 
> >>> single one.
> >>>
> >>>
> >>>
> >>>
> >>>     *Section 1.3 Para 3
> >>>     Therefore, the need is to specify the ID of a 
> MediaStreamTrack 
> >>> and its associated MediaStream for each m-line, which can be 
> >>> accomplished with a media-level SDP attribute.
> >>>     [Suhas] Can we change it to
> >>>
> >>>     "
> >>>      Therefore, the need is to uniquely identify the 
> >>> MediaStreamTrack and its MediaStream for each m-line via a 
> >>> media-level SDP attribute. This would enable establishing the 
> >>> relationship between RTP Packet Streams that correspond to same 
> >>> WebRTC MediaStream across m= lines".
> >>>     "
> >>>
> >>>
> >>> Modulo "would" -> "will" ("would" is the wishful-thinking 
> tense of 
> >>> the word, which I like to avoid - can't remember the grammatical 
> >>> name of the construct at the moment).
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 2 Title
> >>>      [Suhas] Msid is not defined. Also suggest common convention. 
> >>> (MSID vs Msid) throughout
> >>>
> >>>
> >>> The section is the definition of MSID, I'm not sure how to define 
> >>> the term before defining it.
> >>>
> >>> I'd like to have the convention be "msid" (all lower 
> case), but the 
> >>> RFC Editor likes capitals in section titles. I'll 
> lowercase it and 
> >>> see if it survives. (I lowercased all occurences elsewhere in a 
> >>> previous pass)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Section 3
> >>>
> >>>     The ABNF of msid-semantic is:
> >>>
> >>>       attribute =/ msid-semantic-attr
> >>>       msid-semantic-attr = "msid-semantic:" semantic 
> identifier-list
> >>>       semantic = token ; see RFC 4566
> >>>       identifier-list = (" " identifier)* / " *"
> >>>
> >>>     [Suhas] The identifier-list MUST be msid not generic 
> identifier. 
> >>> Since this session level grouping applies only to msid or 
> should it 
> >>> apply
> >>>
> >>>
> >>> There is no "msid" ABNF construct. The "msid-attr" in section
> >>> 2 is defined in terms of identifier.
> >>> So I can't parse this request.
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4
> >>>     [Suhas] Shouldn't we make appData MUST for WMS 
> semantics. Since 
> >>> having a MediaStream with no tracks into makes much 
> sense. also the 
> >>> ABNF for appdata is optional in Section 2.
> >>>
> >>>
> >>> It makes sense to say that it MUST be given. Will do.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4
> >>>     [Suhas] When the m= section is updated to inactive, I am 
> >>> thinking we should signal the MedaStreamTrack as ended, is that a 
> >>> right assumption ?
> >>>
> >>>
> >>> No, because "inactive" can be resumed.
> >>> "Ended" is a final state for a MediaStreamTrack.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4
> >>>        In addition to signaling that the track is closed when its 
> >>> msid attribute disappears from the SDP, the track will also be 
> >>> signaled as being closed when all associated SSRCs have 
> disappeared 
> >>> by the rules of
> >>>     [Suhas] Probably a formatting glitch. The above sentence is 
> >>> incomplete
> >>>
> >>>
> >>> In my copy, it continues with "[RFC3550] section 6.3.4 
> (BYE packet 
> >>> received) and 6.3.5 (timeout), and when the corresponding media 
> >>> section is disabled by setting the port number to zero.". 
> What does 
> >>> it say in your copy?
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4
> >>>     The association between SSRCs and m-lines is specified in 
> >>> [I-D.ietf-rtcweb-jsep] 
> >>> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> >>> etf-rtcweb-jsep> .
> >>>
> >>>     [Suhas] Why is this needed here ?
> >>>
> >>>
> >>>
> >>> It's not. Will remove.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4.1 Title
> >>>     [Suhas] Tracks undefined, suggest we change it to WebRTC 
> >>> MediaStreamTracks or something like that.
> >>>
> >>>
> >>> I think it would be correct to say "non-signalled packet streams".
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4.1 Para 1
> >>>     Non-WebRTC entities will not send msid
> >>>
> >>>     [Suhas] Suggest changing will not to may not .. since msid 
> >>> itself is generic mechanism but WMS is webrtc specific mechanism
> >>>
> >>>
> >>> I'll change to "will not send msid with the WMS semantic".
> >>> This is a leftover from before msid-semantic was introduced.
> >>> Good catch!
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4.1
> >>>     It follows from the above that media stream tracks in the 
> >>> "default" media stream cannot be closed by removing the msid 
> >>> attribute; the application must instead signal these as 
> closed when 
> >>> the SSRC disappears according to the rules of RFC 3550 
> section 6.3.4 
> >>> and 6.3.5 or by disabling the m-line by setting its port to zero.
> >>>
> >>>     [ Suhas ] "default" media stream and tracks aren't 
> defined and 
> >>> we need some context to explain this.
> >>>
> >>>
> >>> This should be "tracks constructed by the above rule when no 
> >>> msid-semantic:WMS is present".
> >>> Good catch.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4.2.1
> >>>      How do we want to support adding  a track that is 
> not part of a 
> >>> Media Stream ? Should there be a msid line at all ?
> >>>
> >>>
> >>> This is not supported. Should it be?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4.2.1
> >>>      What should happen if the modified SDP has same msid but a 
> >>> different trackId in the appData. Should we trigger ended 
> on the old 
> >>> track and created on the new track ?
> >>>
> >>>
> >>> Yes.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Is it worthwhile considering the possibility of sending the 
> >>> TrackId in the RTP Layer (as header extension) since it can 
> >>> identifies the Media Source end to end.
> >>>
> >>>
> >>> This is being considered for BUNDLE (appid). I don't want 
> to try to 
> >>> do the same thing here, for fear of having duelling 
> specifications.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     *Section 4 - Offer/Answer Procedures
> >>>     We might want to add some text to explain the following
> >>>      - An Offer has WMS semantic include, Answerer 
> doesn't include 
> >>> the semantic in response --> No WMS used for the session
> >>>      - Either Offer/Answer has a semantic which isn't 
> understood by 
> >>> the end-points --> No MSID mechanism is used and m= lines are 
> >>> rejected
> >>>
> >>>
> >>>
> >>> I don't see a reason for either of these things. Continuing to 
> >>> announce the data does no harm.
> >>> I can add "MUST ignore a=msid lines where the identifier 
> is listed 
> >>> in a msid-semantic: header that the implementation does not 
> >>> support".
> >>>
> >>>
> >>>
> >>>
> >>>     Section 4.1 Says
> >>>     "If a WebRTC entity sends a description, it MUST include the 
> >>> msid-semantic:WMS attribute, even if no media streams are sent."
> >>>     and Section 3 says
> >>>     "This attribute MUST be present if "a=msid" is used."
> >>>
> >>>
> >>>     So if i add both, it is not clear in the cases of 
> >>> recvonly/inactive streams in the Offer, if we should 
> include a=msid 
> >>> line If i wanted to include a empty WMS semantic. So 
> basically what 
> >>> mandates which is not very clear here ?
> >>>
> >>>
> >>> 4.1 is about WebRTC implementations. These MUST send 
> >>> msid-semantic:WMS, whether or not they have any a=msid in the SDP.
> >>>
> >>> Non-WebRTC implementations that don't send a=msid don't 
> have to send 
> >>> msid-semantic:.
> >>>
> >>> Non-WebRTC implementations that send a=msid MUST send
> >>> msid-semantic: so that it's possible to figure out what 
> they mean by 
> >>> their a=msid lines.
> >>>
> >>> Non-WebRTC implementations that use a different
> >>> msid-semantic: must follow the rules for that semantic.
> >>>
> >>> I don't see what's not clear here, but would appreciate 
> suggestions 
> >>> for more text to make it clearer.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Section 4.2.2
> >>>     - We need a line to parse the Semantics
> >>>
> >>>
> >>> Good catch. It needs to verify that the msid-semantic says WMS. 
> >>> (Since all of section 4.2 is about WMS, this is the only 
> one we need 
> >>> to specify rules for.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Please let me know If i can help with aligning the draft with 
> >>> Taxonomy and so on..
> >>>
> >>>
> >>> Help appreciated!
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Thanks
> >>>     Suhas Nandakumar
> >>>
> >>>     On Thu, Jun 26, 2014 at 4:51 PM, Flemming Andreasen 
> >>> <[e-mail]> wrote:
> >>>
> >>>
> >>>         Thanks Harald
> >>>
> >>>         It would be great if people could please take a 
> look at the 
> >>> updated draft and see if they have any comments; we would like to 
> >>> get WGLC issued soon.
> >>>
> >>>         Thanks
> >>>
> >>>         -- Flemming (MMUSIC co-chair)
> >>>
> >>>
> >>>
> >>>         On 6/26/14, 6:12 PM, Harald Alvestrand wrote:
> >>>
> >>>
> >>>             Flemming kindly pointed out to me that I had not 
> >>> actively notified the list about my new version of the 
> -msid draft 
> >>> that was published on June 6.
> >>>
> >>>             Here's the changelog - the "detailed 
> procedures" section 
> >>> has the "initial offer / initial answer"
> >>> and so on format that was recommended by the chairs, so 
> it may be of 
> >>> interest to this group.
> >>>
> >>>             Harald
> >>>
> >>>             C.12.  Changes from -05 to -06
> >>>
> >>>                Addressed issues found in Fleming 
> Andreassen's review
> >>>
> >>>                Referenced JSEP rather than unified-plan for the 
> >>> M-line mapping model
> >>>
> >>>                Relaxed MSID definition to allow "token-char" in 
> >>> values rather than
> >>>                a-z 0-9 hyphen; tightened ABNF by adding length 
> >>> description to it.
> >>>
> >>>                Deleted discussion of abandoned 
> alternatives, as part 
> >>> of preparing
> >>>                for publication.
> >>>
> >>>                Added a "detailed procedures"
> >>> section to the WMS semantics
> >>>                description.
> >>>
> >>>                Added IANA registration of the "msid-semantic" 
> >>> attribute.
> >>>
> >>>             _______________________________________________
> >>>             mmusic mailing list
> >>>             [e-mail]
> >>>             https://www.ietf.org/mailman/listinfo/mmusic
> >>>
> >>>
> >>>
> >>>
> >>>         _______________________________________________
> >>>         mmusic mailing list
> >>>         [e-mail]
> >>>         https://www.ietf.org/mailman/listinfo/mmusic
> >>>
> >>>
> >>>
> >>>
> >>> .
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>