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

[Paul Kyzivat <[e-mail]>]

Flemming,

Thanks for responding. I was despairing at getting anyone to respond.

On 4/18/18 11:35 PM, Flemming Andreasen wrote:
> 
> 
> 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.

OK. I'll just add some additional text making it even clearer.

>> * 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.

I listened to the discussion live. I can go back and double check. But 
my recollection was that referencing an RFC was brought up. (I think by 
me.) But there is currently no such RFC, so following that path would 
entail writing one, and there was no interest in doing that. My 
understanding was that the decision was to grandfather the registry 
referencing T.38 even though the rules require reference to an RFC.

But that is the status quo, so it appears to me that no change is required.

>> * 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.

I'll contact Jonathan. But my question was a bigger one than that. My 
question is what does it *mean* for the fmt for UDP to be a mime type? 
This was never explained, from the beginning. I *guess* that the intent 
was that every UDP packet body conform to the mime type. Was that the 
original intent? Or is the mime type somehow to describe the whole 
stream of packets?

IOW, it seems to me that the definition of fmt for UDP is 
underspecified. I would like to complete the specification but don't 
know what the intent is. I can make something up, but that seems like a 
bad idea.

I'll also note that I'm not aware of any cases that actually use UDP as 
transport and a mime type as the fmt.


>> * 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>

Not really. I'll query Ben for more about what he meant.

	Thanks,
	Paul