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

Randall Gellens <rg+ietf@randy.pensive.org> Mon, 26 September 2016 22:44 UTC

Return-Path: <rg+ietf@randy.pensive.org>
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 006F712B350 for <media-types@ietfa.amsl.com>; Mon, 26 Sep 2016 15:44:38 -0700 (PDT)
X-Quarantine-ID: <ipe4X3BPFSZy>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
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 ipe4X3BPFSZy for <media-types@ietfa.amsl.com>; Mon, 26 Sep 2016 15:44:36 -0700 (PDT)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782AA12B244 for <media-types@ietf.org>; Mon, 26 Sep 2016 15:44:36 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id u8QMiGPA024601 for <media-types@iana.org>; Mon, 26 Sep 2016 22:44:36 GMT
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 26 Sep 2016 15:44:15 -0700
Mime-Version: 1.0
Message-Id: <p06240601d40f4d71cf0a@[99.111.97.136]>
In-Reply-To: <p0624060ad409bf5d8041@[99.111.97.136]>
References: <p06240604d408c444a602@99.111.97.136> <CALcoZiqzEVL=R_Yt_v=Yb5Jsq90UrYmZph-DdgUPg8V_tp+iLw@mail.gmail.com> <p0624060ad409bf5d8041@[99.111.97.136]>
X-Mailer: Eudora for Mac OS X
Date: Mon, 26 Sep 2016 15:44:13 -0700
To: Mark Baker <distobj@acm.org>, Ned Freed <ned.freed@mrochek.com>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Mon, 26 Sep 2016 22:44:36 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/0smDnqrQfWUY3rjHQJsQ5Y2Xn9A>
Cc: Brian Rosen <Brian.Rosen@neustar.biz>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, media-types@iana.org, ecrit-chairs@ietf.org
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: Mon, 26 Sep 2016 22:44:38 -0000

At 10:11 AM -0700 9/22/16, Randall Gellens wrote:

>  At 9:54 AM -0400 9/22/16, Mark Baker wrote:
>
>>   Sec 4.2 of RFC 6838 describes the role of the period in subtypes;
>>
>>   "Characters before first dot always specify a facet name"
>>
>>    -- https://tools.ietf.org/html/rfc6838#section-4.2
>>
>>   If you want to register in the standards tree, you'll need to do
>>   something like change the period to something else, e.g. hyphens.
>>   Alternately, you could just slap "vnd." on the front.
>
>  Oops.  I should have known this, but didn't.  I'm sorry.  The 
> problem in fixing this is that the current two drafts, which 
> register the three new subtypes, are adding on to RFC 7852 
> (https://tools.ietf.org/html/rfc7852), which registered the 
> following MIME types:
>
>  	application/EmergencyCallData.ProviderInfo+xml
>  	application/EmergencyCallData.ServiceInfo+xml
>  	application/EmergencyCallData.DeviceInfo+xml
>  	application/EmergencyCallData.SubscriberInfo+xml
>  	application/EmergencyCallData.Comment+xml
>
>  These have been registered by IANA (e.g., 
> https://www.iana.org/assignments/media-types/application/EmergencyCallData.ProviderInfo+xml), 
> are referenced in several NENA documents, and I belive there are 
> implementations.
>
>  We want the three new subtypes to follow the same pattern, which is 
> that 'EmergencyCallData' is a parent and the various subtypes are 
> children within that.
>
>  So, given this, how do we proceed?

I have a proposed solutions:

We treat "EmergencyCallData" as a parallel to a facet, since it 
serves an analogous purpose: it establishes a naming subspace that 
has a particular meaning.  Everything registered under 
Application/EmergencyCallData is for data sent with an emergency call 
and is eligible to be in the IANA Emergency Call Data Types registry. 
We can add text to one of the current two drafts to say so.  That 
draft might need to indicate that it updates Appendix A of RFC 6838 
to permit "EmergencyCallData." as a media subtype prefix, reserved 
for data sent during an emergency call.  We can say that this is not 
applicable in any other situation and is not a precedent.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
As of 1992...the money that had been made since the dawn of
aviation by all of this country's airline companies was zero.
Absolutely zero.
    --Warren Buffett, billionaire investor, interview 1999