Re: [MMUSIC] INPUT NEEDED: Edits to 4566bis based on discussion in London

[Flemming Andreasen <[e-mail]>]

On 4/5/18 5:17 PM, Paul Kyzivat wrote:
> I'm working on making the changes to 4566bis that were called for 
> based on the discussion in London. After reviewing all of that I have 
> some questions for which I need feedback from the wg.
>
> * Open Issue 3 - Regarding section 5.11 (z=):
>
> After reviewing the text for t=, r=, z=, the meaning of z= seems 
> pretty clear to me. The text for z= only talks about how it works with 
> r=. In principle, if the adjustment time precedes the start time from 
> t= then I suppose it *might* also apply there, and perhaps to stop 
> time as well.
>
> From the text and examples it is clear that this isn't usable for 
> anything else. E.g., it does *not* provide an adjustment that yields 
> local time.
>
> I could reword to say that it does *not* apply to the start/stop times 
> in t=, or that it definitely only applies to r=. Thoughts?
>
Section 5.11 (z=) says:
<quote>

  Adjustments apply to all "t=" and
    "r=" lines in a session description.

</quote>

If I understood Colin's explanation in London correctly, then I believe 
it *should* only apply to the "r=" line, but that's not what it 
currently says. Maybe Colin can weigh in again ? In either case, I don't 
find the text as clear as you do, so adding a few more lines of text 
would be helpful.

> * Open Issue 7 - Regarding section 8.2.2 ("proto"):
>
> The minutes (regarding udptl) say:
>
> "Action: will grandfather T.38 and keep the text as is. Also change to 
> currently defined registration procedure."
>
> What was meant here? The registration procedure says RFC Required. 
> Changing to conform to that is different from grandfathering T.38.
>
> ISTM that all is well as it is.
>
The minutes 
(https://datatracker.ietf.org/meeting/101/materials/minutes-101-mmusic/) 
say that:
<quote>

	There was also discussion on how to handle udptl, concluding that the
	registry information for udptl is incorrect but that 4566bis will
	grandfather T.38 and keep the text as is. The currently defined
	registration procedure should however be changed to not only allow
	referencing standards track RFC. [Action: Authors]

</quote>

My memory may not serve me well here, but I thought we said that it 
should in fact reference a standards track RFC (there was some back and 
forth discussion between our ADs on this point after the initial 
conclusion I believe). Probably best to listen to the meeting recording 
on this one to verify what the final conclusion was.

> * Open Issue 8 - Regarding section 8.2.3 ("fmt"):
>
> The text implies that the namespace for udp formats consists of mime 
> types. It says:
>
>    ... If no media
>    subtype exists, it is RECOMMENDED that a suitable one be registered
>    through the IETF process [RFC6838] by production of, or reference to,
>    a standards-track RFC that defines the transport protocol for the
>    format.
>
> But IIUC rfc6838 makes no provision for defining a *transport 
> protocol* for a mime type.
>
> I'm not even entirely sure what rfc4566 intended here. Was it that the 
> content of each UDP packet is to conform to the definition of the mime 
> type? What about ordering rules that impose requirements on sequences 
> of packets?
>
> Is it intended that the media types suitable for use as udp formats 
> are only those that have something special in their definitions? Or 
> may any mime type be used if it can fit in a UDP packet?
Here is what the minutes say:
<quote>

     *	Open Issue #8 - Where are media format (“fmt”) registrations to be
     	done?
	Colin commented that the only “proto” that currently has a
	well-defined registration policy (in RFC 3555) are the ones based on
	RTP. A discussion concluded to clarify that the media format namespace
	and registration procedures depends on “proto” value and that “fmt”
	registration procedures must also be specified when registering a new
	“proto”. Jonathan offered to provide text giving some guidance.
	[Action: Jonathan and authors]

</quote>

I'd prod Jonathan for some text here.
>
> * Open Issue 9 - Regarding section 8.2.5 ("bwtype"):
>
> The notes say:
>
> "Check the current IANA registry, did they change the registry and 
> update accordingly."
>
> The registry does now have the mux category, and the entries for CT 
> and AS reference both 4566 and mux-attributes.
>
> AFAICT the only thing to do is update these two registry entries to 
> reference this bis rather than 4566. Did I miss anything?
>

Here is what we have in the minutes:
<quote>

     *	Open Issue #9 - Should IANA registration of “CT” and “AS” bandwidth
     	specifiers be updated to point to 4566bis instead of to RFC 4566 and
	draft-ietf-mmusic-sdp-mux-attributes as today?
	Ben C commented that the current text “should be registered” seems
	un-enforceable and that the WG should pick a text pointing to one of
	the currently defined procedures. This is also applicable to open
	issue #7. It was concluded to re-check IANA registry and refine text
	in 4566bis accordingly. [Action: Authors]

</quote>

Hope this helps.

-- Flemming

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