Subject: [core] Adam Roach's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT)

From: Adam Roach <[email-masked]>
Date: Thu, 19 Apr 2018 00:14:13 -0700

Adam Roach has entered the following ballot position for
draft-ietf-core-senml-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to everyone who contributed to this document.

---------------------------------------------------------------------------

§9 defines a URI fragment identification scheme that is intended to apply to
senml+xml / sensml+xml. Since this uses the "+xml" structured syntax suffix, it
has to comply with the fragment identifier considerations associated with that
suffix. See:

https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

In particular, +xml has requirements around citing section 5 of RFC 7303
(which this document doesn't), as well as requiring support for element()
fragments; e.g.:

  coap://example.com/temp#element(/1/3)

must be allowed as an alias for

  coap://example.com/temp#rec=3

If you want to restrict other aspects of XPointerFramework fragment identifiers,
I believe you'll have to say so explicitly.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share Benjamin's concerns about the ambiguity of time handling, and Ben's
concerns about the security implications of writing to devices.

I also have concerns about the notion of "now" and relative times with the
streaming formats: is it relative to the time the stream was opened? Or
relative to the time the record was received? Given that the document highlights
time precisions down to the sub-microsecond level, and given that the record
sizes are likely to be much smaller than the TCP maximum segment size, this
presumably needs to take into consideration possible buffering effects due to
Nagle's algorithm.

---------------------------------------------------------------------------

§4.3:

>    |    Data Value | vd    |          8 | String (*) | string (*) |

I find nowhere in the document that explains what these "(*)" notations mean.

---------------------------------------------------------------------------

§8:

> 8.  EXI Representation (application/senml-exi)

All the other MIME types here use the structured syntax format, which makes
this one stick out as unnecessarily different. Given that the barrier for
registering +exi as a suffix is "expert review," and the only real requirement
that expert is going to check is a reference suitable for normatively citing
(which EXI is by virtue of its appearance in the "Normative
References" section of this document), it seems that the correct (and easy)
thing to do here is simply go ahead and register "+exi".

As an example: we just did this for +gzip; see the RFC Editor Note at
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/writeup/

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Apr 2018 13:43:07 +0100

Hi Adam,
Reply to your DISCUSS point only:

> https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

Hmm, I forgot about that!

> I believe you'll have to say so explicitly.

I don't think there is a need to deviate from generic +xml fragment handling.

I suggest that the Section 9 of this draft:

9.  Fragment Identification Methods

is updated to reference Section 5 of [RFC7303], plus your example is added. Then the media type registrations don't need to be updated, as they already reference the fragment handling in Section 9. Does this work for you?

Best Regards,
Alexey

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Apr 2018 08:02:15 -0500

This works for me as well, as long as the WG doesn’t object. 

/a

> On Apr 19, 2018, at 07:43, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Adam,

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Apr 2018 16:56:42 +0200

Hi Alexey,

> On Apr 19, 2018, at 14:43, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Adam,
> I don’t think there is a need to deviate from generic +xml fragment handling.

Klaus pointed out that this is counterproductive in a content-negotiation setting.

If I have

>>  coap://example.com/temp#rec=3
or
>>  coap://example.com/temp#element(/1/3)

The server is not going to see the fragment identifier, so it doesn’t know that, in the first case, all SenML variants could be handled by the client, and in the second case, only XML should be sent.

So we really want the fragment identifiers for all SenML variants to be the same.

RFC 7303 says:

  If [XPointerFramework] and [XPointerElement] are inappropriate for
  some XML-based media type, it SHOULD NOT follow the naming convention
  ‘+xml’.

Maybe choosing “-xml” is actually the (radical) answer (which also would reestablish symmetry between -xml and -exi).

(We are still discussing whether this observation is also disqualifying +json and +cbor.)

Grüße, Carsten