From poulin@ebu.ch Mon Oct 3 08:13:53 2016 Return-Path: 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 3ED3512B35F for ; Mon, 3 Oct 2016 08:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.663 X-Spam-Level: X-Spam-Status: No, score=0.663 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 fWBGh4AmSdFY for ; Mon, 3 Oct 2016 08:13:50 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04A112B36A for ; Mon, 3 Oct 2016 08:13:34 -0700 (PDT) Received: from mailgate4.ebu.ch (mailgate4.ebu.ch [193.43.93.76]) by pechora8.dc.icann.org (Postfix) with ESMTP id 30B6EC0B9A; Mon, 3 Oct 2016 15:13:33 +0000 (UTC) Received: from smtp2010.ebu.ch (HELO maildrs.gva.ebu.ch) ([10.73.222.142]) by mailgate4.ebu.ch with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Oct 2016 17:13:10 +0200 Received: from MAILPRD.gva.ebu.ch ([fe80::d915:3098:d72d:8897]) by maildrs.gva.ebu.ch ([10.73.222.142]) with mapi id 14.03.0301.000; Mon, 3 Oct 2016 17:13:10 +0200 From: "Poulin, Felix" To: "ietf-types@iana.org" Thread-Topic: =?Windows-1252?Q?Registration_of_attribute_parameter_"att-field/sdp"_=96_?= =?Windows-1252?Q?=93ebuacip=94?= Thread-Index: AQHSA6F/tsSayMgzU0akSdb8KNGSBqCXCRaw Date: Mon, 3 Oct 2016 15:13:10 +0000 Message-ID: <346D5FB8A0E12F4F9CCCF086D4EB9DF7FB2FAC09@mailprd.gva.ebu.ch> References: In-Reply-To: Accept-Language: en-GB, fr-CA, fr-CH, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.73.220.154] MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Mon, 03 Oct 2016 09:14:10 -0700 Cc: "iana@iana.org" Subject: [media-types] =?windows-1252?q?Registration_of_attribute_paramete?= =?windows-1252?q?r_=22att-field/sdp=22_=96_=93ebuacip=94?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 15:14:55 -0000 Please register the following new SDP Attribute: Contact name, email address, and telephone number: Felix Poulin, EBU-FNS Coordinator poulin@ebu.ch +41(0)22 717 27 42 Attribute Name (as it will appear in SDP): ebuacip Long-form Attribute Name in English: EBU ACIP (Audio Contribution over IP) Profile Type of Attribute: Media level Is Attribute Value subject to the Charset Attribute? This Attribute is not dependent on charset. Purpose of the attribute: This attribute specifies a set of parameters, called a profile, to be negot= iated with an end user agent. Appropriate Attribute Values for this Attribute: The attribute is a value attribute. The values "version", =93jb=94, =93jbde= f=94, =93plength=94, =93qosrec=94 and =93protp=94 are defined. We are expecting this to be registered at the following URL: http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xh= tml#sdp-parameters-9 The public specification of the document that contains the above registrati= on information is: EBU Tech 3368 - Audio Contribution over IP =96 Profiles and maybe obtained = from here: https://tech.ebu.ch/= publications/tech3368 If you require any further information, please contact me. F=E9lix Poulin, EBU ---------------------------------------------------------------------------= --- ************************************************** This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager.= This footnote also confirms that this email message has been swept by the = mailgateway ************************************************** From nobody Mon Oct 3 15:24:21 2016 Return-Path: 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 0834C129452 for ; Mon, 3 Oct 2016 15:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7q20NC60yRcP for ; Mon, 3 Oct 2016 15:24:18 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC38112945D for ; Mon, 3 Oct 2016 15:24:17 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id j129so168995950qkd.1 for ; Mon, 03 Oct 2016 15:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o7DvRgJEggQDqQm/uAsYsXyNIhUNfkAGVu8s9MSDHZA=; b=YU5utoXOmZYROc6NheVUhFN3v0V73Wx7zJkijYHQG/SD6/RXR4j1cPj0TYgx/NuhgW ui75QeFsyaxNU88SC7tuJOI1hNC4HlwXvjALfh07QPoS43j6LQJWblOws7IlP9xtGlb1 9MkfTqA2Zv7if2xna8BMrx+NE4l8+UVd6FwG7+V1a5hIFklzASqCLThBkHA1i149x9nI ld4XUP4QBKMq/MKYgU6PhBUUkeNsALLTIbeCBof9EUgOHbXYQABaSNvSX45j64AwdWuf gIr8XQcss//cJhW2KIIvaD8t9HXBuUePYeDvjYBwQ/MJGBMpe/SoGt6T6BwmiAt1VAKX 26rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o7DvRgJEggQDqQm/uAsYsXyNIhUNfkAGVu8s9MSDHZA=; b=FwkoLazVzVdpo2m+f8nJrOcpRQenpP/0wdmjycCqsxWjXGBuihqmu+Yo1DYXWe5RXF KdNYPD5C2yT58BVF3ObBpeb/T6a2+PMzhJDgEjLOs1k0f/sRsjUblZpiShc0n9pdpg/l a0VVRwQD/Bu0cXbxmcXRUZm6iv91ES+we5Lo6F3krUIAh3Xmxv0o3jyyyXcxX1/EZozc qdcoFYBSJngdeHtbArAnJbI9vhXVdC+vJm1lwPeG9Xp1OK3Vowm2HVe5KjufDNHe6DEP J+I6Gcttxevl/MBGPsVt8+QWlwRgOXQC8pz+SZamgq7PkGtpBFjgKtx/xv1g+kg2D6J/ t3Xg== X-Gm-Message-State: AA6/9RmbKP64Z0B/Kfx1xoATQ7VXwpWz2c7cowUETxynOzJzG7xnWZAxA+TsHjAjhzPijbX5LDb233VpEKeY8w== X-Received: by 10.55.41.12 with SMTP id p12mr399502qkh.141.1475533456893; Mon, 03 Oct 2016 15:24:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.164.132 with HTTP; Mon, 3 Oct 2016 15:24:16 -0700 (PDT) In-Reply-To: <57D6EBD4.501@isode.com> References: <57D6EBD4.501@isode.com> From: Nik Tomkinson Date: Mon, 3 Oct 2016 23:24:16 +0100 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a1140473e8d6c93053dfd6755 Archived-At: Cc: media-types@ietf.org Subject: Re: [media-types] multipart/multilingual registration request 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 22:24:20 -0000 --001a1140473e8d6c93053dfd6755 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Alexey for your comments. I'll update the IANA section accordingly. I'd rather be clear and mention the non-compliant part even if it is a bit superfluous. Nik. On 12 September 2016 at 18:54, Alexey Melnikov wrote: > Hi Nik, > > On 09/09/2016 13:43, Nik Tomkinson wrote: > > Hi All, > > > > I am working on this template but I need some advice from anyone who > knows > > this sort of this thing well and has experience in this area. > > > > It is for this I-D: https://datatracker.ietf.org/doc/draft-ietf-slim- > multilangcontent/ > > > > > > My initial suggestion would be: > > > > Media Type name: multipart > > > > Media subtype name: multilingual > > > > Required parameters: boundary (defined in RFC2046) > > > > Optional parameters: N/A > > > > Encoding considerations: ? > > > > Security considerations: See the Security Considerations section = in > > this document > > > > Interoperability considerations: > > Existing systems that do not treat unknown multipart subtypes > > as multipart/mixed may not correctly render a > > multipart/multilingual type. > > Strictly speaking such systems are already non compliant with MIME. > > > > > Published specification: This document > > > > Applications that use this media type: > > Mail Transfer Agents, Mail User Agents, spam detection, > > virus detection modules and message authentication modules. > > > > Additional information: > > > > Deprecated alias names for this type: N/A > > Magic number(s): N/A > > File extension(s): N/A > > Macintosh file type code(s): N/A > > > > Person & email address to contact for further information: > > Nik Tomkinson > > rfc.nik.tomkinson@gmail.com gmail.com> > > > > Nathaniel Borenstein > > nsb@mimecast.com > > > > Intended usage: Common > > > > > > > > But I am not sure about the encoding considerations because the IANA > > 'Application for a Media Type' form at http://www.iana.org/form/media- > > types includes these options: > > - 7-bit text > > - 8-bit text (this media type may require encoding on transports not > > capable of handling 8-bit text) > > - binary (this media type may require encoding on transports not > capable > > of handling binary) > > > > but it also refers to RFC 6838 =C2=A74.8 > > which lists: > > - 7bit: The content of the media type consists solely of > CRLF-delimited > > 7bit US-ASCII text. > > - 8bit: The content of the media type consists solely of > CRLF-delimited > > 8bit text. > > - binary: The content consists of an unrestricted sequence of octets= . > > > > I have seen from examples of other registered MIME types that the > wording > > is not always the same as above but, given that there is a registratio= n > > form with strict definitions, I am at a bit of a loss which I should > > specify. > > I think you should use something like this: > > only "7bit", "8bit", or "binary" are permitted > > This is the same as used by > > > Best Regards, > Alexey > > > > > Can anyone offer a suggestion? > > > > Thanks in advance, > > > > Nik. > > > > > > -- > > > > ----------------------------------------------------------------- > > Multiple Language Content Type Internet Draft: > > > > > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > > > > > > ----------------------------------------------------------------- > > --=20 ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- --001a1140473e8d6c93053dfd6755 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Alexey for your comments.

I'= ll update the IANA section accordingly. I'd rather be clear and mention= the non-compliant part even if it is a bit superfluous.

Nik.

On 12 September 2016 at 18:54, Alexey Melnikov <= alexey.melni= kov@isode.com> wrote:
Hi Ni= k,

On 09/09/2016 13:43, Nik Tomkinson wrote:
>=C2=A0 Hi All,
>
>=C2=A0 I am working on this template but I need some advice from anyone= who knows
>=C2=A0 this sort of this thing well and has experience in this area. >
>=C2=A0 It is for this I-D: htt= ps://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/
>
>
>=C2=A0 My initial suggestion would be:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Media Type name: multipart
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Media subtype name: multilingual
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Required parameters: boundary (defined in RF= C2046)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Optional parameters: N/A
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Encoding considerations: ?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Security considerations: See the Security Co= nsiderations section in
>=C2=A0 this document
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Interoperability considerations:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Existing systems that do not t= reat unknown multipart subtypes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as multipart/mixed may not cor= rectly render a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multipart/multilingual type.
Strictly speaking such systems are already non compliant with MIME.<= br>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Published specification: This document
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Applications that use this media type:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mail Transfer Agents, Mail Use= r Agents, spam detection,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0virus detection modules and me= ssage authentication modules.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Additional information:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Deprecated alias names for thi= s type: N/A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Magic number(s): N/A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0File extension(s): N/A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Macintosh file type code(s): N= /A
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Person & email address to contact for fu= rther information:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nik Tomkinson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rfc.nik.tomkinson@gmail.com <mailto:rfc.nik.tomkinson@gmail.com>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nathaniel Borenstein
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nsb@mimecast.com <mailto:n= sb@mimecast.com>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Intended usage: Common
>
>
>
>=C2=A0 But I am not sure about the encoding considerations because the = IANA
>=C2=A0 'Application for a Media Type' form at http://www.= iana.org/form/media-
>=C2=A0 types includes these options:
>=C2=A0 =C2=A0- 7-bit text
>=C2=A0 =C2=A0- 8-bit text (this media type may require encoding on tran= sports not
>=C2=A0 capable of handling 8-bit text)
>=C2=A0 =C2=A0- binary (this media type may require encoding on transpor= ts not capable
>=C2=A0 of handling binary)
>
>=C2=A0 but it also refers to RFC 6838 =C2=A74.8
>=C2=A0 which lists:
>=C2=A0 =C2=A0- 7bit:=C2=A0 The content of the media type consists solel= y of CRLF-delimited
>=C2=A0 7bit US-ASCII text.
>=C2=A0 =C2=A0- 8bit:=C2=A0 The content of the media type consists solel= y of CRLF-delimited
>=C2=A0 8bit text.
>=C2=A0 =C2=A0- binary:=C2=A0 The content consists of an unrestricted se= quence of octets.
>
>=C2=A0 I have seen from examples of other registered MIME types that th= e wording
>=C2=A0 is not always the same as above but, given that there is a regis= tration
>=C2=A0 form with strict definitions, I am at a bit of a loss which I sh= ould
>=C2=A0 specify.

I think you should use something like this:

=C2=A0 only "7bit", "8bit", or "binary" are p= ermitted

This is the same as used by
<http://www.iana.org/assignm= ents/media-types/multipart/byteranges>

Best Regards,
Alexey

>
>=C2=A0 Can anyone offer a suggestion?
>
>=C2=A0 Thanks in advance,
>
>=C2=A0 Nik.
>
>
> --
>
> ------------------------------------------------------------= -----
> Multiple Language Content Type Internet Draft:
>
> <http://datatracker.= ietf.org/doc/draft-tomkinson-multilangcontent/>https://datatracker.ietf.org/doc/dr= aft-ietf-slim-multilangcontent/
> <http://datatracker.ie= tf.org/doc/draft-tomkinson-slim-multilangcontent/>
>
> ------------------------------------------------------------= -----




-- 
-------------------------------=
----------------------------------
Multiple Language Content Type Intern=
et Draft:
https://datatracker.= ietf.org/doc/draft-ietf-slim-multilangcontent/
-----------------------------------------=
------------------------
--001a1140473e8d6c93053dfd6755-- From nobody Fri Oct 7 13:54:22 2016 Return-Path: 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 BFBC812941E for ; Fri, 7 Oct 2016 13:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 ToOiJJ9ReFT9 for ; Fri, 7 Oct 2016 13:54:19 -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 531221293EB for ; Fri, 7 Oct 2016 13:54:19 -0700 (PDT) Received: from smtp153.dfw.emailsrvr.com (smtp153.dfw.emailsrvr.com [67.192.241.153]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u97KrwIQ022037 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 7 Oct 2016 20:54:18 GMT Received: from smtp20.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp20.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id A4EA6E0364; Fri, 7 Oct 2016 16:53:57 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp20.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 57A72E0404; Fri, 7 Oct 2016 16:53:57 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.90.15] ([UNAVAILABLE]. [128.107.241.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Fri, 07 Oct 2016 16:53:57 -0400 From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_C2E35033-74AD-4246-9251-7C27724FF2F0" Date: Fri, 7 Oct 2016 13:53:56 -0700 Message-Id: To: media-types@iana.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Fri, 07 Oct 2016 20:54:18 +0000 (UTC) Archived-At: Cc: Core WG mailing list Subject: [media-types] Request review for application/senml+json and related types 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:54:21 -0000 --Apple-Mail=_C2E35033-74AD-4246-9251-7C27724FF2F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would like to request review for a handful of related mime types = specified in=20 https://tools.ietf.org/html/draft-ietf-core-senml-03 = Thank you, Cullen --Apple-Mail=_C2E35033-74AD-4246-9251-7C27724FF2F0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

I would like to request review for a handful of related mime types specified in 


Thank you, Cullen


--Apple-Mail=_C2E35033-74AD-4246-9251-7C27724FF2F0-- From nobody Fri Oct 7 18:44:24 2016 Return-Path: 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 E074D1294C2 for ; Fri, 7 Oct 2016 18:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 a6cv6xO_SNe5 for ; Fri, 7 Oct 2016 18:44:21 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA50129424 for ; Fri, 7 Oct 2016 18:44:21 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id u981i0WX010245 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 8 Oct 2016 01:44:20 GMT Received: by mail-io0-x234.google.com with SMTP id q192so63601479iod.0 for ; Fri, 07 Oct 2016 18:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fKyo2qFCf6FTTQa+k7O2EacmEwz+KKKgIFvGQ+f3GVU=; b=RKNM4FPA3M9ePCqr0EE8yG2QcOPLY7hU/DGv7mCo/Ztzv+KUY1Bs37haclqtUDiFz0 4RmeAWVpGTjGEvS3bLOF11pST7orMKCjTPjSh+xruw3dP2wiw0iNdpUW2OwOc1gfgB/7 7PFMBn8cCD/U44urbpGAK23YFmr6gawEoOtJPYwndrAoC4I8wtgrQqZNp3UNZ5dtRz22 lnhQCXMp2VFoG4laqW/2zDCkUMdVQcbwCOOYEpvWz/wxDdgBShRsLDAePE7etNjqm49L oDBUPz0SKV2iU+qfR3WFLsktamp9aipe4v0ebsDq9y3Mig+NnbrQcWr595IvmsZ7hXwu ydCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fKyo2qFCf6FTTQa+k7O2EacmEwz+KKKgIFvGQ+f3GVU=; b=IO5YgIUE4b0v22WS5Sognz6mvnv+LMuy0ORnxpvYRm6b78y3si3lhheGVnpni3hGs6 7Z4GaLm9NHn4FOewnLod+dpjBn3slyYj0HpFSSGvbUSMgnupkZwNe62Dj6kG55S+IYup IrACJk+pNlfPgd0TZCk7ziYMslF4cUBpQnrjiabl5IJ99pg9FpkOVwF3W/UUCmTzu4oz uXr9scP2t5IiepXDNdSJshDHr0vMDPM7Cu80d44rxOseFPcF7S/BUBlIDhmdOPw9rJT5 CPUfheudy8HxmfZxJt9D3BbTaZR2Ro2wAP1gNkSzcOHwiQw2O3+Cwi+l3R82ac/KgUFZ 9tlw== X-Gm-Message-State: AA6/9RnNHqtYwrwOgOwTteiTDuxBuq4JsyI8v7+ePTlgqVW5Gc61KZEp6bzI1C8+nIGepTjzIUW6p/QJpSUenw== X-Received: by 10.107.39.66 with SMTP id n63mr9291583ion.180.1475891039969; Fri, 07 Oct 2016 18:43:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.147.6 with HTTP; Fri, 7 Oct 2016 18:43:39 -0700 (PDT) In-Reply-To: References: From: Ira McDonald Date: Fri, 7 Oct 2016 21:43:39 -0400 Message-ID: To: Cullen Jennings , Ira McDonald Content-Type: multipart/alternative; boundary=001a114076502a2556053e50a95b X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Sat, 08 Oct 2016 01:44:20 +0000 (UTC) Archived-At: Cc: media-types@iana.org, Core WG mailing list Subject: Re: [media-types] Request review for application/senml+json and related types 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 01:44:23 -0000 --001a114076502a2556053e50a95b Content-Type: text/plain; charset=UTF-8 Hi Cullen, Usual response - please send the actual registration templates in plaintext in an email to the Media Types list. Then the edits needed (there always are some) are clearly documented on the mailing list. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Fri, Oct 7, 2016 at 4:53 PM, Cullen Jennings wrote: > > I would like to request review for a handful of related mime types > specified in > > https://tools.ietf.org/html/draft-ietf-core-senml-03 > > Thank you, Cullen > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > > --001a114076502a2556053e50a95b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Cullen,

Usua= l response - please send the actual registration templates
in pla= intext in an email to the Media Types list.=C2=A0 Then the edits
n= eeded (there always are some) are clearly documented on
the mailin= g list.

Cheers,
- Ira


Ira McDonald = (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solution= s WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO = Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protoco= l WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music /= High North Inc
http://sites.google.com/sit= e/blueroofmusic
http://sites.google.com/= site/highnorthinc
mailto: blueroofmusic@gmail.com
Jan-April: 579 Park Place= =C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
May-Dec: PO Box 221=C2= =A0 Grand Marais, MI 49839=C2=A0 906-494-2434


On Fri, Oct 7, 2016 at 4:53 PM, Cullen Jenni= ngs <fluffy@iii.ca> wrote:

I would like to reques= t review for a handful of related mime types specified in=C2=A0
<= br>

Thank you, Cullen



_______________________________________________<= br> media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-ty= pes


--001a114076502a2556053e50a95b-- From nobody Sat Oct 8 11:42:06 2016 Return-Path: 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 4ABFB129550 for ; Sat, 8 Oct 2016 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 fHGLjfeqtYtU for ; Sat, 8 Oct 2016 11:42:02 -0700 (PDT) Received: from pechora6.dc.icann.org (pechora6.icann.org [IPv6:2620:0:2830:201::1:72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C7E129493 for ; Sat, 8 Oct 2016 11:42:01 -0700 (PDT) Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora6.dc.icann.org (Postfix) with ESMTPS id F380A1E0C23 for ; Sat, 8 Oct 2016 18:42:00 +0000 (UTC) Received: from smtp34.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp34.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C7D9924C1B; Sat, 8 Oct 2016 14:32:47 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp34.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 127C924BA1; Sat, 8 Oct 2016 14:32:46 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.57.2] ([UNAVAILABLE]. [128.107.241.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Sat, 08 Oct 2016 14:32:47 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_9D3CE170-2B11-4EB0-8340-C3F94C36981B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Sat, 8 Oct 2016 11:32:45 -0700 Message-Id: <247A9C78-69D5-4725-A670-F556A2223F66@iii.ca> References: To: Ira McDonald X-Mailer: Apple Mail (2.3124) Archived-At: Cc: media-types@iana.org, Core WG mailing list Subject: Re: [media-types] Request review for application/senml+json and related types 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 18:42:04 -0000 --Apple-Mail=_9D3CE170-2B11-4EB0-8340-C3F94C36981B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sure - here it is=20 11.3.1. senml+json Media Type Registration Type name: application Subtype name: senml+json and sensml+json Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using a subset of the encoding allowed in [RFC7159]. See RFC-AAAA for details. This simplifies implementation of very simple system and does not impose any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information. This format does not provide any security and instead relies on the transport protocol that carries it to provide security. Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. Interoperability considerations: Applications should ignore any JSON key value pairs that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the JSON object. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems that report e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems. Additional information: Magic number(s): none File extension(s): senml and sensml Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG 11.3.2. senml+cbor Media Type Registration Type name: application Subtype name: senml+cbor and sensml+cbor Required parameters: none Optional parameters: none Encoding considerations: TBD Security considerations: See Section 11.3.1 Interoperability considerations: TBD Published specification: RFC-AAAA Applications that use this media type: See Section 11.3.1 Additional information: Magic number(s): none File extension(s): senmlc and sensmlc Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG 11.3.3. senml+xml Media Type Registration Type name: application Subtype name: senml+xml and sensml+xml Required parameters: none Optional parameters: none Encoding considerations: TBD Security considerations: See Section 11.3.1 Interoperability considerations: TBD Published specification: RFC-AAAA Applications that use this media type: See Section 11.3.1 Additional information: Magic number(s): none File extension(s): senmlx and sensmlx Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG 11.3.4. senml+exi Media Type Registration Type name: application Subtype name: senml+exi and sensml+exi Required parameters: none Optional parameters: none Encoding considerations: TBD Security considerations: TBD Interoperability considerations: TBD Published specification: RFC-AAAA Applications that use this media type: See Section 11.3.1 Additional information: Magic number(s): none File extension(s): senmle and sensmle Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG > On Oct 7, 2016, at 6:43 PM, Ira McDonald = wrote: >=20 > Hi Cullen, >=20 > Usual response - please send the actual registration templates=20 > in plaintext in an email to the Media Types list. Then the edits > needed (there always are some) are clearly documented on > the mailing list. >=20 > Cheers, > - Ira >=20 >=20 > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic = > http://sites.google.com/site/highnorthinc = > mailto: blueroofmusic@gmail.com > Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 > May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 >=20 > On Fri, Oct 7, 2016 at 4:53 PM, Cullen Jennings > wrote: >=20 > I would like to request review for a handful of related mime types = specified in=20 >=20 > https://tools.ietf.org/html/draft-ietf-core-senml-03 = >=20 > Thank you, Cullen >=20 >=20 >=20 > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types = >=20 >=20 --Apple-Mail=_9D3CE170-2B11-4EB0-8340-C3F94C36981B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Sure - here it = is 


11.3.1.  senml+json = Media Type Registration

   Type name: application

   Subtype name: senml+json = and sensml+json

   Required parameters: none
   Optional parameters: = none

  =  Encoding considerations: Must be encoded as using a subset of = the
   encoding allowed in [RFC7159]. =  See RFC-AAAA for details.  This
  =  simplifies implementation of very simple system and does not = impose
   any significant limitations as = all this data is meant for machine to
  =  machine communications and is not meant to be human = readable.

 =  Security considerations: Sensor data can contain a wide range = of
   information ranging from = information that is very public, such the
  =  outside temperature in a given city, to very private information = that
   requires integrity and = confidentiality protection, such as patient
  =  health information.  This format does not provide any = security and
   instead relies on the = transport protocol that carries it to provide
  =  security.  Given applications need to look at the overall = context of
   how this media type will be = used to decide if the security is
  =  adequate.

   Interoperability considerations: Applications = should ignore any JSON
   key value pairs = that they do not understand.  This allows backwards
   compatibility extensions to this specification. =  The "bver" field can
   be used to = ensure the receiver supports a minimal level of
   functionality needed by the creator of the JSON = object.

  =  Published specification: RFC-AAAA

   Applications that use this = media type: The type is used by systems
  =  that report e.g., electrical power usage and = environmental
   information such as = temperature and humidity.  It can be used for a
   wide range of sensor reporting = systems.

  =  Additional information:

   Magic number(s): = none

  =  File extension(s): senml and sensml

   Macintosh file type = code(s): none

   Person & email address to contact for = further information: Cullen
   Jennings = <fluffy@iii.ca>

   Intended usage: = COMMON

  =  Restrictions on usage: None

   Author: Cullen Jennings = <fluffy@iii.ca>

   Change controller: = IESG


11.3.2.  senml+cbor Media Type = Registration

   Type name: application

   Subtype name: senml+cbor = and sensml+cbor

   Required parameters: none
   Optional parameters: = none

  =  Encoding considerations: TBD

   Security considerations: = See Section 11.3.1

   Interoperability considerations: TBD

   Published = specification: RFC-AAAA

   Applications that use this media type: See = Section 11.3.1

   Additional information:

   Magic number(s): = none

  =  File extension(s): senmlc and sensmlc

   Macintosh file type = code(s): none

   Person & email address to contact for = further information: Cullen
   Jennings = <fluffy@iii.ca>

   Intended usage: = COMMON

  =  Restrictions on usage: None

   Author: Cullen Jennings = <fluffy@iii.ca>

   Change controller: = IESG

11.3.3. =  senml+xml Media Type Registration

   Type name: = application

   Subtype name: senml+xml and sensml+xml

   Required = parameters: none

   Optional parameters: none
   Encoding considerations: = TBD

  =  Security considerations: See Section 11.3.1
   Interoperability = considerations: TBD

   Published specification: RFC-AAAA

  =  Applications that use this media type: See Section = 11.3.1

  =  Additional information:

   Magic number(s): = none

  =  File extension(s): senmlx and sensmlx

   Macintosh file type = code(s): none

   Person & email address to contact for = further information: Cullen
   Jennings = <fluffy@iii.ca>

   Intended usage: = COMMON

  =  Restrictions on usage: None

   Author: Cullen Jennings = <fluffy@iii.ca>

   Change controller: = IESG

11.3.4. =  senml+exi Media Type Registration

   Type name: = application

   Subtype name: senml+exi and sensml+exi

   Required = parameters: none

   Optional parameters: none
   Encoding considerations: = TBD

  =  Security considerations: TBD

   Interoperability = considerations: TBD

   Published specification: RFC-AAAA

  =  Applications that use this media type: See Section = 11.3.1

  =  Additional information:

   Magic number(s): = none

  =  File extension(s): senmle and sensmle

   Macintosh file type = code(s): none

   Person & email address to contact for = further information: Cullen
   Jennings = <fluffy@iii.ca>

   Intended usage: = COMMON

  =  Restrictions on usage: None

   Author: Cullen Jennings = <fluffy@iii.ca>

   Change controller: = IESG




On Oct 7, 2016, at 6:43 PM, Ira McDonald <blueroofmusic@gmail.com> wrote:

Hi Cullen,

Usual response - please send the actual registration = templates
in plaintext in an email to the Media = Types list.  Then the edits
needed (there = always are some) are clearly documented on
the = mailing list.

Cheers,
- Ira


Ira = McDonald (Musician / Software Architect)
Co-Chair - TCG = Trusted Mobility Solutions WG
Chair - Linux Foundation = Open Printing WG
Secretary - IEEE-ISTO Printer Working = Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol = WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Jan-April: 579 Park Place  Saline, MI  48176  = 734-944-0094
May-Dec: PO Box 221  Grand Marais, MI = 49839  906-494-2434


On Fri, Oct 7, 2016 at 4:53 = PM, Cullen Jennings <fluffy@iii.ca> wrote:

I would = like to request review for a handful of related mime types specified = in 

https://tools.ietf.org/html/draft-ietf-core-senml-03

Thank you, Cullen



_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types



= --Apple-Mail=_9D3CE170-2B11-4EB0-8340-C3F94C36981B-- From nobody Sat Oct 8 14:16:11 2016 Return-Path: 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 9813E1293F0 for ; Sat, 8 Oct 2016 14:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 desz4-6-YbMq for ; Sat, 8 Oct 2016 14:16:09 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [192.0.33.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D435E1293EE for ; Sat, 8 Oct 2016 14:16:09 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by pechora2.lax.icann.org (Postfix) with ESMTP id 8A0A81E0C30 for ; Sat, 8 Oct 2016 21:15:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1475961317; d=isode.com; s=june2016; i=@isode.com; bh=4DXB634cx5GfhPEifBTxajzwskzeHMEfjq6YR9gXNLs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=lIuOok+ZucxfE1TPGrKR9PFwtgydh+QEnX4wHztJFB7zLDlsUCmnln/Rv6jtp9vDpha0GN 3Z7mEVKXvXdmyT94cmE0bhkjespNpb1ApstYfeWos0iyJXRMADOQsbeMNxTb7kUMwqJ69M h40882E2PfEgaNAxF8ehsvd3Fm0NGK0=; Received: from [10.8.219.244] ((unknown) [148.252.128.246]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 8 Oct 2016 22:15:17 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: <247A9C78-69D5-4725-A670-F556A2223F66@iii.ca> Date: Sat, 8 Oct 2016 22:18:54 +0100 Message-Id: <796B1579-635A-4D08-83BE-77B771D6D803@isode.com> References: <247A9C78-69D5-4725-A670-F556A2223F66@iii.ca> To: Cullen Jennings MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: Ira McDonald , media-types@iana.org, Core WG mailing list Subject: Re: [media-types] Request review for application/senml+json and related types 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 21:16:10 -0000 Hi Cullen, There are several TBD in your registrations that need to be fixed first. From nobody Mon Oct 17 05:13:49 2016 Return-Path: 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 4EF17129634 for ; Mon, 17 Oct 2016 05:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net 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 ijceVaE5jzuR for ; Mon, 17 Oct 2016 05:13:45 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [192.0.33.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B96129639 for ; Mon, 17 Oct 2016 05:13:45 -0700 (PDT) Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora1.lax.icann.org (Postfix) with ESMTPS id A25921E0184 for ; Mon, 17 Oct 2016 12:13:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:To:From:Cc:References:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Vlxx1lM2UYXnJc8XNcq4A0eMOaAXg4cIkVqx5BEJeb8=; b=ShPAeqMuN6j3++0/u8a6tewA/a QPIRybYtGKNphejTtdC04C51HR3611TWXNOQli/O2KKjIsq3VB3SW7oCmxFhisk3nN4O9Qv738Y4V qV9B3M0bhZ4efMwQQRnIPjwU58JhshyROJbmLQYIdWpnrMo1BJK6xgaWrh8k8ttj9CEwfO1ub1/Lf A0W/f+XpV3dbdGAxS46P1jnJetYyVbIFDaaaGV+6eEku6jvS1INMzpU6ew53hO4zZGnU1/JS6l8gv CFWULRjLOtLqMNiunBlqyNbCH+x8SCxAXlM1npfNKK4C0CCEph7SEkk1IVrbN4jY32FJBDrN2rQxP dVLse8IQ==; Received: from 154.80.5.85.dynamic.wline.res.cust.swisscom.ch ([85.5.80.154]:49539 helo=dretpro.home) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bw6ml-0006T9-0d; Mon, 17 Oct 2016 08:12:55 -0400 References: <8CE835AF-B228-4623-BDDE-D4B7DD006A6B@dret.net> <31406b75-16fe-3aed-fa16-ca4ad46f255d@dret.net> <9125c52c-ce66-2bff-0674-d2ce737b0014@dret.net> <696edcc0-ffd2-0edb-b432-78a38481d46e@dret.net> From: Erik Wilde To: media-types@iana.org, art@ietf.org Message-ID: Date: Mon, 17 Oct 2016 14:12:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - iana.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: Mark Baker , geojson@ietf.org Subject: [media-types] moving forward with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 12:13:47 -0000 hello. On 2016-09-26 19:20, Mark Baker wrote: > Ah, I hadn't forgotten all about RFC 7464. Yes, registering the suffix > in that light makes ample sense. Thanks, Erik. https://tools.ietf.org/html/draft-wilde-json-seq-suffix seems to be reasonable enough that nobody has objected to it. we would like to move forward with this so that we can use it for a media type that we are working on in the GeoJSON working group. what is the best way to move forward? as requested by https://tools.ietf.org/html/rfc6838#section-6, i have created a registration template here: https://tools.ietf.org/html/draft-wilde-json-seq-suffix-00#section-4 i am including this registration template literally to help the review process via media-types@iana.org: ---------------------------------------- Name: JSON Text Sequence +suffix: +json-seq References: [3] Encoding considerations: See [3] Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +json-seq SHOULD be as specified for "application/json-seq". (At publication of this document, there is no fragment identification syntax defined for "application/json-seq".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+json-seq" SHOULD be processed as follows: For cases defined in +json-seq, where the fragment identifier resolves per the +json-seq rules, then process as specified in +json-seq. For cases defined in +json-seq, where the fragment identifier does not resolve per the +json-seq rules, then process as specified in "xxx/yyy+json-seq". For cases not defined in +json-seq, then process as specified in "xxx/yyy+json-seq". Interoperability considerations: n/a Security considerations: See [3] Contact: Applications and Real-Time Area Working Group (art@ietf.org) Author/Change controller: The Applications and Real-Time Area Working Group. IESG has change control over this registration. ---------------------------------------- assuming media-types@iana.org review ends favorably, i guess i'll need a shepherd for this document to move it through the RFC pipeline? what's the best process to find one, or does anybody volunteer? thanks a lot and kind regards, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon Oct 17 08:40:22 2016 Return-Path: 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 DB5E21295EA for ; Mon, 17 Oct 2016 08:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 8hbImg5WXO4M for ; Mon, 17 Oct 2016 08:40:19 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [192.0.33.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F3A1295BF for ; Mon, 17 Oct 2016 08:40:19 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora1.lax.icann.org (Postfix) with ESMTPS id EFB5B1E0184 for ; Mon, 17 Oct 2016 15:40:18 +0000 (UTC) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-03v.sys.comcast.net with SMTP id wA15b42O38GkCwA18bEvsb; Mon, 17 Oct 2016 15:39:58 +0000 Received: from hobgoblin.ariadne.com ([73.16.37.18]) by resomta-ch2-06v.sys.comcast.net with SMTP id wA16b3quPpzyfwA17bkT5d; Mon, 17 Oct 2016 15:39:58 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u9HFdukp004671; Mon, 17 Oct 2016 11:39:56 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u9HFdtJd004668; Mon, 17 Oct 2016 11:39:55 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Erik Wilde In-Reply-To: (erik.wilde@dret.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 17 Oct 2016 11:39:55 -0400 Message-ID: <87eg3fc7ck.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfN3NGmnhivUrMrO9NWeIrmoeN0Al6IRZMF5Aw/lqwoQO9rivAnGpO4k1ACVX/3eS59wkYG/v1T48bngYuwOovm41eC9mprZHotH6FtSRp3xdMtM7hREV jDDTH0WSxCT2ZzSXtJYSD3m4hfUc0D0KXoKz1OVuJd4hnbsOrQ57y/1JD6oYlbGGsMt26RdaUmPs0g60s+dUn4kFUhFVdX2USm8c/k1xGfjwAXqO7krggTic nhrbncmD3VAlHLvAJ7TiyK0JmSV2z0cyrkEuhj7hh1E= Archived-At: Cc: art@ietf.org, geojson@ietf.org, media-types@iana.org, distobj@acm.org Subject: Re: [media-types] [art] moving forward with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 15:40:20 -0000 > The syntax and semantics for fragment identifiers for a > specific "xxx/yyy+json-seq" SHOULD be processed as follows: > > For cases defined in +json-seq, where the fragment > identifier resolves per the +json-seq rules, then process as > specified in +json-seq. > > For cases defined in +json-seq, where the fragment > identifier does not resolve per the +json-seq rules, then > process as specified in "xxx/yyy+json-seq". > > For cases not defined in +json-seq, then process as > specified in "xxx/yyy+json-seq". Everything looks good to me, except that last sentence: Isn't that a duplicate of the preceding paragraph? Dale From nobody Mon Oct 17 11:17:04 2016 Return-Path: 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 1025D12998A for ; Mon, 17 Oct 2016 11:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coactus-com.20150623.gappssmtp.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 MiWdAJ62YFFS for ; Mon, 17 Oct 2016 11:17:00 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E50912998C for ; Mon, 17 Oct 2016 11:16:57 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pechora8.dc.icann.org (Postfix) with ESMTPS id 6D2D4C09C8 for ; Mon, 17 Oct 2016 18:16:56 +0000 (UTC) Received: by mail-vk0-x22c.google.com with SMTP id q126so133996729vkd.2 for ; Mon, 17 Oct 2016 11:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coactus-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VUnuCiAijfxwD0In+98C8iN+U3QJo9+h/2IQwG/7Xk0=; b=LGTeQIISHy4p2vhO2VQdGq5Dtht9dozRZYR0R6cN+xeiVxaWh1nWfHctYFFly8tuPM t/RgilMzoDh87niTKWgDxxtkDJx/DZMHyZYKnyQGHj0huqFYPqUDMP1/evAZmXRrVjjI 4hNWoRPUDTJmoNRwSeiVkkgfj3vHjNuJg8fOAs3GGLGoJi76sXqJs3bPyXTPoTI+rfCl DNZsApwH1mSWXYZpiZxpQCAOoojF+o6yBvS3GDNTqLt6fUEd55aZE4yveU0ckPN9qz4V Sx8Bec3KK3W8DGEoxmjPxFEhNfmp1n4GE1zb5bzbXIDuvlBqn9ECFxLAmebH/kz6e+S9 OwSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VUnuCiAijfxwD0In+98C8iN+U3QJo9+h/2IQwG/7Xk0=; b=QgJ4SQvDc7zfvnZCrU8q65IpCfI1XrZDIX7vDQ2PeqVgNcO0LbegOEXpzYZBLOIHfX 3bmeDmBmEF8xn4XSI0gnOecGe3KZySRzWP8zfIJDZAkPpvPPLhi4/Ow74juaLrvsuJxN LAI0M4XZ6g2GVrY6hu0EwYyW6hazliUFG5z2hwiXtdQpLO4cqaov0t6JLYyRCN1wSzn1 IrD9o8LHRj5J8q6sAXg1b8L6ItKIOtb5yN3j7soRyCHQmPMrSdHbPMbb4veNaE04mG0A +I4hnKebqmY5UTGlDRD3bx142BJQB9v8P06c3x49vHKi8lWgjDWnV/urtRnXNFuUd2aL LSdg== X-Gm-Message-State: AA6/9RnIQh6vupT4tZsccZJdJIGu0s+qyucSRwkOOMAgjUMpc552wJyB2/OMSk6xJWoPRSa/tWm/sF3y9B6xEw== X-Received: by 10.31.178.198 with SMTP id b189mr18876151vkf.70.1476728215764; Mon, 17 Oct 2016 11:16:55 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.103.138.129 with HTTP; Mon, 17 Oct 2016 11:16:55 -0700 (PDT) X-Originating-IP: [198.84.216.3] In-Reply-To: References: <8CE835AF-B228-4623-BDDE-D4B7DD006A6B@dret.net> <31406b75-16fe-3aed-fa16-ca4ad46f255d@dret.net> <9125c52c-ce66-2bff-0674-d2ce737b0014@dret.net> <696edcc0-ffd2-0edb-b432-78a38481d46e@dret.net> From: Mark Baker Date: Mon, 17 Oct 2016 14:16:55 -0400 X-Google-Sender-Auth: sQGfdDZNY7F5vVcJig9oce08cvU Message-ID: To: Erik Wilde Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: art@ietf.org, media-types@iana.org, geojson@ietf.org Subject: Re: [media-types] [art] moving forward with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 18:17:01 -0000 On Mon, Oct 17, 2016 at 8:12 AM, Erik Wilde wrote: > hello. > > On 2016-09-26 19:20, Mark Baker wrote: >> >> Ah, I hadn't forgotten all about RFC 7464. Yes, registering the suffix >> in that light makes ample sense. Thanks, Erik. > > > https://tools.ietf.org/html/draft-wilde-json-seq-suffix seems to be > reasonable enough that nobody has objected to it. we would like to move > forward with this so that we can use it for a media type that we are working > on in the GeoJSON working group. > > what is the best way to move forward? as requested by > https://tools.ietf.org/html/rfc6838#section-6, i have created a registration > template here: That's a good place to start ;) > > https://tools.ietf.org/html/draft-wilde-json-seq-suffix-00#section-4 > > i am including this registration template literally to help the review > process via media-types@iana.org: > > ---------------------------------------- > > Name: JSON Text Sequence > > +suffix: +json-seq > > References: [3] > > Encoding considerations: See [3] > > Fragment identifier considerations: The syntax and semantics of > fragment identifiers specified for +json-seq SHOULD be as > specified for "application/json-seq". (At publication of this > document, there is no fragment identification syntax defined for > "application/json-seq".) > > The syntax and semantics for fragment identifiers for a > specific "xxx/yyy+json-seq" SHOULD be processed as follows: > > For cases defined in +json-seq, where the fragment > identifier resolves per the +json-seq rules, then process as > specified in +json-seq. > > For cases defined in +json-seq, where the fragment > identifier does not resolve per the +json-seq rules, then > process as specified in "xxx/yyy+json-seq". > > For cases not defined in +json-seq, then process as > specified in "xxx/yyy+json-seq". Is this necessary? I have a couple of concerns about it that would be tricky to explain, but seeing as there currently is no generic syntax, could it just be removed? From nobody Tue Oct 18 07:40:11 2016 Return-Path: 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 76C70126FDC for ; Tue, 18 Oct 2016 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 EMce7aW1oCxc for ; Tue, 18 Oct 2016 07:40:02 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [192.0.33.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A59128874 for ; Tue, 18 Oct 2016 07:40:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pechora1.lax.icann.org (Postfix) with ESMTPS id 334941E0655 for ; Tue, 18 Oct 2016 14:39:32 +0000 (UTC) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9IEd8GT076504 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 18 Oct 2016 09:39:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: media-types@iana.org From: Robert Sparks Message-ID: <323e1c3c-1ee8-ef18-dacc-df0006739c07@nostrum.com> Date: Tue, 18 Oct 2016 09:39:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------522AA8CEE83BCDA9E353D37C" Archived-At: Cc: Alissa Cooper , Russ Housley Subject: [media-types] Review request for application/passport 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 14:40:09 -0000 This is a multi-part message in MIME format. --------------522AA8CEE83BCDA9E353D37C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Please review this request for registering application/passport. See 10.1. Media Type Registration 10.1.1. Media Type Registry Contents Additions Requested This section registers the "application/passport" media type [RFC2046] in the "Media Types" registry in the manner described in [RFC6838], which can be used to indicate that the content is a PASSporT defined JWT and JWS. o Type name: application o Subtype name: passport o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: 8bit; application/passport values outside the US-ASCII range are encoded using percent encoding as described in Section 2.1 of [RFC3986] (some values may be the empty string), each separated from the next by a single period ('.') character. o Security considerations: See the Security Considerations Section of [RFC7515]. o Interoperability considerations: n/a o Published specification: [RFCThis] o Applications that use this media type: STIR and other applications that require identity related assertion o Fragment identifier considerations: n/a o Additional information: Magic number(s): n/a File extension(s): n/a Macintosh file type code(s): n/a o Person & email address to contact for further information: Chris Wendt, chris-ietf@chriswendt.net o Intended usage: COMMON o Restrictions on usage: none o Author: Chris Wendt, chris-ietf@chriswendt.net o Change Controller: IESG o Provisional registration? No --------------522AA8CEE83BCDA9E353D37C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Please review this request for registering application/passport.

See <https://datatracker.ietf.org/doc/draft-ietf-stir-passport/>

10.1.  Media Type Registration

10.1.1.  Media Type Registry Contents Additions Requested

   This section registers the "application/passport" media type
   [RFC2046] in the "Media Types" registry in the manner described in
   [RFC6838], which can be used to indicate that the content is a
   PASSporT defined JWT and JWS.

   o  Type name: application

   o  Subtype name: passport

   o  Required parameters: n/a

   o  Optional parameters: n/a

   o  Encoding considerations: 8bit; application/passport values outside
      the US-ASCII range are encoded using percent encoding as described
      in Section 2.1 of [RFC3986] (some values may be the empty string),
      each separated from the next by a single period ('.') character.

   o  Security considerations: See the Security Considerations
      Section of [RFC7515].

   o  Interoperability considerations: n/a

   o  Published specification: [RFCThis]

   o  Applications that use this media type: STIR and other applications
      that require identity related assertion

   o  Fragment identifier considerations: n/a

   o  Additional information:

      Magic number(s): n/a File extension(s): n/a Macintosh file type
      code(s): n/a

   o  Person & email address to contact for further information: Chris
      Wendt, chris-ietf@chriswendt.net

   o  Intended usage: COMMON

   o  Restrictions on usage: none

   o  Author: Chris Wendt, chris-ietf@chriswendt.net

   o  Change Controller: IESG

   o  Provisional registration?  No
--------------522AA8CEE83BCDA9E353D37C-- From nobody Wed Oct 19 02:50:25 2016 Return-Path: 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 5435F127078 for ; Wed, 19 Oct 2016 02:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 1Rbd0JbhTfeu for ; Wed, 19 Oct 2016 02:50:22 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [IPv6:2620:0:2830:201::1:74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A188412945B for ; Wed, 19 Oct 2016 02:50:22 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by pechora8.dc.icann.org (Postfix) with ESMTP id E7863C0CD6 for ; Wed, 19 Oct 2016 09:50:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1476870601; d=isode.com; s=june2016; i=@isode.com; bh=Wy4R1vyQJmvXlZjVgqB+jtoRLvMDSaXVxkparlpfGpg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=TOuDo6GzlYp2BUWlaSaAewWlFJGGu/l7+YvFCP70IoQPiE3gLI/ZmXaSgunaSanz0YZm8c uuefSjuJIYWvVAezOFWmpwUar26zGSYh5KwHiAEHso4zOMCZbZN4xpMkYIxh1YiaLPMQSP kDeXiogTkGDA6Md0pbcxrboWIqYvngU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 19 Oct 2016 10:50:00 +0100 To: Robert Sparks , media-types@iana.org References: <323e1c3c-1ee8-ef18-dacc-df0006739c07@nostrum.com> From: Alexey Melnikov Message-ID: <134b3e70-38ea-bfe3-c55f-5d96d0c9bb49@isode.com> Date: Wed, 19 Oct 2016 10:49:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <323e1c3c-1ee8-ef18-dacc-df0006739c07@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B2D29308494EF70B136419C7" Archived-At: Cc: Russ Housley , Alissa Cooper Subject: Re: [media-types] Review request for application/passport 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 09:50:25 -0000 This is a multi-part message in MIME format. --------------B2D29308494EF70B136419C7 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Robert, This looks basically fine, a couple of minor things below: On 18/10/2016 15:39, Robert Sparks wrote: > > Please review this request for registering application/passport. > > See > > 10.1. Media Type Registration > > 10.1.1. Media Type Registry Contents Additions Requested > > This section registers the "application/passport" media type > [RFC2046] in the "Media Types" registry in the manner described in > [RFC6838], which can be used to indicate that the content is a > PASSporT defined JWT and JWS. > > o Type name: application > > o Subtype name: passport > > o Required parameters: n/a > > o Optional parameters: n/a > > o Encoding considerations: 8bit; application/passport values outside > the US-ASCII range are encoded using percent encoding as described > in Section 2.1 of [RFC3986] (some values may be the empty string), > each separated from the next by a single period ('.') character. This looks a bit contradictory: if non US-ASCII values are %-encoded, then this will be 7bit? Also, can you have lines longer than 1000 octets here before CRLF? If the answer is yes, then Encoding should be "7bit or Binary" (or "8bit or Binary"). > o Security considerations: See the Security Considerations > Section of [RFC7515]. > > o Interoperability considerations: n/a > > o Published specification: [RFCThis] > > o Applications that use this media type: STIR and other applications > that require identity related assertion > > o Fragment identifier considerations: n/a > > o Additional information: > > Magic number(s): n/a File extension(s): n/a Macintosh file type > code(s): n/a A nit: I personally prefer a file extension to be registered. > o Person & email address to contact for further information: Chris > Wendt,chris-ietf@chriswendt.net > > o Intended usage: COMMON > > o Restrictions on usage: none > > o Author: Chris Wendt,chris-ietf@chriswendt.net > > o Change Controller: IESG > > o Provisional registration? No --------------B2D29308494EF70B136419C7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Hi Robert,

This looks basically fine, a couple of minor things below:


On 18/10/2016 15:39, Robert Sparks wrote:

Please review this request for registering application/passport.

See <https://datatracker.ietf.org/doc/draft-ietf-stir-passport/>

10.1.  Media Type Registration

10.1.1.  Media Type Registry Contents Additions Requested

   This section registers the "application/passport" media type
   [RFC2046] in the "Media Types" registry in the manner described in
   [RFC6838], which can be used to indicate that the content is a
   PASSporT defined JWT and JWS.

   o  Type name: application

   o  Subtype name: passport

   o  Required parameters: n/a

   o  Optional parameters: n/a

   o  Encoding considerations: 8bit; application/passport values outside
      the US-ASCII range are encoded using percent encoding as described
      in Section 2.1 of [RFC3986] (some values may be the empty string),
      each separated from the next by a single period ('.') character.
This looks a bit contradictory: if non US-ASCII values are %-encoded, then this will be 7bit?

Also, can you have lines longer than 1000 octets here before CRLF? If the answer is yes, then Encoding should be "7bit or Binary" (or "8bit or Binary").
   o  Security considerations: See the Security Considerations
      Section of [RFC7515].

   o  Interoperability considerations: n/a

   o  Published specification: [RFCThis]

   o  Applications that use this media type: STIR and other applications
      that require identity related assertion

   o  Fragment identifier considerations: n/a

   o  Additional information:

      Magic number(s): n/a File extension(s): n/a Macintosh file type
      code(s): n/a
A nit: I personally prefer a file extension to be registered. 
   o  Person & email address to contact for further information: Chris
      Wendt, chris-ietf@chriswendt.net

   o  Intended usage: COMMON

   o  Restrictions on usage: none

   o  Author: Chris Wendt, chris-ietf@chriswendt.net

   o  Change Controller: IESG

   o  Provisional registration?  No

--------------B2D29308494EF70B136419C7-- From nobody Wed Oct 19 13:22:19 2016 Return-Path: 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 F380C1294C4 for ; Wed, 19 Oct 2016 13:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coactus-com.20150623.gappssmtp.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 YPJ6tJiTP0E2 for ; Wed, 19 Oct 2016 13:22:15 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [192.0.33.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8AE129579 for ; Wed, 19 Oct 2016 13:22:15 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pechora1.lax.icann.org (Postfix) with ESMTPS id C28BC1E06E9 for ; Wed, 19 Oct 2016 20:22:14 +0000 (UTC) Received: by mail-vk0-x235.google.com with SMTP id 83so42704439vkd.0 for ; Wed, 19 Oct 2016 13:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coactus-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=m7s6AUcHA3OBpAmLbJoWVzQmw+g57XmTKqO71Uw/+9A=; b=EfB8s5qjtv3Oxh5bep76BCvbTHaeO+BVFpH0RN9EoHZSUCPP6UjafhlnSDMMXM99l+ 2ToWdO8XM0GVFONWNc3T4gKueZxHmhuX7U27RR/OXQFjJ78evVHuOPBP9OIaQcaSahwa 1ZOqxwYcCDFpPfO6qKoFmRnN4BO0eQ3olhAZHvj6+nIF0LuQWWFc49CYg51fDsSuRMGo rhTvqmvP/PLGiVUzOIrotArp6KBb0atr/74ZBkTOx88qUpdws6YNpzQJyYNxOoCOTHb7 F/WiEG8HXsqrct07zu6YNnjrp4rwgnciUI82dSPk5sFqiRvtdLeIMTST2nMgzRIzW6lw mmpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=m7s6AUcHA3OBpAmLbJoWVzQmw+g57XmTKqO71Uw/+9A=; b=MglZbdhhCpi1zt1WX5BAruSanPuxsT/hqTL3HDOUtA3haMBb8ZAE544mP6OZevpV4w L8X6wsXrGY816l+i0eAW4aPQ+e9oT566nrt0SvlyRQ/zg00jNzmvliF//81HSo/i/FSd Ecwn0LzTBsnDJx9hKUnuPaerWLdJ28phONmoY3bd4frdCa3IxaCbOG9iSkxo1NO6TfND rrMoL34ALL4pyc+JgcwysAbUi0Ll60KrQfybi6UdOfYYq56HjvxVc3mdzdaEmHY16N4L ESpNHuWmrPsFpVY0K9VWb/V0lTsqd781gtSwyy6VSAcCsHXECwKFqrLXuWW5T5FQqN2M RFeg== X-Gm-Message-State: AA6/9RkKXRm1jkGlLPjNk3p5KMDZK641Bwz0DZlbyF9nifVjTofH8nEJKHCgxXc4X0wu5aOn6gwao5+2p8KvTA== X-Received: by 10.31.224.71 with SMTP id x68mr6251486vkg.63.1476908533994; Wed, 19 Oct 2016 13:22:13 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.103.138.129 with HTTP; Wed, 19 Oct 2016 13:22:13 -0700 (PDT) X-Originating-IP: [199.119.233.251] In-Reply-To: <323e1c3c-1ee8-ef18-dacc-df0006739c07@nostrum.com> References: <323e1c3c-1ee8-ef18-dacc-df0006739c07@nostrum.com> From: Mark Baker Date: Wed, 19 Oct 2016 16:22:13 -0400 X-Google-Sender-Auth: H4-_MA4llDCqnKX7udnY2cl9gxk Message-ID: To: Robert Sparks Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Russ Housley , Alissa Cooper , media-types@iana.org Subject: Re: [media-types] Review request for application/passport 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 20:22:17 -0000 On Tue, Oct 18, 2016 at 10:39 AM, Robert Sparks wrote: > Please review this request for registering application/passport. > > See > > 10.1. Media Type Registration > > 10.1.1. Media Type Registry Contents Additions Requested > > This section registers the "application/passport" media type > [RFC2046] in the "Media Types" registry in the manner described in > [RFC6838], which can be used to indicate that the content is a > PASSporT defined JWT and JWS. > > o Type name: application > > o Subtype name: passport My concern about the name is its broad nature. Is there a more specific name that could be used instead? Also, would a +json suffix be suitable? I see there's a canonical form defined; is that why the suffix wasn't used? > > o Required parameters: n/a > > o Optional parameters: n/a > > o Encoding considerations: 8bit; application/passport values outside > the US-ASCII range are encoded using percent encoding as described > in Section 2.1 of [RFC3986] (some values may be the empty string), > each separated from the next by a single period ('.') character. In addition to Alexey's comments, I'm not quite sure what's going on at the end of that description, and I can't find any percent encoded examples in the draft to help me understand. Mark. From nobody Tue Oct 25 07:16:01 2016 Return-Path: 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 448E212947B for ; Tue, 25 Oct 2016 07:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 LsFXkNCmE0W9 for ; Tue, 25 Oct 2016 07:15:57 -0700 (PDT) Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924731294BF for ; Tue, 25 Oct 2016 07:15:54 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by pechora6.dc.icann.org (Postfix) with ESMTP id 967A91E007A for ; Tue, 25 Oct 2016 14:15:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1477404931; d=isode.com; s=june2016; i=@isode.com; bh=I2RaTuFjUggNJ7KC1csh0wCOMCateNymTu5ofsxHhjc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=fZKhz/BTWQmH79K/7+pYfRTrcjKaC3057zPewuvp+tVX284zFedzpRgNNShsSlloiMTavm AUaV1/mU7FR5kyESML1ewOx4RWzBuOWS011WPHkma+yBjQvaZQ23WLJ35oadJ+s5+6X9Uk CVeAA/uH65RecjqhjaEX+HacZJ4Y3/c=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 25 Oct 2016 15:15:31 +0100 To: Chris Wendt References: <323e1c3c-1ee8-ef18-dacc-df0006739c07@nostrum.com> <134b3e70-38ea-bfe3-c55f-5d96d0c9bb49@isode.com> <2CBD38D0-BC1F-487C-85DF-235435E2D67B@me.com> From: Alexey Melnikov Message-ID: <2f123b52-ed6d-c62c-86f2-9f9498b51619@isode.com> Date: Tue, 25 Oct 2016 15:15:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <2CBD38D0-BC1F-487C-85DF-235435E2D67B@me.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A6A68811CC79005E256ABA90" Archived-At: Cc: Russ Housley , Alissa Cooper , media-types@iana.org, Robert Sparks Subject: Re: [media-types] Review request for application/passport 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 14:15:59 -0000 --------------A6A68811CC79005E256ABA90 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Chris, A few corrections below: On 25/10/2016 14:37, Chris Wendt wrote: > Hi Alexey, > > Yes this is a mistake, I changed the body text to align with the > unicode rules in JWS, but missed changing this in the media type > registration as well. > > New text (including change for +json suggested by Mark) will be: > > 11. IANA Considerations > > 11.1. Media Type Registration > > 11.1.1. Media Type Registry Contents Additions Requested > > This section registers the "application/passport+json" media type > [RFC2046] in the "Media Types" registry in the manner described in > [RFC6838], which can be used to indicate that the content is a > PASSporT used to assert identity related information in JSON format. > > o Type name: application > > o Subtype name: passport passport+json ? > > o Required parameters: n/a > > o Optional parameters: n/a > > o Encoding considerations: 8bit; application/passport+json values are > represented as a JSON object; UTF-8 encoding SHOULD be employed > for the JSON object as defined in [RFC7519] Section 7. I think you should use "binary" as application/json registration. This would be especially needed if some flavour of UTF-16 is used (you are only using SHOULD, not a MUST above). > > o Security considerations: See the Security Considerations > Section of [RFC7515]. > > o Interoperability considerations: n/a > > o Published specification: [RFCThis] > > o Applications that use this media type: STIR and other applications > that require identity related assertion > > o Fragment identifier considerations: n/a > > o Additional information: > > Magic number(s): n/a File extension(s): .json You should register a new file extension. > Macintosh file type > code(s): n/a > > o Person & email address to contact for further information: Chris > Wendt, chris-ietf@chriswendt.net > > o Intended usage: COMMON > > o Restrictions on usage: none > > o Author: Chris Wendt, chris-ietf@chriswendt.net > > > o Change Controller: IESG > > o Provisional registration? No > > >>> Encoding considerations: 8bit; application/passport values outside >>> the US-ASCII range are encoded using percent encoding as described >>> in Section 2.1 of [RFC3986] (some values may be the empty string), >>> each separated from the next by a single period ('.') character. > > > >> On Oct 19, 2016, at 4:49 AM, Alexey Melnikov >> > wrote: >> >> Hi Robert, >> >> This looks basically fine, a couple of minor things below: >> >> >> On 18/10/2016 15:39, Robert Sparks wrote: >>> >>> Please review this request for registering application/passport. >>> >>> See >>> >>> >>> 10.1. Media Type Registration >>> >>> 10.1.1. Media Type Registry Contents Additions Requested >>> >>> This section registers the "application/passport" media type >>> [RFC2046] in the "Media Types" registry in the manner described in >>> [RFC6838], which can be used to indicate that the content is a >>> PASSporT defined JWT and JWS. >>> >>> o Type name: application >>> >>> o Subtype name: passport >>> >>> o Required parameters: n/a >>> >>> o Optional parameters: n/a >>> >>> o Encoding considerations: 8bit; application/passport values outside >>> the US-ASCII range are encoded using percent encoding as described >>> in Section 2.1 of [RFC3986] (some values may be the empty string), >>> each separated from the next by a single period ('.') character. >> This looks a bit contradictory: if non US-ASCII values are %-encoded, >> then this will be 7bit? >> >> Also, can you have lines longer than 1000 octets here before CRLF? If >> the answer is yes, then Encoding should be "7bit or Binary" (or "8bit >> or Binary"). >>> o Security considerations: See the Security Considerations >>> Section of [RFC7515]. >>> >>> o Interoperability considerations: n/a >>> >>> o Published specification: [RFCThis] >>> >>> o Applications that use this media type: STIR and other applications >>> that require identity related assertion >>> >>> o Fragment identifier considerations: n/a >>> >>> o Additional information: >>> >>> Magic number(s): n/a File extension(s): n/a Macintosh file type >>> code(s): n/a >> A nit: I personally prefer a file extension to be registered. >>> o Person & email address to contact for further information: Chris >>> Wendt,chris-ietf@chriswendt.net >>> >>> o Intended usage: COMMON >>> >>> o Restrictions on usage: none >>> >>> o Author: Chris Wendt,chris-ietf@chriswendt.net >>> >>> o Change Controller: IESG >>> >>> o Provisional registration? No >> > --------------A6A68811CC79005E256ABA90 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

Hi Chris,

A few corrections below:


On 25/10/2016 14:37, Chris Wendt wrote:
Hi Alexey,

Yes this is a mistake, I changed the body text to align with the unicode rules in JWS, but missed changing this in the media type registration as well.

New text (including change for +json suggested by Mark) will be:

11. =A0IANA Considerations

11.1. =A0Media Type Registration

11.1.1. =A0Media Type Registry Contents Additions Requested

=A0 =A0This section registers the "application/passport+json" media type
=A0 =A0[RFC2046] in the "Media Types" registry i= n the manner described in
=A0 =A0[RFC6838], which can be used to indicate that the content is a
=A0 =A0PASSporT used to assert identity related information in JSON format.

=A0 =A0o =A0Type name: application

=A0 =A0o =A0Subtype name: passport
passport+json ?

=A0 =A0o =A0Required parameters: n/a

=A0 =A0o =A0Optional parameters: n/a

=A0 =A0o =A0Encoding considerations: 8bit; application/passport+json=A0values are=A0
=A0 =A0 =A0 represented as a JSON object; UTF-8 encoding SHOULD be employed=A0
=A0 =A0 =A0 for the JSON object as defined in [RFC7519] Section 7.
I think you should use "binary" as application/json registration. This would be especially needed if some flavour of UTF-16 is used (you are only using SHOULD, not a MUST above).


=A0 =A0o =A0Security considerations: See the Security Considerations
=A0 =A0 =A0 Section of [RFC7515].

=A0 =A0o =A0Interoperability considerations: n/a=

=A0 =A0o =A0Published specification: [RFCThis]

=A0 =A0o =A0Applications that use this media typ= e: STIR and other applications
=A0 =A0 =A0 that require identity related assert= ion

=A0 =A0o =A0Fragment identifier considerations: = n/a

=A0 =A0o =A0Additional information:

=A0 =A0 =A0 Magic number(s): n/a File extension(= s): .json
You should register a new file extension.
Macintosh file type
=A0 =A0 =A0 code(s): n/a

=A0 =A0o =A0Person & email address to contac= t for further information: Chris
=A0 =A0 =A0 Wendt, chris-i= etf@chriswendt.net

=A0 =A0o =A0Intended usage: COMMON

=A0 =A0o =A0Restrictions on usage: none

=A0 =A0o =A0Author: Chris Wendt, chris-i= etf@chriswendt.net

=A0 =A0o =A0Change Controller: IESG

=A0 =A0o =A0Provisional registration? =A0No 


Encoding considerations: 8bit; application=
/passport values outside
      the US-ASCII range are encoded using percent encoding as described
      in Section 2.1 of [RFC3986] (some values may be the empty string),
      each separated from the next by a single period ('.') character.


=20

On Oct 19, 2016, at 4:49 AM, Alexey Melnikov <ale= xey.melnikov@isode.com> wrote:

Hi Robert,

This looks basically fine, a couple of minor things below:


On 18/10/2016 15:39, Robert Sparks wrote:

Please review this request for registering application/passport.

See <https://datatracker.ietf.org/doc/draft-ietf-stir-passp= ort/>


10.1.  Media Type =
Registration

10.1.1.  Media Type Registry Contents Additions Requeste=
d

   This section registers the "application/passport" media type
   [RFC2046] in the "Media Types" registry in the manner described in
   [RFC6838], which can be used to indicate that the content is a
   PASSporT defined JWT and JWS.

   o  Type name: application

   o  Subtype name: passport

   o  Required parameters: n/a

   o  Optional parameters: n/a

   o  Encoding considerations: 8bit; application/passport values outside
      the US-ASCII range are encoded using percent encoding as described
      in Section 2.1 of [RFC3986] (some values may be the empty string),
      each separated from the next by a single period ('.') character.
This looks a bit contradictory: if non US-ASCII values are %-encoded, then this will be 7bit?

Also, can you have lines longer than 1000 octets here before CRLF? If the answer is yes, then Encoding should be "7bit or Binary" (or "8bit or Binary").
   o  Security considerations: See the=
 Security Considerations
      Section of [RFC7515].

   o  Interoperability considerations: n/a

   o  Published specification: [RFCThis]

   o  Applications that use this media type: STIR and other applications
      that require identity related assertion

   o  Fragment identifier considerations: n/a

   o  Additional information:

      Magic number(s): n/a File extension(s): n/a Macintosh file type
      code(s): n/a
A nit: I personally prefer a file extension to be registered. 
   o  Person & email address to co=
ntact for further information: Chris
      Wendt, chris-ietf@chriswendt.net

   o  Intended usage: COMMON

   o  Restrictions on usage: none

   o  Author: Chris Wendt, chris-ietf@chriswend=
t.net

   o  Change Controller: IESG

   o  Provisional registration?  No



--------------A6A68811CC79005E256ABA90-- From nobody Tue Oct 25 15:35:29 2016 Return-Path: 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 12E9E129861 for ; Tue, 25 Oct 2016 15:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 Krb7PotzN6T6 for ; Tue, 25 Oct 2016 15:35:26 -0700 (PDT) Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE97C12942F for ; Tue, 25 Oct 2016 15:35:24 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pechora6.dc.icann.org (Postfix) with ESMTPS id C170D1E007A for ; Tue, 25 Oct 2016 22:35:23 +0000 (UTC) Received: by mail-qt0-x231.google.com with SMTP id 23so14804106qtp.5 for ; Tue, 25 Oct 2016 15:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TzJtF9hb06oLRqDjBtPeYkhWYJG/bKXnssbWN6Zhwdk=; b=aEa3SENQLYMl/bOL4+7AkVXyJGxHWYvIe7iUcRI0hlPMfZ6nJ5onA5ev/LkgEH7UcN 7sdwbPkdLqgiMPnCQnANl9zyre+IXgcny1YGg+dR9egt/LUZDTV3cwBpSNaysX8T3tPz aMxdREWj7IU9RYjzrE1ll9Qg5Z5IHTu/7A+qpLxQNaZoS1yFmwhAqfviwG6/5wjByNVE 3z1zW9UI2W+bRy//HbWcRCM8K7F+OodsH+tZK6DEiZwtWZXPXMZBFvbVvka1C0M/v7ay 9eXICbdp4O6UKUkUds5yo1y0rIh12S87w6yP8te4HSPEpf9c2Au75B2eI+CO+QOhk467 MU6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TzJtF9hb06oLRqDjBtPeYkhWYJG/bKXnssbWN6Zhwdk=; b=SQvieMYVuazZ/OJEB8yUFNfZKKLYWdONO00Kuj3zuI8MelXqlFGxNsxMtb5LAP+3jm 4cxdsguC4k9V4p7NTSTpWODdoga0KsHgxaWoLz/Dzba0hM3qWZWMRVt7LNTUIG2+3SUR S1brCZtOOJrYPdx0Nz6y+GkihPysk5mgi6Hd9Z8UkP8b0JdNCbHizaK0/Ccserp+iS4B IUeuZXo4FWKoZrGQL9EwySuahNGqtTqpELTtt7vKX/WtHF7wMtGviWLgvhbgpffTTu4+ oCz9lCm1p7GMqb4B8cdrGYPsdivqiMUeNl1sQ5OGrR/MC/AwI+fPP/G8kzLq+0KRg8CX Farw== X-Gm-Message-State: ABUngvczjoTcz3Sbvnp1bSMCN2WiBswjHTTektbH0HO3BBI9QZ3h0SuKai3cHPA5jpuwVA== X-Received: by 10.237.41.39 with SMTP id s36mr22007216qtd.156.1477434903646; Tue, 25 Oct 2016 15:35:03 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:5d7b:5ed3:493d:4819? ([2601:41:c101:9364:5d7b:5ed3:493d:4819]) by smtp.gmail.com with ESMTPSA id c189sm12223367qkg.21.2016.10.25.15.35.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Oct 2016 15:35:03 -0700 (PDT) From: Chris Wendt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B9B7C5FE-86ED-4BBE-99EC-DFA52B7E94F2" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Tue, 25 Oct 2016 18:35:01 -0400 In-Reply-To: <2f123b52-ed6d-c62c-86f2-9f9498b51619@isode.com> To: Alexey Melnikov References: <323e1c3c-1ee8-ef18-dacc-df0006739c07@nostrum.com> <134b3e70-38ea-bfe3-c55f-5d96d0c9bb49@isode.com> <2CBD38D0-BC1F-487C-85DF-235435E2D67B@me.com> <2f123b52-ed6d-c62c-86f2-9f9498b51619@isode.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Alissa Cooper , Russ Housley , media-types@iana.org, Robert Sparks Subject: Re: [media-types] Review request for application/passport 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 22:35:28 -0000 --Apple-Mail=_B9B7C5FE-86ED-4BBE-99EC-DFA52B7E94F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alexey, Inline >>=20 >>=20 >> o Subtype name: passport > passport+json ? Originally this indeed was a mistake, but after some discussion and = specifically Jim Schaad pointed out that PASSporT after construction is = not a JSON object, but rather a bunch of Base64 encoded characters with = =E2=80=98.'. So, based on this I think we should stick with just = =E2=80=9Cpassport" >>=20 >> o Required parameters: n/a >>=20 >> o Optional parameters: n/a >>=20 >> o Encoding considerations: 8bit; application/passport+json values = are=20 >> represented as a JSON object; UTF-8 encoding SHOULD be employed=20= >> for the JSON object as defined in [RFC7159] Section 7. > I think you should use "binary" as application/json registration. This = would be especially needed if some flavour of UTF-16 is used (you are = only using SHOULD, not a MUST above). Based on conclusion above about only using Base64 encoded ASCII/UTF-8 = and some further discussion and looking at JWT/JWS, we are going to = change this to=20 o Encoding considerations: 8bit; PASSporT values are encoded as a = series of base64url-encoded ASCII values (some of which may be the empty string) separated by period ('.') characters. The only thing here we could consider is setting 7bit, because the = resulting Base64 and =E2=80=98.=E2=80=99 is really just ASCII = characters, but didn=E2=80=99t want to conflict with what is in RFC7519 = JWT. o Type name: application o Subtype name: jwt o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: 8bit; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters. >=20 >>=20 >> o Security considerations: See the Security Considerations >> Section of [RFC7515]. >>=20 >> o Interoperability considerations: n/a >>=20 >> o Published specification: [RFCThis] >>=20 >> o Applications that use this media type: STIR and other = applications >> that require identity related assertion >>=20 >> o Fragment identifier considerations: n/a >>=20 >> o Additional information: >>=20 >> Magic number(s): n/a File extension(s): .json > You should register a new file extension. So, i=E2=80=99m ok just adding .json as a possible use of storing = passport object, but in reality these tokens are only constructed during = the life of a call in the real-time signaling path, so we really would = NEVER create any file for this, so now I=E2=80=99m thinking we just go = back to n/a, if that=E2=80=99s acceptable. Here is the resulting proposed request: * Type name: application * Subtype name: passport * Required parameters: n/a * Optional parameters: n/a * Encoding considerations: 8bit; application/passport values are encoded = as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters.. * Security considerations: See the Security Considerations Section of = {{RFC7515}}. * Interoperability considerations: n/a * Published specification: [RFCThis] * Applications that use this media type: STIR and other applications = that require identity related assertion * Fragment identifier considerations: n/a * Additional information: Magic number(s): n/a File extension(s): n/a Macintosh file type code(s): n/a * Person & email address to contact for further information: Chris = Wendt, chris-ietf@chriswendt.net * Intended usage: COMMON * Restrictions on usage: none * Author: Chris Wendt, chris-ietf@chriswendt.net * Change Controller: IESG * Provisional registration? No --Apple-Mail=_B9B7C5FE-86ED-4BBE-99EC-DFA52B7E94F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Alexey,

Inline



   o  Subtype name: = passport
passport+json ?

Originally this indeed was a mistake, but after = some discussion and specifically Jim Schaad pointed out that PASSporT = after construction is not a JSON object, but rather a bunch of Base64 = encoded characters with =E2=80=98.'.  So, based on this I think we = should stick with just =E2=80=9Cpassport"


   o  Required parameters: = n/a

   o  Optional parameters: = n/a

   o  Encoding = considerations: 8bit; application/passport+json values are 
      represented as a JSON = object; UTF-8 encoding SHOULD be employed 
      for the JSON object as = defined in [RFC7159] Section 7.
I think you should use "binary" as application/json registration. This would be especially needed if some flavour of UTF-16 is used (you are only using SHOULD, not a MUST above).

Based = on conclusion above about only using Base64 encoded ASCII/UTF-8 and some = further discussion and looking at JWT/JWS, we are going to change this = to 

 o Encoding = considerations: 8bit; PASSporT values are encoded as a series
      of base64url-encoded ASCII values (some = of which may be the empty
      = string) separated by period ('.') characters.

The only thing here we could consider = is setting 7bit, because the resulting Base64 and =E2=80=98.=E2=80=99 is = really just ASCII characters, but didn=E2=80=99t want to conflict with = what is in RFC7519 JWT.
   o  Type name: application
   o  Subtype name: jwt
   o  Required parameters: n/a
   o  Optional parameters: n/a
   o  Encoding considerations: 8bit; JWT values are encoded as a series
      of base64url-encoded values (some of which may be the empty
      string) separated by period ('.') characters.




   o  Security = considerations: See the Security Considerations
      Section of = [RFC7515].

   o  Interoperability = considerations: n/a

   o  Published = specification: [RFCThis]

   o  Applications that use = this media type: STIR and other applications
      that require identity = related assertion

   o  Fragment identifier = considerations: n/a

   o  Additional = information:

      Magic number(s): n/a = File extension(s): .json
You should register a new file extension.

So, = i=E2=80=99m ok just adding .json as a possible use of storing passport = object, but in reality these tokens are only constructed during the life = of a call in the real-time signaling path, so we really would NEVER = create any file for this, so now I=E2=80=99m thinking we just go back to = n/a, if that=E2=80=99s acceptable.


Here is the resulting proposed = request:

* Type name: = application
* Subtype name: passport
* Required = parameters: n/a
* Optional parameters: n/a
* = Encoding considerations: 8bit; application/passport values are encoded = as a series
      of = base64url-encoded values (some of which may be the empty
  =     string) separated by period ('.') characters..
* = Security considerations: See the Security Considerations Section of = {{RFC7515}}.
* Interoperability considerations: = n/a
* Published specification: [RFCThis]
* = Applications that use this media type: STIR and other applications that = require identity related assertion
* Fragment identifier = considerations: n/a
* Additional information:

     Magic number(s): = n/a
     File extension(s): = n/a
     Macintosh file type code(s): = n/a

* Person & email address to = contact for further information: Chris Wendt, chris-ietf@chriswendt.net
* Intended usage: = COMMON
* Restrictions on usage: none
* Author: Chris = Wendt, chris-ietf@chriswendt.net
* Change Controller: = IESG
* Provisional registration?  No


= --Apple-Mail=_B9B7C5FE-86ED-4BBE-99EC-DFA52B7E94F2-- From nobody Mon Oct 31 14:07:53 2016 Return-Path: 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 712BC129AD5 for ; Mon, 31 Oct 2016 14:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 BoTIJStZLQ_n for ; Mon, 31 Oct 2016 14:07:51 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:201::1:72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD37129B22 for ; Mon, 31 Oct 2016 14:07:43 -0700 (PDT) Received: from smtp97.iad3a.emailsrvr.com (smtp97.iad3a.emailsrvr.com [173.203.187.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora2.lax.icann.org (Postfix) with ESMTPS id 7E3FE1E0C6D for ; Mon, 31 Oct 2016 21:07:43 +0000 (UTC) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 553AB5977; Mon, 31 Oct 2016 17:07:23 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 113505AFF; Mon, 31 Oct 2016 17:07:22 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.7); Mon, 31 Oct 2016 17:07:23 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Mon, 31 Oct 2016 15:07:22 -0600 Message-Id: To: media-types@iana.org X-Mailer: Apple Mail (2.3226) Archived-At: Subject: [media-types] Request review for application/senml+exi and application/sensml+exi 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:07:52 -0000 In the registration below, RFC-AAAA would point at an RFC based on = draft-ietf-core-senml-04 Type name: application Subtype name: senml+exi and sensml+exi Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using [W3C.REC-exi-20140211]. See RFC-AAAA for details. Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information. This format does not provide any security and instead relies on the transport protocol that carries it to provide security. Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. Interoperability considerations: Applications should ignore any tags or attributes that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" attribute in the senml tag can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the XML. Further information on using schemas to guide the EXI can be found in RFC-AAAA. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems that report e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems. Additional information: Magic number(s): none File extension(s): senmle and sensmle Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG [W3C.REC-exi-20140211] Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, "Efficient XML Interchange (EXI) Format 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC- exi-20140211, February 2014, . =20 From nobody Mon Oct 31 14:07:57 2016 Return-Path: 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 98D71129B1A for ; Mon, 31 Oct 2016 14:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 ENnZHIIeZHGs for ; Mon, 31 Oct 2016 14:07:51 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:201::1:72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD749129B24 for ; Mon, 31 Oct 2016 14:07:43 -0700 (PDT) Received: from smtp97.iad3a.emailsrvr.com (smtp97.iad3a.emailsrvr.com [173.203.187.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora2.lax.icann.org (Postfix) with ESMTPS id 7EFA71E0D21 for ; Mon, 31 Oct 2016 21:07:43 +0000 (UTC) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7F5015BB0; Mon, 31 Oct 2016 17:07:21 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 3D7595D63; Mon, 31 Oct 2016 17:07:21 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.7); Mon, 31 Oct 2016 17:07:21 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Mon, 31 Oct 2016 15:07:20 -0600 Message-Id: To: media-types@iana.org X-Mailer: Apple Mail (2.3226) Archived-At: Subject: [media-types] Request even more review for application/senml+xml and application/sensml+xml 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:07:52 -0000 In the registration below, RFC-AAAA would point at an RFC based on = draft-ietf-core-senml-04 Type name: application Subtype name: senml+xml and sensml+xml Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using [W3C.REC-xml-20081126]. See RFC-AAAA for details. Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information. This format does not provide any security and instead relies on the transport protocol that carries it to provide security. Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. Interoperability considerations: Applications should ignore any tags or attributes that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" attribute in the senml tag can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the XML. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems that report e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems. Additional information: Magic number(s): none File extension(s): senmlx and sensmlx Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, . From nobody Mon Oct 31 14:08:23 2016 Return-Path: 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 CF3A2129B1A for ; Mon, 31 Oct 2016 14:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 4FtRBLmjwwf3 for ; Mon, 31 Oct 2016 14:08:10 -0700 (PDT) Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E14129B1D for ; Mon, 31 Oct 2016 14:08:04 -0700 (PDT) Received: from smtp97.iad3a.emailsrvr.com (smtp97.iad3a.emailsrvr.com [173.203.187.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora6.dc.icann.org (Postfix) with ESMTPS id 4D9881E036F for ; Mon, 31 Oct 2016 21:08:03 +0000 (UTC) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1C6455D68; Mon, 31 Oct 2016 17:07:26 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id CE5105D66; Mon, 31 Oct 2016 17:07:25 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.7); Mon, 31 Oct 2016 17:07:26 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Mon, 31 Oct 2016 15:07:25 -0600 Message-Id: <98C90DD9-9153-4FFC-A93B-F2513D70E098@iii.ca> To: media-types@iana.org X-Mailer: Apple Mail (2.3226) Archived-At: Subject: [media-types] Request review for application/senml+json and application/sensml+json 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:08:18 -0000 In the registration below, RFC-AAAA would point at an RFC based on = draft-ietf-core-senml-04 Type name: application Subtype name: senml+json and sensml+json Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using a subset of the encoding allowed in [RFC7159]. See RFC-AAAA for details. This simplifies implementation of very simple system and does not impose any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information. This format does not provide any security and instead relies on the transport protocol that carries it to provide security. Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. Interoperability considerations: Applications should ignore any JSON key value pairs that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the JSON object. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems that report e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems. Additional information: Magic number(s): none File extension(s): senml and sensml Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . From nobody Mon Oct 31 14:08:30 2016 Return-Path: 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 AFC0F129558 for ; Mon, 31 Oct 2016 14:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 rNXUc47Njxde for ; Mon, 31 Oct 2016 14:08:17 -0700 (PDT) Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B921299A5 for ; Mon, 31 Oct 2016 14:08:04 -0700 (PDT) Received: from smtp97.iad3a.emailsrvr.com (smtp97.iad3a.emailsrvr.com [173.203.187.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora6.dc.icann.org (Postfix) with ESMTPS id 4BD631E01B8 for ; Mon, 31 Oct 2016 21:08:03 +0000 (UTC) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 278775D2F; Mon, 31 Oct 2016 17:07:28 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id DB4365D90; Mon, 31 Oct 2016 17:07:27 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.7); Mon, 31 Oct 2016 17:07:28 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Mon, 31 Oct 2016 15:07:27 -0600 Message-Id: <25A0104D-507E-41E3-AFEC-0C7650C41741@iii.ca> To: media-types@iana.org X-Mailer: Apple Mail (2.3226) Archived-At: Subject: [media-types] Request review for application/senml+cbor and application/sensml+cbor 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:08:18 -0000 In the registration below, RFC-AAAA would point at an RFC based on = draft-ietf-core-senml-04 Type name: application Subtype name: senml+cbor and sensml+cbor Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using [RFC7049]. See RFC-AAAA for details. Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information. This format does not provide any security and instead relies on the transport protocol that carries it to provide security. Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. Interoperability considerations: Applications should ignore any key value pairs that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the CBOR object. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems that report e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems. Additional information: Magic number(s): none File extension(s): senmlc and sensmlc Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, .