Closed tschaub closed 8 years ago
As I said in a response to that email, I'd like to keep SHOULD. There are very few applications that can properly handle features that aren't cut at the anti-meridian.
As I said in email, no problem with normative SHOULD, but that should be stated as a generic requirement, not within examples.
@coopdanger Ah, I think I understand now. I think there are 2 ways to go.
Sound like a plan? /cc @tschaub @martinthomson @dret
WFM
Superseded by #195.
@tschaub I need clarification: are you now more in favor of this one than in favor of #195? It seems that way from your last msg to the mailing list.
I understand now the issue of avoiding normative language in examples. I like that this change is simpler than #195. So reopening and merging this makes sense to me.
@sgillies if you feel strongly that some of the interoperability considerations should become normative recommendations, you could continue on #195 (and it also seems like the sections don't necessarily need to be reorganized, but rather the normative language would have to come out of the examples).
This follows the suggestions from Alissa Cooper's email. I'll admit I don't understand the nuance here, but am curious to understand.
Note that we still have other RFC2119 key words in the considerations sections (including SHOULD).