From dworley@avaya.com Mon Jan 3 10:20:11 2011 Return-Path: X-Original-To: sipping@core3.amsl.com Delivered-To: sipping@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB1C3A6A55 for ; Mon, 3 Jan 2011 10:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 M1tdSpRMmuqh for ; Mon, 3 Jan 2011 10:20:09 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 639E03A6A53 for ; Mon, 3 Jan 2011 10:20:09 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABqjIU3GmAcF/2dsb2JhbACkNHOlKQKWWoVKBIRliVY X-IronPort-AV: E=Sophos;i="4.60,267,1291611600"; d="scan'208";a="257793669" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Jan 2011 13:22:16 -0500 X-IronPort-AV: E=Sophos;i="4.60,267,1291611600"; d="scan'208";a="565688899" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Jan 2011 13:22:15 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 3 Jan 2011 13:22:15 -0500 From: "Worley, Dale R (Dale)" To: "sipping@ietf.org" Date: Mon, 3 Jan 2011 13:22:14 -0500 Thread-Topic: (resend) Errata reports on erratum 2580 on RFC 3398 (ISDN User Part (ISUP) to SIP Mapping) and errata 2121 and 2122 on RFC 5479 (Requirements and Analysis of Media Security Management Protocols) Thread-Index: AQHLq3Ml165MNmLa3EmdQmcH4sLrNQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Sipping] (resend) Errata reports on erratum 2580 on RFC 3398 (ISDN User Part (ISUP) to SIP Mapping) and errata 2121 and 2122 on RFC 5479 (Requirements and Analysis of Media Security Management Protocols) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 18:20:11 -0000 There may have been a mailer problem with the first sending of this report to the Sipping mailing list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3398, "ISDN User Part (ISUP) to SIP Mapping" Source of RFC: sipping (rai) Errata ID: 2580 Status: Reported Type: Technical Reported By: Stephen James Date Reported: 2010-10-19 Section 8.1.3 says: Item 6. The gateway also sends a CANCEL message to the SIP node to terminate any initiation attempts. It should say: Drop this statement. Notes: No CANCEL is sent on INVITE transaction timeout. This is per 3261 "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request." ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update Section 8.1.3 item 6 should be updated to "The gateway also sends a CANCEL message to the SIP node to terminate the initiation attempt if a provisional response has been received." The situation illustrated in section 8.1.3 does not distinguish the "provisional response received" case from the "provisional response not received" case, so the commentary should cover both cases. (The specific example diagrammed shows the "no provisional response received" case.) A similar change should be made to section 8.1.4 item 7, "The REL will trigger a CANCEL request to the SIP node if a provisional response has been received." A similar change should be made to section 8.1.7 item 7, "Upon receipt of a REL message before an INVITE final response, the gateway will send a CANCEL towards the SIP node if a provisional response has been received. Since a reader familiar with SIP will know the rules for sending CANCEL, this correction is not crucial for proper implementation of the RFC, so I am recommending that it be held for document update. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5479, "Requirements and Analysis of Media Security Management Protocols" Source of RFC: sip (rai) Errata ID: 2121 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2010-04-05 Section 5.1 - 5.3 says: Notes: Sections 5.1 through 5.3 use unexpected irregular, non-uniform indentation in hanging lists; this is accompanied by dangling hyphens in 5.2 ( s/third- party/third-party/ and s/crypto- agility/crypto-agility/ !). (Keep for update!) third- party ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5479, "Requirements and Analysis of Media Security Management Protocols" Source of RFC: sip (rai) Errata ID: 2122 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2010-04-05 Section App. A says: [[ second-to-last paragraph, on mid-page 24: ]] Related to SRTP's characteristics is a goal that any SRTP keying | mechanism to also be efficient and not cause additional call setup delay. It should say: Related to SRTP's characteristics is a goal that any SRTP keying | mechanism also be efficient and not cause additional call setup delay. Notes: Rationale: language/grammar improvement -- keep for update! ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dale From aallen@rim.com Wed Jan 5 09:05:21 2011 Return-Path: X-Original-To: sipping@core3.amsl.com Delivered-To: sipping@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB553A6C07; Wed, 5 Jan 2011 09:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 d1VJPc6uamPV; Wed, 5 Jan 2011 09:05:19 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id CC3E83A6B89; Wed, 5 Jan 2011 09:05:17 -0800 (PST) X-AuditID: 0a666446-b7bdeae000000a41-7f-4d24a54b0b87 Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 14.A6.02625.B45A42D4; Wed, 5 Jan 2011 12:07:24 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Jan 2011 12:07:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Wed, 5 Jan 2011 11:07:32 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-ietf-sipping-media-policy-dataset issues: mediatypes Thread-Index: AQHLkybTlVHtE3vAWk+tHx2rb1eNZpPCz2lQ References: From: "Andrew Allen" To: "Worley, Dale R (Dale)" , , X-OriginalArrivalTime: 05 Jan 2011 17:07:23.0993 (UTC) FILETIME=[058A9C90:01CBACFB] X-Brightmail-Tracker: AAAAAgAAAZEXFZJ3 Subject: Re: [Sipping] draft-ietf-sipping-media-policy-dataset issues: mediatypes X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 17:05:21 -0000 Dale I am OK with your proposed changes. I also would like to see this draft progress. Andrew -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale) Sent: Friday, December 03, 2010 2:15 PM To: rai@ietf.org; sipping@ietf.org Subject: [Sipping] draft-ietf-sipping-media-policy-dataset issues: mediatypes I am working on draft-ietf-sipping-media-policy-dataset to clean up some issues. These issues are minor technical changes to make the standard more technically coherent and easier to implement. As such, I don't think they will be controversial in their essence, but I would like people to look them over to ensure that I am not introducing new problems. The first issues revolve around media types: 1. 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. 2. 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. The differences for the above two changes are attached, if you want to see the details. 3. 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? Dale =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- draft-ietf-sipping-media-policy-dataset-11.xml (revision 4412) +++ draft-ietf-sipping-media-policy-dataset-11.xml (working copy) @@ -174,7 +174,7 @@ This section discusses fundamental properties of the Media Policy Dataset Format (MPDF). -
+
The MPDF format is based on XML . A MPDF document MUST be @@ -195,7 +195,7 @@ urn:ietf:params:xml:ns:mediadataset - The MIME type for the Media Policy Dataset Format is: + The media type for the Media Policy Dataset Format is: application/media-policy-dataset+xml @@ -949,10 +949,8 @@
Element" anchor=3D"sec:mediatype"> The <media-type> element identifies a specific media - type. The value of this element MUST be the name of a IANA - registered media type (see RFC4566), such as 'audio', 'video', - 'text', or 'application'. + type. The value of this element MUST be the name of a + media type such as 'audio', 'video', 'text', or 'application'. This element MAY have the following attribute (see ): q. @@ -968,11 +966,9 @@
Element"> The <codec> element identifies a specific codec. The - content of this element MUST be a registered MIME type - using media type and subtype (e.g., + content of this element MUST be a media type and subtype (e.g., audio/PCMA or video/H263 - ) and possibly additional registered - MIME type parameters. + ), possibly with parameters. The <codec> element MAY have the following attribute (see ): q. @@ -989,9 +985,9 @@
Element"> - The <mime-type> element contains a MIME type that + The <mime-type> element contains a media type and subtype that identifies a codec. The value of this element MUST be a - combination of a registered MIME media type and subtype + media type and subtype separated by a "/" (e.g., audio/PCMA, audio/G726-16 or video/H263 ). @@ -1003,7 +999,7 @@ The <mime-parameter> element may be needed for some codecs to identify a particular encoding or profile. The value of this element MUST be a name-value pair containing - the name and the value of a registered MIME type parameter + the name and the value of a media type parameter for the codec . The name and value are separated by a "=3D". For example, the parameter "profile=3D0" can be used to specify a specific profile for @@ -1145,9 +1141,7 @@ <max-stream-bw> element only applies to streams of a certain media type. For example, it may only apply to audio streams. The value of the 'media-type' attribute MUST be the - name of a IANA registered media type (see RFC4566), such as 'audio', 'video', - 'text', or 'application'. + media type such as 'audio', 'video', 'text', or 'application'. The label attribute is used to define a bandwidth limit for a specific media stream. The use of this attribute requires that @@ -1190,10 +1184,8 @@ The media-type attribute is used to define that <qos-dscp> element only applies to streams of a certain media type. For example, it may only apply to audio streams. The - value of the 'media-type' attribute MUST be the name of a IANA - registered media type (see RFC4566), such as 'audio', 'video', - 'text', or 'application'. + value of the 'media-type' attribute MUST be the name of a + media type, such as 'audio', 'video', 'text', or 'application'.