<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 September 2015 at 11:12, Florian Schmaus <span dir="ltr"><<a href="mailto:flo@geekplace.eu" target="_blank">flo@geekplace.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 16.09.2015 23:26, Dave Cridland wrote:<br>
> On 16 September 2015 at 22:21, Florian Schmaus <<a href="mailto:flo@geekplace.eu">flo@geekplace.eu</a><br>
</span><span class="">> <mailto:<a href="mailto:flo@geekplace.eu">flo@geekplace.eu</a>>> wrote:<br>
>     > The last time this came up, many many months ago, I recall there not<br>
>     > being consensus to change.  But that was then and this is now.<br>
>     ><br>
>     > What are implementers doing today?<br>
>     ><br>
>     > * Are implementations using XEP-0280's <private/>?<br>
>     > * Are implementations using XEP-0334's <no-copy/>?<br>
><br>
>     Smack's doing <private/><br>
><br>
>     > * Are implementations supporting both, but favoring XEP-0334's <no-copy/>?<br>
><br>
>     I would switch to xep334 in an instant. Kurt has a valid point about<br>
>     xep334 <no-copy/> being not as strict as <private/>. Hence I think we<br>
>     should change that bit in xep334 and incorporate the semantics of<br>
>     xep280's <private/>.<br>
><br>
><br>
> The point of '334 is that it's pure a hint and cannot be relied upon to<br>
> provide any particular behaviour.<br>
><br>
> I think changing that would probably be a mistake.<br>
><br>
> Despite your argument to the contrary, I think you and Kurt have<br>
> convinced me that we should keep Carbons (and <private/>) as-is.<br>
<br>
</span>I get your point. But it feels wrong to define nearly identical<br>
extension elements in two XEPs. The author of xep334, Matthew Wild,<br>
already expressed his willingness to change xep334 so that it can be<br>
re-used in xep280. Therefore I'm all for changing xep334, then issue a<br>
last call for it, ideally advance it to draft, then issue another last<br>
call for a xep280 version using xep334 elements, and finally advance it<br>
to draft.<br>
<br></blockquote><div><br></div><div>So summarizing...</div><div><br></div><div>Procedurally:</div><div><br></div><div>If we don't switch, then Carbons goes through to Draft now, and Hints either loses <no-copy/> or has a duplicate with softer requirements.</div><div><br></div><div>If we do switch, then Carbons is delayed and has a version bump, and Hints needs editing and goes through Last Call to Draft.</div><div><br></div><div>Technically:</div><div><br></div><div><private/> is a mandatory part of Carbons.</div><div><br></div><div><no-copy/> is an expression of opinion from the sender that Carbon copying and similar will not be useful or desirable.</div><div><br></div><div>Which semantics make more sense?</div><div><br></div><div>(And by the way I'd rather rephrase XEP-0334 in that way).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we don't fix it right now, we will potentially never get another<br>
chance to fix it.<br></blockquote><div><br></div><div>Not really true, we get to wonder if <no-copy/> is useful in the face of <private/> at a later date.</div><div><br></div><div>But even if you were right, and certainly some options close on this decision, there is the question of whether this actually matters much.</div><div><br></div><div>The only path I strongly object to would be making any of XEP-0334's Hints have mandatory (or even recommended in the RFC 2119 sense) behaviour.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- Florian<br>
<br>
</font></span></blockquote></div><br></div></div>