Hi Alexey,
This commit https://github.com/SanKumar2015/EST-coaps/commit/77d65f0eb7a28282f363e5e48cd0d28970f9366e should address your feedback. The full discussion is in https://github.com/SanKumar2015/EST-coaps/issues/155 Let us know if it does not make sense. Rgs, Panos From: Ace <ace-boun...@ietf.org> On Behalf Of Alexey Melnikov Sent: Monday, December 23, 2019 9:42 AM To: consulta...@vanderstok.org; Carsten Bormann <c...@tzi.org> Cc: ace-cha...@ietf.org; Jim Schaad <i...@augustcellars.com>; Benjamin Kaduk <ka...@mit.edu>; Ace Wg <ace@ietf.org>; The IESG <i...@ietf.org>; draft-ietf-ace-coap-...@ietf.org; Klaus Hartke <har...@projectcool.de> Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) Hi Peter, On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok wrote: HI all, We had this discussion about this specific text several times. I like to keep at least some text for the following reason: Implementers, new to coap without a photographic memory of RFC7252 text, are surprised by the absence of uri host in the examples, and tend to assume an error. The curent text does not look like a "normative rephrasing" to me. Nevertheless, is the suggestion below acceptable to everyone? OLD The Uri-Host and Uri-Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. NEW Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. Other suggestions are welcome. Your suggested text is much better. Thank you, Alexey Peter Carsten Bormann schreef op 2019-12-20 18:16: On Dec 20, 2019, at 17:34, Klaus Hartke <har...@projectcool.de <mailto:har...@projectcool.de> > wrote: I would prefer if draft-ietf-ace-coap-est didn't say anything here, since the Uri-Host and Uri-Port options and whether they should be omitted or not is entirely specified by CoAP [RFC7252].* Klaus has an important point here. We need to be **much more** vigilant about specifications messing with their normative references. Saying how they are used, yes, but re-stating (or, worse, re-interpreting) normative material from those references is prone to creating dialects that no longer interoperate with their unadulterated originals. Unless these are hopelessly broken(*) and this is the only way to fix them, this is a MUST NOT. Grüße, Carsten (*) the normative reference EST has an example for that case: The use of content-transfer-encoding with HTTP, which is explicitly ruled out in Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was a count of RFC 7030 messing with a normative reference, and in turn **needed** to be messed with in CoAP-EST (and eventually needs to be fixed in the parent specification, too).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
