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

From: Paul Kyzivat <[email-masked]>
Date: Thu, 5 Apr 2018 17:17:03 -0400

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?

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

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

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

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 18 Apr 2018 23:35:17 -0400

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

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

> But IIUC rfc6838 makes no provision for defining a *transport 
> protocol* for a mime type.
>
> 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.
> The registry does now have the mux category, and the entries for CT 
> and AS reference both 4566 and mux-attributes.
>

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Apr 2018 17:47:58 -0400

Flemming,

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

> find the text as clear as you do, so adding a few more lines of text 

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

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

> 	in 4566bis accordingly. [Action: Authors]

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

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 19 Apr 2018 21:48:15 -0400

On 4/19/18 5:47 PM, Paul Kyzivat wrote:
>>> based on the discussion in London. After reviewing all of that I 
>>> have some questions for which I need feedback from the wg.
>>>
>>> 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.
>>>
>>> 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>
>>
>> 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.
>
>>> "Action: will grandfather T.38 and keep the text as is. Also change 
>>> to currently defined registration procedure."
>>>
>> 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.
>
> 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 
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.

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

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

Thanks

-- Flemming

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Apr 2018 10:07:15 +0200

Hi Paul,

See inline.

Den 2018-04-19 kl. 23:47, skrev Paul Kyzivat:
> know what the intent is. I can make something up, but that seems like 
> a bad idea.
>

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

-- 

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Apr 2018 11:36:36 -0400

Magnus, Colin, Flemming, and others,

On 4/23/18 4:07 AM, Magnus Westerlund wrote:

>> ... But my question was a bigger one than that. My 
That seems like a prudent direction to take. But it also seems like 
something well in excess of a simple editorial action. I can propose 
something, but I would think it would deserve some serious discussion in 
the WG. (If it is possible to find enough people to have that discussion.)

The things that I can recall that use UDP have all chosen to define a 
new proto value and then specify how to use fmt with that.

Are there *any* cases of RFCs where a proto of UDP is used with a mime 
subtype as fmt? Maybe we could simply deprecate this usage.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Mon, 23 Apr 2018 17:33:24 +0100

Paul,

> On 23 Apr 2018, at 16:36, Paul Kyzivat <[email-masked]> wrote:
> 
>>> ... 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?

The contents of each UDP packet have to conform to the signalled media type. This is exactly the same as when RTP is used, where the contents of every RTP packet have to conform to the signalled media type (i.e., the RTP payload format). 

>>> 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
> That seems like a prudent direction to take. But it also seems like something well in excess of a simple editorial action. I can propose something, but I would think it would deserve some serious discussion in the WG. (If it is possible to find enough people to have that discussion.)
> 
> The things that I can recall that use UDP have all chosen to define a new proto value and then specify how to use fmt with that.
> 
> Are there *any* cases of RFCs where a proto of UDP is used with a mime subtype as fmt? Maybe we could simply deprecate this usage.

SDP specifies the transport protocol and the data format that’s conveyed within that transport protocol. The transport protocol is identified by the “proto” field. The data format is identified by the combination of the media type (“media”) and the subtype (“fmt”).

For RTP, the fmt field references a media subtype indirectly:

	m=video 51372 RTP/AVP 99
	a=rtpmap:99 h263-1998/90000

Here the transport is “RTP/AVP" and the media type is “video/h263-1990; rate=90000”. RFC 3555 describes the process for mapping media type names and parameters onto SDP using the combination of “a=rtpmap:”, “a=ptime:”, “a=maxptime:”,  and “a=fmtp:” lines. 

For UDP, the fmt directly references a media subtype:

	m=application 10000 udp foo

In this case, the media type is “application/foo”, and the UDP packets contain data that is formatted as described in the media type registration for "application/foo”. We don’t need an SDP specific registry: it’s just a standard media type registration, presumably with a note in its Encoding Considerations section to the effect that “This media type is only defined for transmission over UDP”. 

What seems to be missing in RFC 4566 is a statement that “a=fmtp:” parameters can be used to convey media type parameters for media formats sent over UDP. 

For other transport protocols, the registration of the “proto” value denoting the transport states whether media types are used to describe the payload with that transport too, or whether the “fmt” namespace is managed differently. It would likely be a good idea to say that new protocols SHOULD use the media type namespace, for consistency, but there’s nothing in SDP that requires they do so.

Using UDP as the transport doesn’t seem especially useful, since in most cases I’d expect some additional framing to be needed to allow loss or reordering to be detected, but it seems conceptually well specified (although perhaps the text could be clearer in places). I don’t think deprecating UDP as a transport is appropriate, although clarifying when it should be used might be a good idea.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Apr 2018 12:42:55 -0400

> In this case, the media type is “application/foo”, and the UDP packets contain data that is formatted as described in the media type registration for "application/foo”. We don’t need an SDP specifi…

Thanks. You are confirming what I *thought* was intended, though it 
isn't stated very clearly.

> What seems to be missing in RFC 4566 is a statement that “a=fmtp:” parameters can be used to convey media type parameters for media formats sent over UDP.

OK. That is something that we can do.

> Using UDP as the transport doesn’t seem especially useful, since in most cases I’d expect some additional framing to be needed to allow loss or reordering to be detected, but it seems conceptually…

OK. I do have another question about one point. The text currently says:

    "udp" indicates an unspecified protocol over UDP.

This implies that there is some other protocol over UDP. But indeed 
there is no mechanism for specifying such. ISTM that this statement is 
wrong - that this proto means that UDP is used directly as the protocol.

For instance, you could conceivably specify

   m=text 50000 UDP plain

and then just sending plain text in UDP packets. But you would then have 
to live with the fact that reordering and packet loss may occur.

Alternatively you could define a new mime type that has packet sequence 
numbers and use those to do *something* to cope with packet loss and 
reordering. *That* might be functionally equivalent to defining another 
protocol layer, but it is then not "unspecified", and as far as SDP is 
concerned it isn't a protocol since it is part of the fmt.

Bottom line, ISTM the above should not say "unspecified protocol". Perhaps:

    "udp" indicates direct use of the UDP protocol.

How does that work for people?

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 Apr 2018 00:06:59 +0100

> On 25 Apr 2018, at 17:42, Paul Kyzivat <[email-masked]> wrote:
> 
> Thanks. You are confirming what I *thought* was intended, though it isn't stated very clearly.
> 
> This implies that there is some other protocol over UDP. But indeed there is no mechanism for specifying such. ISTM that this statement is wrong - that this proto means that UDP is used directly as the protocol.
> 
> and then just sending plain text in UDP packets. But you would then have to live with the fact that reordering and packet loss may occur.

Agree.

> Alternatively you could define a new mime type that has packet sequence numbers and use those to do *something* to cope with packet loss and reordering. *That* might be functionally equivalent to defining another protocol layer, but it is then not "unspecified", and as far as SDP is concerned it isn't a protocol since it is part of the fmt.
> 

Makes sense to me. Or maybe something like “…indicates that the data is transported directly in UDP with no additional framing”, if we want to be verbose?

-- 
Colin Perkins
https://csperkins.org/

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 25 Apr 2018 19:47:12 -0400

On 4/25/18 7:06 PM, Colin Perkins wrote:
>
>> On 25 Apr 2018, at 17:42, Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>>> On 23 Apr 2018, at 16:36, Paul Kyzivat <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>>> ... 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?
>>> The contents of each UDP packet have to conform to the signalled 
>>> media type. This is exactly the same as when RTP is used, where the 
>>> contents of every RTP packet have to conform to the signalled media 
>>> type (i.e., the RTP payload format).
>>>>>> 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
>>>> something well in excess of a simple editorial action. I can 
>>>> propose something, but I would think it would deserve some serious 
>>>> discussion in the WG. (If it is possible to find enough people to 
>>>> have that discussion.)
>>>>
>>>> The things that I can recall that use UDP have all chosen to define 
>>>> a new proto value and then specify how to use fmt with that.
>>>>
>>>> Are there *any* cases of RFCs where a proto of UDP is used with a 
>>>> mime subtype as fmt? Maybe we could simply deprecate this usage.
>>> SDP specifies the transport protocol and the data format that’s 
>>> conveyed within that transport protocol. The transport protocol is 
>>> identified by the “proto” field. The data format is identified by 
>>> the combination of the media type (“media”) and the subtype (“fmt”).
>>> Here the transport is “RTP/AVP" and the media type is 
>>> “video/h263-1990; rate=90000”. RFC 3555 describes the process for 
>>> mapping media type names and parameters onto SDP using the 
>>> combination of “a=rtpmap:”, “a=ptime:”, “a=maxptime:”, and “a=fmtp:” 
>>> lines.
>>> In this case, the media type is “application/foo”, and the UDP 
>>> packets contain data that is formatted as described in the media 
>>> type registration for "application/foo”. We don’t need an SDP 
>>> specific registry: it’s just a standard media type registration, 
>>> presumably with a note in its Encoding Considerations section to the 
>>> effect that “This media type is only defined for transmission over UDP”.
>>
>>> What seems to be missing in RFC 4566 is a statement that “a=fmtp:” 
>>> parameters can be used to convey media type parameters for media 
>>> formats sent over UDP.
>>
>>> For other transport protocols, the registration of the “proto” value 
>>> denoting the transport states whether media types are used to 
>>> describe the payload with that transport too, or whether the “fmt” 
>>> namespace is managed differently. It would likely be a good idea to 
>>> say that new protocols SHOULD use the media type namespace, for 
>>> consistency, but there’s nothing in SDP that requires they do so.
>>> Using UDP as the transport doesn’t seem especially useful, since in 
>>> most cases I’d expect some additional framing to be needed to allow 
>>> loss or reordering to be detected, but it seems conceptually well 
>>> specified (although perhaps the text could be clearer in places). I 
>>> don’t think deprecating UDP as a transport is appropriate, although 
>>> clarifying when it should be used might be a good idea.
>>
>> there is no mechanism for specifying such. ISTM that this statement 
>> is wrong - that this proto means that UDP is used directly as the 
>> protocol.
>>
>> and then just sending plain text in UDP packets. But you would then 
>> have to live with the fact that reordering and packet loss may occur.
>
> Agree.
>
>> Alternatively you could define a new mime type that has packet 
>> sequence numbers and use those to do *something* to cope with packet 
>> loss and reordering. *That* might be functionally equivalent to 
>> defining another protocol layer, but it is then not "unspecified", 
>> and as far as SDP is concerned it isn't a protocol since it is part 
>> of the fmt.
>>
> Makes sense to me. Or maybe something like “…indicates that the data 
> is transported directly in UDP with no additional framing”, if we want 
> to be verbose?
>
Sounds good.

-- Flemming