Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 06 Jan 2020 17:30:02 +0000

Hi Panos,

On Fri, Dec 27, 2019, at 5:20 AM, Panos Kampanakis (pkampana) wrote:
> 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.

Yes, the changes look fine to me. I just cleared my DISCUSS.

Best Regards,
Alexey

> Rgs,

> Panos

> *From:* Ace <[email-masked]> *On Behalf Of *Alexey Melnikov
> *Sent:* Monday, December 23, 2019 9:42 AM
> *To:* [email-masked]; Carsten Bormann <[email-masked]>
> *Cc:* [email-masked]; Jim Schaad <[email-masked]>; Benjamin Kaduk <[email-masked]>; Ace Wg <[email-masked]>; The IESG <[email-masked]>; [email-masked]; Klaus Hartke <[email-masked]>
> *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 <[email-masked]> 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).

> *Attachments:*
>  * smime.p7s