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.
Peter
Carsten Bormann schreef op 2019-12-20 18:16:
On Dec 20, 2019, at 17:34, Klaus Hartke <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ace
