Subject: [core] New "application/coap-group+json" Internet Media Type for Group Communication

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 7 May 2013 14:55:23 -0400

Hi Carsten/Matthias/Zach,

Esko and I have taken a stab at defining the new
"application/coap-group+json" Internet Media Type for Group
Communication in the updated Group Communications draft:

http://tools.ietf.org/html/draft-ietf-core-groupcomm-07#section-7

Can you please review and tell us if you agree with this approach?

Best Regards,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kovatsch Matthias
Sent: Tuesday, April 23, 2013 7:55 AM
To: Dijk, Esko
Cc: [email-masked]
Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt

Hmm, that is a good point. The problem here lies more in the number
registry for the Content-Format, I suppose.
Maybe we should have something similar to option numbers, so that
specific bits indicate a "+json" or "+xml"?

In general, it is the point, though, that the media types must be
pre-shared. A generic client would probably be like a Web browser that
has plugins for new types or at least can make a lookup in the registry.

Ciao
Matthias

> Suppose we define 'application/coap-group+json' for that, the side 
> effect is that a client not knowing this specific content-format can't

> deduce that it is in fact JSON format. (E.g. the client could 
> integrate a generic-JSON-viewer-plus- editor that shows the 
> information to a user. In this case it won't invoke the JSON-viewer
anymore because the content is not recognized as being JSON).
> So in a way, we also lose a bit of functionality/generality by this
solution.

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 May 2013 00:16:17 +0400

hi akbar,

i'm in St. Petersburg right now, but will look at it when i'm back next week,

Sent from my iPad

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 8 May 2013 11:38:01 +0000

Additional note: the syntax of the current media type uses standard IPv6 address notation in the values of the "ip" fields.
One improvement could be to replace this with an easier to parse representation, for example a 16-byte fixed length sequence in hexadecimal, i.e. 32 characters always. That would avoid the need for a fully functional IPv6 address notation parser in constrained nodes.

Esko

-----Original Message-----
From: Rahman, Akbar [mailto:[email-masked]]
Sent: Tuesday, May 07, 2013 20:55
To: Carsten Bormann; Kovatsch Matthias; Zach Shelby
Cc: [email-masked]; Dijk, Esko
Subject: New "application/coap-group+json" Internet Media Type for Group Communication

Esko and I have taken a stab at defining the new "application/coap-group+json" Internet Media Type for Group Communication in the updated Group Communications draft:

Best Regards,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kovatsch Matthias
Sent: Tuesday, April 23, 2013 7:55 AM
To: Dijk, Esko
Cc: [email-masked]
Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt

Hmm, that is a good point. The problem here lies more in the number registry for the Content-Format, I suppose.
Maybe we should have something similar to option numbers, so that specific bits indicate a "+json" or "+xml"?

In general, it is the point, though, that the media types must be pre-shared. A generic client would probably be like a Web browser that has plugins for new types or at least can make a lookup in the registry.

Ciao
Matthias

solution.

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 12 May 2013 13:31:47 +0000

Dear Akbar and Esko

This looks like a good direction to me. Maybe we can make it more explicit that the media type defines the processing rules, not the resource type. I have a proposal below. 

Another question that arose: Why must group affiliation be configured with single JSON group objects in multiple POSTs? Could we not just add several at once with one POST? (fragmentation aside; maybe as an implementation note...)

What is actually the status about "+json" suffixes in media types? I saw that it was kind of refused a while ago, so maybe it is sufficient to register "application/coap-group"?

Proposed draft texts for 3.6:
---8<---
[...]

CoAP endpoints implementing this optional mechanism MUST support the
"Group Configuration" Internet Media Type (application/coap-group+json).
A resource offering this representation can be annotated for direct
discovery using the resource type (rt) [RFC6690] "core.gp" where "gp" is
shorthand for "group". An authorized controller uses this media type to
query/manage group membership of a CoAP server as defined in the following.

The "Group Configuration" has a JSON-based content format. A (unicast)
GET on a resource accepting this format returns a JSON array of group
objects, each group object formatted as shown below:

[...]

A (unicast) POST with a "Group Configuration" media type as payload
adds the CoAP endpoint to the defined group(s). For this, it adds the
specified IP multicast addresses to its network interface configuration.
This also updates the resource by adding the specified group object(s)
to the existing ones:

[...]

A (unicast) PUT with a "Group Configuration" media type as payload
will replace all current group memberships with the new ones defined
in the PUT request.  After a change effected on the resource,
the endpoint MUST effect registration/de-registration from the
corresponding IP multicast groups as soon as possible.

A (unicast) DELETE will delete all group memberships and the endpoint
MUST effect de-registration from corresponding IP multicast groups as
soon as possible.
	
[...]
--->8---

Ciao
Matthias

> From: Dijk, Esko [mailto:[email-masked]]
> Sent: Wednesday, May 08, 2013 13:38
> To: Rahman, Akbar; Carsten Bormann; Kovatsch Matthias; Zach Shelby
> Cc: [email-masked]
> Subject: RE: New "application/coap-group+json" Internet Media Type for
> Group Communication
> 
> Additional note: the syntax of the current media type uses standard IPv6
> address notation in the values of the "ip" fields.
> One improvement could be to replace this with an easier to parse
> representation, for example a 16-byte fixed length sequence in hexadecimal,
> i.e. 32 characters always. That would avoid the need for a fully functional IPv6
> address notation parser in constrained nodes.
> 
> Esko
> 
> Esko and I have taken a stab at defining the new "application/coap-
> group+json" Internet Media Type for Group Communication in the updated
> Group Communications draft:
> 
> 
> In general, it is the point, though, that the media types must be pre-shared.
> A generic client would probably be like a Web browser that has plugins for
> new types or at least can make a lookup in the registry.
> 
> Ciao
> Matthias
> 
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby notified
> that any use, forwarding, dissemination, or reproduction of this message is
> strictly prohibited and may be unlawful. If you are not the intended recipient,
> please contact the sender by return e-mail and destroy all copies of the
> original message.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 13 May 2013 16:35:13 -0400

Hi Matthias,

Thank you for your detailed review and helpful suggestions.  Some
initial feedback is as follows:

---- Snip-1 -------

What is actually the status about "+json" suffixes in media types? I saw
that it was kind of refused a while ago, so maybe it is sufficient to
register "application/coap-group"?

RESPONSE - If you look in
http://www.iana.org/assignments/media-types/application you will see
that there are some successfully registered "...+json" types.  However,
I am personally, open to either approach.  Hopefully, Carsten can also
give us some guidance on what is the best approach for this topic.

---- End of Snip-1 -------

AND

---- Snip-2 -------

RESPONSE - Very nice.  I will incorporate this into the next revision of
the I-D.

---- End of Snip-2 -------

Best Regards,

Akbar

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]] 
Sent: Sunday, May 12, 2013 9:32 AM
To: Dijk, Esko; Rahman, Akbar; Carsten Bormann; Zach Shelby
Cc: [email-masked]
Subject: RE: New "application/coap-group+json" Internet Media Type for
Group Communication

Dear Akbar and Esko

This looks like a good direction to me. Maybe we can make it more
explicit that the media type defines the processing rules, not the
resource type. I have a proposal below. 

Another question that arose: Why must group affiliation be configured
with single JSON group objects in multiple POSTs? Could we not just add
several at once with one POST? (fragmentation aside; maybe as an
implementation note...)

What is actually the status about "+json" suffixes in media types? I saw
that it was kind of refused a while ago, so maybe it is sufficient to
register "application/coap-group"?

query/manage group membership of a CoAP server as defined in the
following.

[...]

A (unicast) POST with a "Group Configuration" media type as payload adds
the CoAP endpoint to the defined group(s). For this, it adds the
specified IP multicast addresses to its network interface configuration.
This also updates the resource by adding the specified group object(s)
to the existing ones:

[...]

A (unicast) PUT with a "Group Configuration" media type as payload will
replace all current group memberships with the new ones defined in the
PUT request.  After a change effected on the resource, the endpoint MUST
effect registration/de-registration from the corresponding IP multicast
groups as soon as possible.

[...]
--->8---

Ciao
Matthias

> Group Communication
> 
> Additional note: the syntax of the current media type uses standard 
> IPv6 address notation in the values of the "ip" fields.
> representation, for example a 16-byte fixed length sequence in 
> hexadecimal, i.e. 32 characters always. That would avoid the need for 
> a fully functional IPv6 address notation parser in constrained nodes.
> 
> Esko
> 
pre-shared.
> A generic client would probably be like a Web browser that has plugins

> for new types or at least can make a lookup in the registry.
> 
> Ciao
> Matthias
> 
> The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended solely

> for the addressee(s). If you are not the intended recipient, you are 
> hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original
message.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 18 May 2013 17:48:38 +0200

>register "application/coap-group"?

The `+json` suffix is defined and registered in RFC 6839, and it makes a
lot of sense to use it for JSON-based formats, as it makes it easy for
applications to recognise such entities as JSON, e.g. pretty printers in
network analysis tools.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 20 May 2013 14:05:35 -0400

Thanks for the good reference, Bjorn.

-----Original Message-----
From: Bjoern Hoehrmann [mailto:[email-masked]] 
Sent: Saturday, May 18, 2013 11:49 AM
To: Kovatsch Matthias
Cc: Dijk, Esko; Rahman, Akbar; Carsten Bormann; Zach Shelby; [email-masked]
Subject: Re: [core] New "application/coap-group+json" Internet Media Type for Group Communication

* Kovatsch  Matthias wrote:
>What is actually the status about "+json" suffixes in media types? I 
>saw that it was kind of refused a while ago, so maybe it is sufficient 
>to register "application/coap-group"?

The `+json` suffix is defined and registered in RFC 6839, and it makes a lot of sense to use it for JSON-based formats, as it makes it easy for applications to recognise such entities as JSON, e.g. pretty printers in network analysis tools.
--
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/