Re: [media-types] Review request for application/emergencyCallData.eCall.MSD+per

"HANSEN, TONY L" <tony@att.com> Fri, 30 September 2016 18:25 UTC

Return-Path: <tony@att.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E39812B1D6 for <media-types@ietfa.amsl.com>; Fri, 30 Sep 2016 11:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCawPUCns6AZ for <media-types@ietfa.amsl.com>; Fri, 30 Sep 2016 11:25:55 -0700 (PDT)
Received: from pechora4.lax.icann.org (pechora4.icann.org [192.0.33.74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC2412B1C5 for <media-types@ietf.org>; Fri, 30 Sep 2016 11:25:54 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id u8UIPJxT010615 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <media-types@iana.org>; Fri, 30 Sep 2016 18:25:39 GMT
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u8UIOxG8010530; Fri, 30 Sep 2016 14:25:15 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 25sv1k4vkk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Sep 2016 14:25:14 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u8UIPDfG006669; Fri, 30 Sep 2016 14:25:13 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u8UIOuar006323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Sep 2016 14:25:00 -0400
Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 30 Sep 2016 18:24:44 GMT
Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.113]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0301.000; Fri, 30 Sep 2016 14:24:43 -0400
From: "HANSEN, TONY L" <tony@att.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>, Ned Freed <ned.freed@mrochek.com>
Thread-Topic: [media-types] Review request for application/emergencyCallData.eCall.MSD+per
Thread-Index: AQHSGTDeyq/8MiJJNEG1tCXr9esmj6COe11DgADC8gD//8EmAIAAR54AgAMWXgA=
Date: Fri, 30 Sep 2016 18:24:42 +0000
Message-ID: <56BC1665-8A03-4C95-A715-FB7E98A3ECD7@att.com>
References: <p06240604d408c444a602@99.111.97.136> <CALcoZiqzEVL=R_Yt_v=Yb5Jsq90UrYmZph-DdgUPg8V_tp+iLw@mail.gmail.com> <p0624060ad409bf5d8041@99.111.97.136> <p06240601d40f4d71cf0a@99.111.97.136> <CALcoZioe5NW56ZRiZ+irc=E=X3BSrOxXq=0v_Q0Y1b+_ze0Znw@mail.gmail.com> <01Q5FW9PDQ3W00005M@mauve.mrochek.com> <p06240605d410dbe81638@[99.111.97.136]> <01Q5GOYB35LG00005M@mauve.mrochek.com> <p06240601d41186590928@[192.168.1.2]> <01Q5H5GL1BUC00005M@mauve.mrochek.com> <p06240603d4118e1ada5a@[192.168.1.2]>
In-Reply-To: <p06240603d4118e1ada5a@[192.168.1.2]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.110.241.193]
Content-Type: text/plain; charset="utf-8"
Content-ID: <37E58C598D9B2F4BB85C96B72747F318@LOCAL>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-30_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609280000 definitions=main-1609300337
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Fri, 30 Sep 2016 18:25:39 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/KP53XBcJ6HU-yk9-fQU2ZiEscyo>
Cc: Mark Baker <distobj@acm.org>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "ecrit-chairs@ietf.org" <ecrit-chairs@ietf.org>, "media-types@iana.org" <media-types@iana.org>, Brian Rosen <Brian.Rosen@neustar.biz>
Subject: Re: [media-types] Review request for application/emergencyCallData.eCall.MSD+per
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2016 18:25:56 -0000

Hi Randy.

What you’re talking about is creating an additional “registration tree”, which is governed by RFC 6838 section 3.5:

       3.5.  Additional Registration Trees

          From time to time and as required by the community, new top-level
          registration trees may be created by IETF Standards Action.  It is
          explicitly assumed that these trees may be created for external
          registration and management by well-known permanent organizations;
          for example, scientific societies may register media types specific
          to the sciences they cover.  In general, the quality of review of
          specifications for one of these additional registration trees is
          expected to be equivalent to registrations in the standards tree by a
          recognized standards-related organization.  When the IETF performs
          such review, it needs to consider the greater expertise of the
          requesting organization with respect to the subject media type.

IMO, such a registration does NOT need to update RFC 6838. You could either make such a registration a separate RFC, or include it as part of an RFC creating those additional EmergencyCallData media types. My slight preference would be a separate RFC, but it certainly would not be required. Note that whatever RFC does it needs to be marked as standards track.

	Tony Hansen

On 9/28/16, 11:15 AM, "media-types on behalf of Randall Gellens" <media-types-bounces@ietf.org on behalf of rg+ietf@randy.pensive.org> wrote:

…
    
    Could this be added to one of the two current drafts that seek to 
    register new application/EmergencyCallData.* types or would this need 
    to be a new standalone draft?  Would the draft need to update RFC 
    6838?