-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/15/2011 11:50 AM, Eric Rescorla wrote: > > 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.
Aaaah. My reading of the spec was that elements were synthesized only for arrays. Now I get it. "exists=False" is used in fact for two different functions: to remove an existing element, and as a placeholder for no-existence when retrieving data. In this case I withdraw my proposal to get rid of them, but I still have the question about the signer of the synthesized element (also the storage_time and lifetime to use). > > 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. Yeah, and removing an element could have been done by updating it with lifetime=0, which would have permit to remove the "exists". Anyway, let's keep things as they are. - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1/v4UACgkQ9RoMZyVa61ed5QCdFaUgzBD9TZwN3EwVMn1JMuyt IlgAn2V5d5cvsgPSR3CVZc1yt6BCnE4O =RsO/ -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
