Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DBA21F9E6B for ; Tue, 15 Oct 2013 08:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TOdYGBstGsU for ; Tue, 15 Oct 2013 08:52:09 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B66B521F9E3B for ; Tue, 15 Oct 2013 08:52:08 -0700 (PDT) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9FFq3ZD066369 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 15 Oct 2013 10:52:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <525D649E.5040608@nostrum.com> Date: Tue, 15 Oct 2013 10:51:58 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="------------080006050401020700030105" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: [MMUSIC] Bundle-only, Port 0, and other options X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:52:20 -0000 This is a multi-part message in MIME format. --------------080006050401020700030105 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit There's been a bit of a brouhaha (from small but disproportionately vocal quarters) around the use of port zero in an offer for bundle-only lines. So I wanted to take a step back and see whether we could untangle this knot a bit. The key property that we need here is that bundle-only lines must be formed in a way that causes them to be rejected by non-bundling agents, but accepted by bundling agents. Since bundle deals with ports, that seems like an extremely natural place to make the distinction. It has the spectacular advantage of being defined in a crystal clear way in RFC 3264: "A port number of zero in the offer indicates that the stream is offered but MUST NOT be used. This has no useful semantics in an initial offer, but is allowed for reasons of completeness..." "A stream that is offered with a port of zero MUST be marked with port zero in the answer." By overriding this second normative statement for bundle clients, we turn it into an extremely well-defined extension point. ---------------------------------------------------------------------- But this is exactly the approach that is causing people heartburn, so let's look at other potential ways of achieving the goal. In a media section, there are only a small handful of fields that an implementation is required to read and understand: m= / ... c= Taken one-by-one: 1. Extending "media" would be somewhat problematic, since we use this information extensively in our use cases. We would effectively have to register bundle-only variations on "audio," "video," and "application" (at a minimum), which is horribly inelegant. 2. Port is discussed above. 3. Setting "number of ports" to zero would clearly have the semantics that we're interested in here. The down-side of using this approach is that (in my experience) there are a lot of implementations that simply ignore the "number of ports" field, and a small handful that simply choke when it is present. 4. Proto is an interesting one. Right now, we use RTP/SAVPF and DTLS/SCTP. We could conceivably additionally register RTP/SAVPF/BUNDLEONLY and DTLS/SCTP/BUNDLEONLY, which would presumably be rejected by non-bundle clients as unrecognized. 5. Fmt isn't really an option -- we need to use it to identify formats. 6. Moving on to the c= line (which, if present, is mandatory to parse, understand, and honor), nettype is pretty much hardwired to "IN." We could register an "IN-BUNDLEONLY" option, but there's a good chance that implementations don't really look at the value of this field, so they wouldn't reject the new value. 7. Addrtype is necessary for indicating IP4 versus IP6. We could register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is approximately as elegant as option #1. 8. Overloading connection-address would be dicey, since it ruins the ability to send different streams to different places. While WebRTC might not care too much about these use cases, they *are* important in other contexts. In summary: of the above options, the strongest option still seems to be "port," followed (perhaps) by "proto." We could probably force "media" or "addrtype" to work, but these would be pretty messy. I think "number of ports" and "nettype" are at high risk of being ignored by non-bundle implementations (i.e., they won't trigger the failure we want), and we need to maintain the existing meanings for "fmt" and "connection-address". Even more tersely: if we don't want to port zero, I think the only other realistic option is registering new "proto" values. /a --------------080006050401020700030105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit There's been a bit of a brouhaha (from small but disproportionately vocal quarters) around the use of port zero in an offer for bundle-only lines. So I wanted to take a step back and see whether we could untangle this knot a bit.

The key property that we need here is that bundle-only lines must be formed in a way that causes them to be rejected by non-bundling agents, but accepted by bundling agents. Since bundle deals with ports, that seems like an extremely natural place to make the distinction. It has the spectacular advantage of being defined in a crystal clear way in RFC 3264:

  "A port number of zero in the offer indicates that the
   stream is offered but MUST NOT be used.  This has no useful semantics
   in an initial offer, but is allowed for reasons of completeness..."

  "A stream that is offered with a port of zero MUST be marked with port
   zero in the answer."

By overriding this second normative statement for bundle clients, we turn it into an extremely well-defined extension point.

----------------------------------------------------------------------

But this is exactly the approach that is causing people heartburn, so let's look at other potential ways of achieving the goal. In a media section, there are only a small handful of fields that an implementation is required to read and understand:

  m=<media> <port>/<number of ports> <proto> <fmt> ...
  c=<nettype> <addrtype> <connection-address>

Taken one-by-one:

  1. Extending "media" would be somewhat problematic, since we use this information extensively in our use cases. We would effectively have to register bundle-only variations on "audio," "video," and "application" (at a minimum), which is horribly inelegant.

  2. Port is discussed above.

  3. Setting "number of ports" to zero would clearly have the semantics that we're interested in here. The down-side of using this approach is that (in my experience) there are a lot of implementations that simply ignore the "number of ports" field, and a small handful that simply choke when it is present.

  4. Proto is an interesting one. Right now, we use RTP/SAVPF and DTLS/SCTP. We could conceivably additionally register RTP/SAVPF/BUNDLEONLY and DTLS/SCTP/BUNDLEONLY, which would presumably be rejected by non-bundle clients as unrecognized.

  5. Fmt isn't really an option -- we need to use it to identify formats.

  6. Moving on to the c= line (which, if present, is mandatory to parse, understand, and honor), nettype is pretty much hardwired to "IN." We could register an "IN-BUNDLEONLY" option, but there's a good chance that implementations don't really look at the value of this field, so they wouldn't reject the new value.

  7. Addrtype is necessary for indicating IP4 versus IP6. We could register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is approximately as elegant as option #1.

  8. Overloading connection-address would be dicey, since it ruins the ability to send different streams to different places. While WebRTC might not care too much about these use cases, they *are* important in other contexts.

In summary: of the above options, the strongest option still seems to be "port," followed (perhaps) by "proto." We could probably force "media" or "addrtype" to work, but these would be pretty messy. I think "number of ports" and "nettype" are at high risk of being ignored by non-bundle implementations (i.e., they won't trigger the failure we want), and we need to maintain the existing meanings for "fmt" and "connection-address".

Even more tersely: if we don't want to port zero, I think the only other realistic option is registering new "proto" values.

/a

--------------080006050401020700030105--