From stewe@stewe.org Sun Feb 13 10:40:59 2011 Return-Path: X-Original-To: rai@core3.amsl.com Delivered-To: rai@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6956F3A6A1C; Sun, 13 Feb 2011 10:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz0VYpBVapwi; Sun, 13 Feb 2011 10:40:58 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id DE1BE3A6A00; Sun, 13 Feb 2011 10:40:57 -0800 (PST) Received: from [192.168.1.106] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4221-1743317 for multiple; Sun, 13 Feb 2011 19:41:17 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Sun, 13 Feb 2011 10:41:10 +0100 From: Stephan Wenger To: IETF AVT WG , , Message-ID: Thread-Topic: Incoming liaison from MPEG Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3380438477_1401406" X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Subject: [RAI] Incoming liaison from MPEG X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 18:40:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3380438477_1401406 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, We have received a liaison statement from MPEG. They inform us of their progress at their last meeting in Korea. Their streaming over HTTP technology (known as DASH) is now in Draft International Standard (DIS) state, and support for DASH has also been included in a Draft Amendment to their MPEG-4 file format specification. With respect to the latter, the AVT folks may find the informal description of RTP's synchronization mechanisms in Annex H particularly interesting. I glanced over it and found it consistent with RTP and its common use, but perhaps someone else wants to check as well? No actions are required by the IETF, but they welcome comments and participation. The statement should be available in the official IETF tracker (https://datatracker.ietf.org/liaison/) shortly; until then, you can email me for a copy. Regards, Stephan --B_3380438477_1401406 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

Hi all,

We have re= ceived a liaison statement from MPEG. They inform us of their progress= at their last meeting in Korea. Their streaming over HTTP technology = (known as DASH) is now in Draft International Standard (DIS) state, and supp= ort for DASH has also been included in a Draft Amendment to their MPEG-4 fil= e format specification. With respect to the latter, the AVT folks may = find the informal description of RTP's synchronization mechanisms in Annex H= particularly interesting. I glanced over it and found it consistent w= ith RTP and its common use, but perhaps someone else wants to check as well?=

No actions are required by the IETF, but they welcome comments an= d participation.

The statement should be available in the official= IETF tracker (https://datatr= acker.ietf.org/liaison/) shortly; until then, you can email me for a cop= y.

Regards,

Stephan

<= /html> --B_3380438477_1401406-- From rjsparks@nostrum.com Fri Feb 18 11:59:55 2011 Return-Path: X-Original-To: rai@core3.amsl.com Delivered-To: rai@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EA53A6FD7 for ; Fri, 18 Feb 2011 11:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr553ISLHHHc for ; Fri, 18 Feb 2011 11:59:54 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 60FCB3A6FDF for ; Fri, 18 Feb 2011 11:59:53 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p1IJxCuN030430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 18 Feb 2011 13:59:12 -0600 (CST) (envelope-from rjsparks@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Robert Sparks In-Reply-To: <70E058BB-56CC-4A2A-8470-E5873ED724D6@nostrum.com> Date: Fri, 18 Feb 2011 13:59:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <47F3FEDF-C369-49EA-85CC-41320BF66114@nostrum.com> References: <70E058BB-56CC-4A2A-8470-E5873ED724D6@nostrum.com> To: rai@ietf.org X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [RAI] SIPit 28 registration closes April 1 X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 19:59:55 -0000 Registration for SIPit 28 is open. SIPit 28 will be hosted by Digium April 11-15, 2011 in Huntsville, = Alabama. More information, and a link to the registration website is available at = https://www.sipit.net RjS From gonzalo.camarillo@ericsson.com Fri Feb 25 05:07:01 2011 Return-Path: X-Original-To: rai@core3.amsl.com Delivered-To: rai@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195B73A69AC; Fri, 25 Feb 2011 05:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMrj2nLqduBp; Fri, 25 Feb 2011 05:06:59 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0C7FC3A69AB; Fri, 25 Feb 2011 05:06:58 -0800 (PST) X-AuditID: c1b4fb39-b7b76ae00000276e-f5-4d67a9a67968 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 49.A1.10094.6A9A76D4; Fri, 25 Feb 2011 14:07:50 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 25 Feb 2011 14:07:50 +0100 Received: from [131.160.126.172] (rvi2-126-172.lmf.ericsson.se [131.160.126.172]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E38F625C4; Fri, 25 Feb 2011 15:07:49 +0200 (EET) Message-ID: <4D67A9A5.7090600@ericsson.com> Date: Fri, 25 Feb 2011 15:07:49 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "rai@ietf.org" , "sipping@ietf.org" , Volker Hilt Subject: Re: [RAI] draft-ietf-sipping-media-policy-dataset: The implied boolean logic of policy operations X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 13:07:01 -0000 Hi Dale, here you have my answers not only to your original email, but to the whole section on open revision items you added to the draft. > 1.1. Media Types > > > 1.1.1. Require Registration > > > In -10, all media type names that are mentioned in a MPDF are > explicitly required to be IANA-registered. Technically, this means > that experimental or private-use types can not be used, even in > situations where all participants are aware of non-registered media > types. In practice, people will go ahead and use them anyway. I am > proposing to remove the "registered" requirement. yes, I agree this draft does not need to put unnecessarily restrictive requirements on the tokens to be placed in MPDF documents. > 1.1.2. Terminology > > In a number of places, media types are called "MIME types". The > latter is common usage, but it is not official, and as RFC 4288 makes > clear, media types are independent of their use within MIME. I've > fixed the wording of the draft in a number of places to correct this. Perfect. > 1.1.3. Rename the child of > > There is an element that is a child of the > element that carries a media type and subtype. The natural fix would > be to change this to , but there is already an element of > that name that is a child of that carries a media type > (without subtype). I would like a name that means "media type and > subtype", but I can't think of a short one. Suggestions? I do not think we should spend too much time thinking of a good name for it. Let's just call it , for instance. > > 1.2. Remove reference to uaprofile.rng > > The Relax NG schema given in draft-ietf-sipping-media-policy-dataset > includes "uaprofile.rng". As far as I can figure out, uaprofile.rng > is the schema defined in draft-ietf-sipping-profile-datasets, which > has been abandoned. So we need to remove the reference to > uaprofile.rng. It's possible that there are things defined in that > schema that need to be either deleted from > draft-ietf-sipping-media-policy-dataset, or copied from the abandoned > draft into the schema in draft-ietf-sipping-media-policy-dataset. > > If anyone has further information about this, please tell me. > Yes, although a cleanup was performed in order to get rid of the now-abandoned draft, we may still need to finish it properly. > 1.3. Remove > > I have updated the text of draft-ietf-sipping-media-policy-dataset-11 > to consistently use "property-set" rather than sometimes using > "property_set". However, it seems to me that the > element serves no use (now that sipping-profile-datasets has been > abandoned). The draft says that each and policy> appears in a , and can contain > more than one of each. But there seems to be no practical use for > this grouping; the semantics of and > is completely standalone. > > So I am proposing eliminating the element entirely, > making and into top-level elements. Yes, this is part of the cleanup we referred to above. > 1.4. Specifying Sets > > There are many properties for which the values are sets of primitive > values. The current syntax for specifying sets is awkward. In > addition, it is not permitted to specify a set containing zero > elements. Sessions containing empty sets are not useful to write, > but it is easy to generate them when applying a policy to a info>. So the syntax for set values needs to be updated. Yes, it makes sense. > 1.5. Specifying Bandwidth Limitations > > Looking at the XML of draft-ietf-sipping-media-policy-dataset, I see > this paragraph: > > > > SDP provides "b=" lines for specifying bandwidth limitations. > Similarly, MPD provides , , and > elements, and the draft states that they are > equivalent to various forms of the b= line. Should we require that > when SDP is translated into MPD that the bandwidth limitations be > translated? Yes, it makes sense. > > 1.6. Rejecting a media stream > > In draft-ietf-sipping-media-policy-dataset-10 there is no explicit > way to indicate that a stream has been rejected (which is needed to > correspond to an m= line in SDP where the port number is 0). > Implicitly, this can be done by setting the port number in the > or to 0. But that is pretty > ugly. I propose that we introduce an attribute of the > element to indicate that a stream has been rejected/disabled: > > > > The default value of "enabled" would be "yes". > > This resolves the problem of how a policy server would modify a > to make it conform to a policy if one of the s > contradicted the policy: The policy server would put enabled="no" > onto the . > > For consistency, a policy server could effectively reject a proposed > session by rejecting all of the streams within it. This would be > slightly different than rejecting the session as a whole by returning > an empty session-info document, . This distinction > corresponds to the difference between an SDP offer/answer negotiation > failing, and the negotiation succeeding but the answer rejecting all > the m= lines in the SDP. Yes, it makes sense. > > 1.7. The implied boolean logic of policy operations > > I am starting work on a messy part of the media policy dataset > definition: Specifying the logic when a policy is applied to a > session-info, and also specifying how two policies are combined to > apply jointly to session-infos. The goal is to implement one's > intuitive expectations while introducing as few special cases as > possible. > > My current analysis is: > o The primary operation is applying a session-policy to a session- > info to produce a possibly more restricted session-info. This is > done by applying the session-policy to each stream in turn, which > may "restrict" the stream (in regard to bandwidth, codecs, etc.). Yes. > o A stream may be restricted to the point that it permits no media > whatsoever. Such "null" streams are all logically equivalent, > although a null stream can be represented in many different ways. > When translated back into SDP, a null stream becomes a rejected m= > line. Yes. > o The different elements in a session-policy are > effectively ORed together, in that the policy intends to permit > any stream that conforms to *any one* of the elements. > This is necessary because e.g. a session-policy can contain one > that specifies audio media and restricts the codecs > permitted for audio, and another that specifies video > media and restricts the codecs permitted for video. When policies apply to different aspects (e.g., video codecs and audio codecs), this is true. However, if different policies apply to the same aspect, they need to be merged. And when merging the policies, the resulting stream needs to be compliant to all policies (i.e., an AND operation). For example, if one policy allows codecs 0 and 8 and another only allows 8, the resulting policy is to only use codec 8. If a policy allows only codec 0 and another policy only allows codec 8, the result is a null session. I am not sure if this is what you are saying above (and below in the rest of the section), though. Thanks, Gonzalo > o Thus, applying a session-policy to a stream involves applying each > session-policy to the stream, and then choosing the > "best" result. In practice, we expect that the streams admitted > by the session-policy elements to be disjoint (e.g., one > is for audio, one is for video), so the result of applying any but > one will be a null stream, and the "best" result will be > the only non-null result. > o The alternative strategy of "unioning" the results of applying > each element cannot be used because it can allow the > resulting session to exceed all of the element policies. > Consider the policy > > > codecs: audio/foo, bandwidth: 10 > codecs: audio/foo,audio/bar, bandwidth: 1 > > > applied to the requested stream "codecs: audio/foo,audio/bar, > bandwidth: 10". The result of restricting with the first > is "codecs: audio/foo, bandwidth: 10" and the result of > restricting with the second is "codecs: audio/foo,audio/ > bar, bandwidth: 1". The union of the two (the "smallest" stream > that contains them both) is "codecs: audio/foo,audio/bar, > bandwidth: 10", which is not allowed by either . > o Within this context, combining two policies to form a joint policy > that enforces both their restrictions simultaneously is simple: > The resulting policy is made by "intersecting" all possible pairs > of s, one from the first policy and one from the second > policy. (Intersections that result in null policies can be > dropped from the result.) > o I haven't studied the role of the directional attributes yet, but > currently I believe that a bidirectional session-info can > be treated as an abbreviation for two session-info s, one > in each direction, and a bidirectional session-policy can > be treated similarly. Or, directionality can be treated as an > attribute with two possible values, *with identical results*.