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

[Flemming Andreasen <[e-mail]>]

On 4/19/18 5:47 PM, Paul Kyzivat wrote:
> 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.
I agree wrt. the existing T.38 registration. I'm not sure about whether 
we wanted to make changes to the registration procedures documented in 
4566bis in general.

>
>>> * 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?
>
I'm not sure either.
> IOW, it seems to me that the definition of fmt for UDP is underspecified. 
I agree.
> 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.
>
Maybe Colin and Jonathan can help with additional input here. In the 
absence of that, I'd suggest you come up with a proposal.

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

Thanks

-- Flemming


>     Thanks,
>     Paul
> .
>