<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  That would make sense for one direction, however we need the information in<br>
both directions.</blockquote><div><br>You would need a separate entry for the other direction with the "requires-way" as well which is also a similar situation to that you have described below. I do not personally call this an issue.<br>
 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also, since users aren't allowed to edit other users' content<br>
items, it would be problematic to suddenly add such information to content/get<br>
as it would indicate it has been vetted somehow (as everything else returned<br>
by that call is provided by the owner, not by others). However, if that is<br>
deemed to not be a problem by everybody else here, then i don't have any real<br>
issue with that idea.<br></blockquote><div><br>I would not personally place ACL in general into the specification because of the following reasons:<br><br>1) It is outside of the scope for this specification.<br>2) The real content still belongs only to the author, it is just about the collaboration data.<br>
3) S<span>ervers should only return what data they are permitted to</span>, <span>by their acl model.<br>4) C</span><span>lient apps should not assume. </span><span>They will get all data requested</span>.<br>5) Such considerations can slow the specification down in general at times (i.e. getting all the necessary metadata in a bunch does not result extra calls which can be costy as mentioned in a previous email).<br>
 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  A note, though: For adding, the information should need to be given on<br>
adding and editing the child item, though presumably that would go without<br>
saying. The information in content/get would then become an aggregation, akin<br>
to the comments number.<br></blockquote><div><br>Yes, it would be consistent with the rest for OCS v1.<br><br>Laszlo<br></div></div>