On Mar 15, 2011, at 11:19 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/14/2011 05:43 PM, Cullen Jennings wrote: >> >> There are a few things that did not get fixed in the -13 draft. Some due to >> just not sure how to fix them yet and some due to lack of time. The remanning >> open items are > > [...] > >>> A.39. Section 6.2.2 >>> >>> I am not really sure to understand how the "exists=False" are synthesized >>> when doing a Fetch on an array. For example if a Store was made for an >>> object with an index of 0xfffffffe, and the Fetch requests the whole array, >>> will the answer contains 4294967294 "exists=False" objects? >> >> Proposal: Yes >> >>> Also how are this synthesized elements signed? >> >> Proposal: The "opaque value<0..2^32-1>;" would just indicate a 0 byte long >> binary blog and be encoded per normal. >> > > My proposal is to get rid of the synthesized elements. A Fetch returns the > array with holes in it but returns the exists=False elements that were sent. > > This solves a lot of issues (who sign them? What is the storage_time and > lifetime of a synthesized element?)
Hi Marc, I think I'm the person who put this text in originally but it's been a while so I'm trying to reconxtruct my reasoning. Let's ignore arrays for a second and just talk about simple elements. A requester asks for objects with resource-ids A, B, and C, but B doesn't exist and so he just gets A and C. Now he has to remember what he asked for and do some set intersection to see what was and wasn't returned. By contrast, if you get back an answer for every request, then it's simpler to understand the response. I'm not saying that it's impossible to do the former, but the latter is easier. Now, when we come to arrays, life is more complicated, since I might ask for either element i or elements i..j. We could have the rule that we never return synthesized elements for arrays, or that we only do so for explicit as opposed to range queries, or that we always do. All of these are consistent, I think. Anyway, you may or may not find the original rationale compelling--I'm not sure if I still do--but IIRC that was the reason. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
