[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Thoughts on XRD-to-resource cardinality
--Apple-Mail-525--592330924 Content-Type: multipart/alternative; boundary=Apple-Mail-524--592331006 --Apple-Mail-524--592331006 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I was thinking myself that one of the use cases we need to not loose site of is the fragment in the cannonicalID to allow relying parties to detect URI recycling. I agree with you about the template really being an instantiation of a XRD for a resource. There is still a one to one relationship between the resource and the XRD describing it. The trick is that with a template the XRD is a self assertion by the resource (URI) that the identifier has a relationship ie describedby to the instance of the XRD in question. The XRD in this case would NOT contain a CannonicalID directly it may contain some other template to validate the URI's that may have a relationship to it. That template would also be used to validate any signature. To my mind in this case the CannonicalID from the perspective of the RP would be the URI that expresses the relationship. I consider everything in the XRD to be self asserted claims with the exception of the CID if the XRD is signed. =jbradley On 29-Jan-09, at 5:13 AM, Nat Sakimura wrote: > Comments inline: > > -------------------------------------------------- > From: "Drummond Reed" <drummond.reed@cordance.net> > Sent: Wednesday, January 28, 2009 2:59 PM > To: "'XRI TC'" <xri@lists.oasis-open.org> > Subject: [xri] Thoughts on XRD-to-resource cardinality > >> I will be offline Thursday and Friday travelling to a memorial, so >> I want to >> contribute here on the list to advance today's discussion about >> XRD-to-resource mapping >> (http://wiki.oasis-open.org/xri/SelfServeAgenda#head-a4044b7035eb441c2674549 >> d07ccaf27daed8970). >> >> As I said on the call, the concept of a one-to-many mapping between >> an XRD >> and the resources it describes is a mind-expander for those of us >> who have >> been living a one-XRD-to-one-resource worldview for a few years >> now. But the >> use case -- being able to get and cache one XRD to describe >> potentially a >> very large number of resources (such as an entire site) is >> compelling. > > Well, as I have stated in my previous mail, this is a well studied > area in > the Object Orientation, I suppose, and it still is one-XRD-to-one- > resource. > We have just defined a instantiation method by templating. > >> >> Under a one-to-many mapping, I believe Eran's right that the >> concept of >> asserting a synonym (not just CanonicalID but any synonym) pretty >> much goes >> away. The only synonym assertion I could see providing is some form >> of >> aliasing template that would apply to the URIs of all the described >> resources (e.g., every that maps to the http://foo.example.com/* >> template >> can all be mapped to the http://bar.example.com/* template). > > I am not sure about this. Think of this example. > > <XRD> > <CanonicalID>https://sakimura.org/nat#12345678</CanonicalID> > <About>https://google.com/sakimura</About> > <About>https://id.mixi.jp/nat</About> > <About>https://marimba.org/webmaster</About> > <About>https://nri.co.jp/employee/n-sakimura</About> > <link> > .... > </link> > </XRD> > > How do you construct a valid template for this example? > (Of course, the above XRD is just stating that owner of the > CanonicalID > allows him to be desribed by the uris in <About>, and not vice-versa.) > > >> >> But that appears to be of limited use, and probably not appropriate >> for >> assigning CanonicalIDs (which is usually a mapping from a >> reassignable to a >> persistent identifier). >> >> But the rest of the XRD metadata and Link metadata still seems >> appropriate, >> i.e., it applies as much to an individual resource (one-to-one >> mapping) as >> it does to a group of resources (one-to-many mapping). >> >> So what I'm wondering is if maybe there should be a clear way of >> indicating >> the cardinality of the XRD. In other words, a child element of the >> root XRD >> element that indicates whether it is it an individual XRD (one-to-one >> mapping) or a group XRD (one-to-many mapping). >> >> If there was a choice between two mutually exclusive options for >> that child >> element, then all the other elements that are appropriate only for >> one or >> the other (CanonicalID, EquivID, URIMap, etc.) could follow as >> children of >> that element. >> >> Here's a simple example using the element names <Resource> and >> <ResourceGroup>: >> >> INDIVIDUAL XRD: >> >> <XRD> >> <Expires>2009-01-01T08:30:00Z</Expires> >> <Resource> >> <CanonicalID>http://example.com/resource/1</CanonicalID> >> <EquivID>http://example.net/resource/1</EquivID> >> </Resource> >> <Type>http://example.com/type/profile_photo</Type> >> >> <Link> >> <URI>http://example.com/resource/2</URI> >> <Rel>http://example.com/rel/profile</Rel> >> </Link> >> </XRD> >> >> GROUP XRD: >> >> <XRD> >> <Expires>2009-01-01T08:30:00Z</Expires> >> <ResourceGroup> >> <URIMap>http://example.com/resource/*</URIMap> >> </ResourceGroup> >> <Type>http://example.com/type/photos</Type> >> >> <Link> >> <URI>http://example.com/service/1</URI> >> <Rel>http://example.com/rel/some-group-service</Rel> >> </Link> >> </XRD> >> >> Thoughts? > > BTW, is this <Resource> element now semi-official? > >> >> =Drummond >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/ >> my_workgroups.php >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --Apple-Mail-524--592331006 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; ">I was thinking myself that one = of the use cases we need to not loose site of is the fragment in the = cannonicalID to allow relying parties to detect URI = recycling.<div><br></div><div>I agree with you about the = template really being an instantiation of a XRD for = a resource. There is still a one to one relationship between the = resource and the XRD describing it.</div><div><br></div><div>The trick = is that with a template the XRD is a self assertion by the = resource (URI) that the identifier has a relationship ie = describedby to the instance of the XRD in question. = </div><div><br></div><div>The XRD in this case would NOT contain a = CannonicalID directly it may contain some other template to validate the = URI's that may have a relationship to it. That template = would also be used to validate any = signature.</div><div><br></div><div>To my mind in this case the = CannonicalID from the perspective of the RP would be the URI that = expresses the relationship.</div><div><br></div><div>I consider = everything in the XRD to be self asserted claims with the = exception of the CID if the XRD is = signed.</div><div><br></div><div>=3Djbradley</div><div><br><div><div>On = 29-Jan-09, at 5:13 AM, Nat Sakimura wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div>Comments = inline:<br><br>--------------------------------------------------<br>From:= "Drummond Reed" <<a = href=3D"mailto:drummond.reed@cordance.net";>drummond.reed@cordance.net</a>>= <br>Sent: Wednesday, January 28, 2009 2:59 PM<br>To: "'XRI TC'" <<a = href=3D"mailto:xri@lists.oasis-open.org";>xri@lists.oasis-open.org</a>><br>= Subject: [xri] Thoughts on XRD-to-resource = cardinality<br><br><blockquote type=3D"cite">I will be offline Thursday = and Friday travelling to a memorial, so I want = to<br></blockquote><blockquote type=3D"cite">contribute here on the list = to advance today's discussion about<br></blockquote><blockquote = type=3D"cite">XRD-to-resource mapping<br></blockquote><blockquote = type=3D"cite">(<a = href=3D"http://wiki.oasis-open.org/xri/SelfServeAgenda#head-a4044b7035eb44= 1c2674549">http://wiki.oasis-open.org/xri/SelfServeAgenda#head-a4044b7035e= b441c2674549</a><br></blockquote><blockquote = type=3D"cite">d07ccaf27daed8970).<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">As I said on = the call, the concept of a one-to-many mapping between an = XRD<br></blockquote><blockquote type=3D"cite">and the resources it = describes is a mind-expander for those of us who = have<br></blockquote><blockquote type=3D"cite">been living a = one-XRD-to-one-resource worldview for a few years now. But = the<br></blockquote><blockquote type=3D"cite">use case -- being able to = get and cache one XRD to describe potentially = a<br></blockquote><blockquote type=3D"cite">very large number of = resources (such as an entire site) is = compelling.<br></blockquote><br>Well, as I have stated in my previous = mail, this is a well studied area in<br>the Object Orientation, I = suppose, and it still is one-XRD-to-one-resource.<br>We have just = defined a instantiation method by templating.<br><br><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Under a = one-to-many mapping, I believe Eran's right that the concept = of<br></blockquote><blockquote type=3D"cite">asserting a synonym (not = just CanonicalID but any synonym) pretty much = goes<br></blockquote><blockquote type=3D"cite">away. The only synonym = assertion I could see providing is some form = of<br></blockquote><blockquote type=3D"cite">aliasing template that = would apply to the URIs of all the described<br></blockquote><blockquote = type=3D"cite">resources (e.g., every that maps to the <a = href=3D"http://foo.example.com/*";>http://foo.example.com/*</a> = template<br></blockquote><blockquote type=3D"cite">can all be mapped to = the <a href=3D"http://bar.example.com/*";>http://bar.example.com/*</a> = template).<br></blockquote><br>I am not sure about this. Think of this = example.<br><br><XRD><br> <CanonicalID><a = href=3D"https://sakimura.org/nat";>https://sakimura.org/nat</a>#12345678<= ;/CanonicalID><br> <About><a = href=3D"https://google.com/sakimura";>https://google.com/sakimura</a></A= bout><br> <About><a = href=3D"https://id.mixi.jp/nat";>https://id.mixi.jp/nat</a></About><br> = <About><a = href=3D"https://marimba.org/webmaster";>https://marimba.org/webmaster</a>&l= t;/About><br> <About><a = href=3D"https://nri.co.jp/employee/n-sakimura";>https://nri.co.jp/employee/= n-sakimura</a></About><br> <link><br> = ....<br> = </link><br></XRD><br><br>How do you construct a valid = template for this example?<br>(Of course, the above XRD is just stating = that owner of the CanonicalID<br> allows him to be desribed by the uris = in <About>, and not vice-versa.)<br><br><br><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">But that = appears to be of limited use, and probably not appropriate = for<br></blockquote><blockquote type=3D"cite">assigning CanonicalIDs = (which is usually a mapping from a reassignable to = a<br></blockquote><blockquote type=3D"cite">persistent = identifier).<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">But the rest of = the XRD metadata and Link metadata still seems = appropriate,<br></blockquote><blockquote type=3D"cite">i.e., it applies = as much to an individual resource (one-to-one mapping) = as<br></blockquote><blockquote type=3D"cite">it does to a group of = resources (one-to-many mapping).<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">So what I'm = wondering is if maybe there should be a clear way of = indicating<br></blockquote><blockquote type=3D"cite">the cardinality of = the XRD. In other words, a child element of the root = XRD<br></blockquote><blockquote type=3D"cite">element that indicates = whether it is it an individual XRD = (one-to-one<br></blockquote><blockquote type=3D"cite">mapping) or a = group XRD (one-to-many mapping).<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">If there was a = choice between two mutually exclusive options for that = child<br></blockquote><blockquote type=3D"cite">element, then all the = other elements that are appropriate only for one = or<br></blockquote><blockquote type=3D"cite">the other (CanonicalID, = EquivID, URIMap, etc.) could follow as children = of<br></blockquote><blockquote type=3D"cite">that = element.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Here's a simple = example using the element names <Resource> = and<br></blockquote><blockquote = type=3D"cite"><ResourceGroup>:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">INDIVIDUAL = XRD:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><XRD><br></blockquote><blockquote type=3D"cite"> = <Expires>2009-01-01T08:30:00Z</Expires><br></blockquote>= <blockquote type=3D"cite"> = <Resource><br></blockquote><blockquote type=3D"cite"> = <CanonicalID><a = href=3D"http://example.com/resource/1";>http://example.com/resource/1</a>&l= t;/CanonicalID><br></blockquote><blockquote type=3D"cite"> = <EquivID><a = href=3D"http://example.net/resource/1";>http://example.net/resource/1</a>&l= t;/EquivID><br></blockquote><blockquote type=3D"cite"> = </Resource><br></blockquote><blockquote type=3D"cite"> = <Type><a = href=3D"http://example.com/type/profile_photo";>http://example.com/type/pro= file_photo</a></Type><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite"> = <Link><br></blockquote><blockquote type=3D"cite"> = <URI><a = href=3D"http://example.com/resource/2";>http://example.com/resource/2</a>&l= t;/URI><br></blockquote><blockquote type=3D"cite"> = <Rel><a = href=3D"http://example.com/rel/profile";>http://example.com/rel/profile</a>= </Rel><br></blockquote><blockquote type=3D"cite"> = </Link><br></blockquote><blockquote = type=3D"cite"></XRD><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">GROUP = XRD:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><XRD><br></blockquote><blockquote type=3D"cite"> = <Expires>2009-01-01T08:30:00Z</Expires><br></blockquote>= <blockquote type=3D"cite"> = <ResourceGroup><br></blockquote><blockquote type=3D"cite"> = <URIMap><a = href=3D"http://example.com/resource/*";>http://example.com/resource/*</a>&l= t;/URIMap><br></blockquote><blockquote type=3D"cite"> = </ResourceGroup><br></blockquote><blockquote type=3D"cite">= <Type><a = href=3D"http://example.com/type/photos";>http://example.com/type/photos</a>= </Type><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite"> = <Link><br></blockquote><blockquote type=3D"cite"> = <URI><a = href=3D"http://example.com/service/1";>http://example.com/service/1</a><= /URI><br></blockquote><blockquote type=3D"cite"> = <Rel><a = href=3D"http://example.com/rel/some-group-service";>http://example.com/rel/= some-group-service</a></Rel><br></blockquote><blockquote type=3D"cite">= </Link><br></blockquote><blockquote = type=3D"cite"></XRD><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">Thoughts?<br></blockquote><br>BTW, is this <Resource> = element now semi-official?<br><br><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">=3DDrummond<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">------------------------------------------------------------= ---------<br></blockquote><blockquote type=3D"cite">To unsubscribe from = this mail list, you must leave the OASIS TC = that<br></blockquote><blockquote type=3D"cite">generates this mail. = Follow this link to all your TCs in OASIS = at:<br></blockquote><blockquote type=3D"cite"><a = href=3D"https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups= .php">https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p= hp</a><br></blockquote><blockquote = type=3D"cite"><br></blockquote><br>---------------------------------------= ------------------------------<br>To unsubscribe from this mail list, = you must leave the OASIS TC that<br>generates this mail. Follow = this link to all your TCs in OASIS at:<br><a = href=3D"https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups= .php">https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p= hp</a> <br></div></blockquote></div><br></div></body></html>= --Apple-Mail-524--592331006-- --Apple-Mail-525--592330924 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGrzCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggNoMIIC0aADAgECAhAd94+bIYviuSaQ w/qU/yWPMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wODEyMTIwMTU0MzFaFw0wOTEyMTIwMTU0MzFaMIGfMR8wHQYDVQQDExZUaGF3 dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBqYnJhZGxleUBtYWMuY29tMR4wHAYJ KoZIhvcNAQkBFg9qYnJhZGxleUBtZS5jb20xHTAbBgkqhkiG9w0BCQEWDnZlN2p0YkBtYWMuY29t MRwwGgYJKoZIhvcNAQkBFg12ZTdqdGJAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxB2GGbZ5p8mVtg16CSDXeF8F3D+5sbs8L4b/YrHt/BvtQdE8GY202cUko/b/rXTUA0JC XZRDrOiH7ZxcqI4alJNel9AcSLepcdHN4+t2zhvWilm+YF0/r6m/1PikkVT9TWic61IZMpNWIUkk A+MWzEjChYPefdSMhxikhhMFZ0sv2qPE9pmdaPtD2uF4MwKnIzdZYo+X7rWoaXHIdsZwZDU3HdR5 rVuK5s9xvRED7TZgwE1/yHzHnTbedUWPdNNUlL24Jp3iiVzjZan8zOCn6x4b8O1QPN5b/FOZrerq FDZ2zhIBsWEcKdIxqIqPdVkrYvEfGBLMe1QIORu0J56L/QIDAQABo10wWzBLBgNVHREERDBCgRBq YnJhZGxleUBtYWMuY29tgQ9qYnJhZGxleUBtZS5jb22BDnZlN2p0YkBtYWMuY29tgQ12ZTdqdGJA bWUuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEADhjvX5w/BXN7OL5y1ZfydfmJ RKezNqugUDf8XbKmmMR/o+vjx395pBpO9QF8hQwtKNDuvoxLTNDMWdcCNbvaEpqREXc7liV9FfA5 ndAB1VgDqYDjY9M9LU54LH8uqEx7+pX6qa6KoR8eRHby9zi+iuSkJ4GLI59RBnVI54x4/acxggMQ MIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQHfeP myGL4rkmkMP6lP8ljzAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wOTAxMjkyMTQzNDNaMCMGCSqGSIb3DQEJBDEWBBQLUNep7SwcRmxsBC2c PaOWJxNH9TCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wDQYJ KoZIhvcNAQEBBQAEggEAph9t/CcD/jtpZfmKz1zbMknWuNeBs3DqFSy4pnSDiO/XZs4rm7/K13Iu ckmpK6PlkGtQoOwl2OUawjrYHfwWYPpPIta3fl8JJwtTUiuNuHv094BhkcWMW/fApSu66WT/stA+ SS4QBQ2TdqFJzEmrXZModCi5gE8BQeEXZ0XPG9V7lpNlMJ2dYn19GLP6foEOxlSv+QS2LMIaLumL BkkIUThXrjwnnCUdXeBAUE/fMEuAPy+RxtsIjUz72sJbkacZFrBHtv7wTkIbPZlkACGEFjCUKFqv K6B6KY8NomlCQ7s/SUvGtRw9ycuuX2Nb73mIt8vpDkPwA8YoStCDO5CAiAAAAAAAAA== --Apple-Mail-525--592330924--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]