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

[Magnus Westerlund <[e-mail]>]

Hi Paul,

See inline.


Den 2018-04-19 kl. 23:47, skrev Paul Kyzivat:
> 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.

So Colin, may have a better recollection of those early discussions. 
But, yes I do think that the original intention was to put the subtype 
of the MIME type in the fmt space. However, based on the later 
discussions around use of MIME types I think that is problematic. The 
proto + fmt combination does basically identify a specific transport 
protocol and format to be used. That doesn't match MIME, which is a 
specific format only. We had a long discussion around the MIME type 
usage with RTP, which is much more specific.

What I would do here is to create a SDP specific registry but maintain 
the MIME syntax for any entry, and make it clear that what ever like to 
register here needs to define what foo over UDP is. So specification 
required at least.

/Magnus

>
>
>>> * 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
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------