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> 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).
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
