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

Ned Freed <ned.freed@mrochek.com> Wed, 28 September 2016 14:59 UTC

Return-Path: <ned.freed@mrochek.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 518E012B1A2 for <media-types@ietfa.amsl.com>; Wed, 28 Sep 2016 07:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.126
X-Spam-Level:
X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mrochek.com
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 g8uX7OLXqhwd for <media-types@ietfa.amsl.com>; Wed, 28 Sep 2016 07:59:24 -0700 (PDT)
Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154C012B196 for <media-types@ietf.org>; Wed, 28 Sep 2016 07:59:23 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u8SEx1cg016203 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <media-types@iana.org>; Wed, 28 Sep 2016 14:59:22 GMT
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q5H5GN2J4000QUYQ@mauve.mrochek.com> for media-types@iana.org; Wed, 28 Sep 2016 07:53:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1475074437; bh=Pl6LbbcGutxkCw1hPl7EzxxPFPQnfeUNCVs0cPvfYPU=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=ZGs6rBU8arXvFrXJ2wb8m6whLMi6LLttir//GnJ9XHQepIOKz5SHxQbyiYW5whqVM qHs+xenWQNaZuaJ1VVBXI40FMKm7ksYJ04UkMh/G47rJ1EDJSNnhp4GN2uf+AHI25q cmB9EsnWO9AnLKTZY2rq1/L3TbIIOifwGxl9rV+o=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"; Format="flowed"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q4N105JRCW00005M@mauve.mrochek.com>; Wed, 28 Sep 2016 07:53:54 -0700 (PDT)
Message-id: <01Q5H5GL1BUC00005M@mauve.mrochek.com>
Date: Wed, 28 Sep 2016 07:48:09 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 28 Sep 2016 07:44:30 -0700" <p06240601d41186590928@[192.168.1.2]>
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]>
To: Randall Gellens <rg+ietf@randy.pensive.org>
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Wed, 28 Sep 2016 14:59:22 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/pv__kgaE8XJfUE-g5F070VVrz1s>
Cc: Mark Baker <distobj@acm.org>, Randall Gellens <rg+ietf@randy.pensive.org>, Ned Freed <ned.freed@mrochek.com>, ecrit-chairs@ietf.org, Brian Rosen <Brian.Rosen@neustar.biz>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, media-types@iana.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: Wed, 28 Sep 2016 14:59:25 -0000

> Hi Ned,

> To be clear, if we want to register the three new types as
> application/EmergencyCallData.*+xml we need option (3), which would
> establish the EmergencyCallData tree as an IETF tree? 

Yes, that's correct, although I can't speak to whether or not you'd 
want the tree restricted to the IETF.

> We would need
> to indicate if it is possible to have vendor, private, and vanity
> facets under this, and indicate the rules for registered
> standards-related uses?  Or am I not understanding the option?

No, that's not what's needed. What you need to do is specify essentially what
the tree is for, who gets to use it, and so on. The same way that RFC 6838
specifies what the trees it defines are for and who gets to use them.

I know very little about these types generally, but given the name
I'm guessing that the rules associated with personal tree would not
be appropriate... Some variation of the rules associated with the standards
(unfaceted) tree would seem to make sense, but as I note above, you
need to decide who gets to use the tree, and the rule for the existing
standards tree (standards organizations recognized as such by the IESG)
may or may not be what you want.

				Ned