Subject: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP structured headers

From: James <[email-masked]>
Date: Mon, 8 Feb 2021 23:28:47 +0000

Hi Dispatch,

I've written a draft[1] that I'd like your help in finding the right
place to carry on the work.

This draft solves the problem of having session information about media
being transmitted over HTTP, so implementations can use existing HTTP
semantics to represent SDP data models instead of handling SDP's
serialisation format.

Looking at possible places for this work to go, I've considered:
* mmusic - HTTP work doesn't appear to fit in here
* httpapi - This work might be "too specific" for media and out of scope
* wish - Whilst my use case isn't specific for WISH, it might fit in

I'll be presenting to the working group at IETF 110, but before then any
feedback you have would be appreciated.

Regards

- J

1: https://datatracker.ietf.org/doc/draft-gruessing-sdp-http/

---

From: Adam Roach <[email-masked]>
Date: Mon, 8 Feb 2021 18:15:47 -0600

Hi! It's not as much a suggestion for where this should go as it is a 
request to understand the use cases involved. I see that there is a 
desire to avoid parsing SDP syntax when it is sent in an HTTP context. 
What I'm trying to work though is which use cases this might happen in 
and what is really gained.

For the lines that are called out in this initial proposal, parsing is a 
pretty straightforward exercise of <key>=<value>, and multi-field values 
separated into fields using spaces. This is trivial to code.

Where SDP's complexity comes into play is parsing the values of "a=" 
fields, which vary from attribute type to attribute type, and which will 
continue to grow over time as new attributes are defined. This proposal 
does nothing to assist in parsing these fields, and any effort to do so 
will necessarily require new attributes to take into account HTTP 
encoding (unless we're just willing to let the HTTP encoding become out 
of date as soon as the next attribute is defined).

Given the foregoing, I'm scratching my head about which use cases will 
legitimately be simplified by encoding SDP as part of HTTP header 
fields. I think we really need to understand this before we can figure 
out who (if anyone) should work on it.

(Minor aside: the proposal right now seems to lack any way to encode the 
media type, port, profile, and parameters, as well as leaving off "a=" 
attributes for media sections.)

/a

On 2/8/21 17:28, James wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 9 Feb 2021 00:21:03 +0000

Given the parsing facets that Adam mentioned, would it be as simple to just
base64-encode the SDP, and stick to reusing off-the-shelf SDP parsers?

Cheers
Lucas

---

From: Adam Roach <[email-masked]>
Date: Mon, 8 Feb 2021 21:44:14 -0600

On 2/8/2021 6:21 PM, Lucas Pardue wrote:
> Given the parsing facets that Adam mentioned, would it be as simple to 
> just base64-encode the SDP, and stick to reusing off-the-shelf SDP 
> parsers?

That raises the same question about what one might gain from doing so. 
Would we entertain the notion of encoding images in HTTP header fields? 
HTML? There's a way this kind of thing is transferred in HTTP, and it's 
the message body.

Again, before we set off trying to figure out how to put SDP into HTTP 
header fields and who might go about designing how to do so, I think the 
first step is understanding the use cases that are driving such a solution.

/a

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 9 Feb 2021 04:10:03 +0000

> Would we entertain the notion of encoding images in HTTP header fields?

Good idea. SVGs can be super tiny [1], we could then leverage HPACK
compression ;)

> first step is understanding the use cases that are driving such a solution.

In seriousness, I agree totally.

I might hazard a guess that the SDP is being considered as metadata for the
associated media. Therefore to use HTTP, the proposal directly overlays on
HTTP concepts of metadata and content. But I'd love to hear more about the
motivation from the horses mouth.

Cheers
Lucas

[1] https://github.com/edent/SuperTinyIcons

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Feb 2021 11:37:28 +0000

Hi,

I agree with Adam, that we should first get a wider picture of what you are trying to do.

The draft says:

"The Session-Description header MAY be sent at the same time in a
 response with a HTTP body that also contains the SDP payload for
 backwards compatibility."

Backwards compatibility with what? If there are existing solutions where HTTP and SDP are used to negotiate media sessions I think it would be good to reference those, and describe what the issues sending SDP as body content are in those solutions.

Regards,

Christer

-----Original Message-----
From: dispatch <[email-masked]> On Behalf Of Adam Roach
Sent: tiistai 9. helmikuuta 2021 5.44
To: Lucas Pardue <[email-masked]>
Cc: DISPATCH WG <[email-masked]>
Subject: Re: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP structured headers

That raises the same question about what one might gain from doing so. 
Would we entertain the notion of encoding images in HTTP header fields? 
HTML? There's a way this kind of thing is transferred in HTTP, and it's the message body.

Again, before we set off trying to figure out how to put SDP into HTTP header fields and who might go about designing how to do so, I think the first step is understanding the use cases that are driving such a solution.

/a

---

From: James <[email-masked]>
Date: Thu, 11 Feb 2021 22:51:37 +0000

Thanks for taking the time to read the draft.
However after some careful consideration and significant procrastination,
I believe I've worked out where my work should go and that is - nowhere.

To least provide the basic courtesy of answering your question of further
clarification of my use case; where this is already (internally) deployed is on
the control plane of broadcast media enccoders where signalling and control is
done over HTTP, and where some components (including browsers) understand HTTP
wholesale and the SDP data model but not the SDP serialisation format. Having
this standardised would help with interop with suppliers and other systems, as
well as potentially having broader applicability.

In future I'll do a better effort up front of covering the details in my use
case (lawyers permitting) and abstain from ever trying to standardise HTTP
headers.

-  J

On Mon, Feb 08, 2021 at 06:15:47PM -0600, Adam Roach wrote:
> request to understand the use cases involved. I see that there is a desire
> to avoid parsing SDP syntax when it is sent in an HTTP context. What I'm
> trying to work though is which use cases this might happen in and what is
> really gained.
> 
> Where SDP's complexity comes into play is parsing the values of "a=" fields,
> which vary from attribute type to attribute type, and which will continue to
> grow over time as new attributes are defined. This proposal does nothing to
> assist in parsing these fields, and any effort to do so will necessarily
> require new attributes to take into account HTTP encoding (unless we're just
> willing to let the HTTP encoding become out of date as soon as the next
> attribute is defined).
> 
> legitimately be simplified by encoding SDP as part of HTTP header fields. I
> think we really need to understand this before we can figure out who (if
> anyone) should work on it.
>