[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [xrds-simple] Starting over... Sorta
--Apple-Mail-311--326711203 Content-Type: multipart/alternative; boundary=Apple-Mail-310--326711281 --Apple-Mail-310--326711281 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable FYI Begin forwarded message: > From: Eran Hammer-Lahav <eran@hueniverse.com> > Date: August 11, 2008 4:33:19 PM PDT (CA) > To: "xrds-simple@googlegroups.com" <xrds-simple@googlegroups.com> > Subject: [xrds-simple] Starting over... Sorta > Reply-To: xrds-simple@googlegroups.com > > My work on the second draft of XRDS-Simple has been stuck in a one-=20 > step-forward-two-steps-back pattern. The reason for that is my =20 > objectives for the project changed from a small clarification spec =20 > that was aimed to make OAuth Discovery easier to understand, to =20 > creating a simple discovery protocol for HTTP resources that will =20 > become a building block for the open web. The problem I keep getting =20= > stuck on, is the desire to create something clean and simple vs. the =20= > argument (I=92ve made many times before) of running code. The running =20= > code argument seems to be losing. For the past 10 months I have =20 > spent most of my =93technical=94 time thinking about discovery. I feel = I =20 > have a very clear idea at this point as to what I would like the =20 > HTTP discovery specification to look like. > > I would have probably avoided opening this up has the XRI Resolution =20= > 2.0 passed the OASIS vote and became a standard. But given the =20 > current state of things over at OASIS, and the discussions with the =20= > W3C TAG, it is a given that the 2.0 specification is going to be =20 > changed (I think as required by the OASIS rules). This creates an =20 > opportunity to reset this effort and better align it with my =20 > objectives. > > --- > > The discovery specification contains two components: > > A document format for describing the properties of an HTTP resource. > A protocol for the association and retrieval of the discovery =20 > document using the resource URI. > > For #1 we have been using a stripped down version of XRDS with 2 =20 > elements added (MustSupport and TemplateURI). > For #2 we have been using the Yadis protocol as adopted by XRI =20 > Resolution 2.0 section 6 with some minor consistency modifications. > > --- > > I have been convinced that the Yadis protocol is not consistent with =20= > intentions of HTTP with regard to using the Accept header, which =20 > should return an equivalent representation of the resource itself, =20 > not its metadata. In addition, an IETF draft is aimed at providing a =20= > partial solution = (http://tools.ietf.org/id/draft-nottingham-http-link-header-02.txt=20 > ) seems like the right approach to replace the X-XRDS-Location =20 > header, and is in line with both the HTML and AtomPub way of doing a =20= > similar thing. > > For the sake of full disclosure, some of my reservation are =20 > influenced by the internal feedback I received from my Yahoo! =20 > coworkers with regard to what will and will not be allowed on the =20 > Yahoo! front page. The two primary Yahoo! concerns are serving =20 > anything other than the HTML representation of the front page (proxy =20= > serving the XRDS document instead of the HTML document to an end =20 > user), and bandwidth waste caused by including the X-XRDS-Location =20 > header on every front page request. While this concern might not be =20= > shared by others, I believe the solution should be easily =20 > implementable by small and large providers alike. > > --- > > I (still) like the XRDS-Simple schema. I don=92t like the way it =20 > builds on top of a larger schema and removes support from it, and I =20= > find the element name =91Service=92 to be too confusing. I don=92t = mind =20 > (but hate explaining) why it uses an XML namespace that starts with =20= > an xri:// scheme. And the overall structure could be tweaked to make =20= > it more trivial to understand. Every once is a while I get confused =20= > about the =93right=94 way to implement something in XRDS. This is not =20= > good. The delta between my desired schema and the current XRDS-=20 > Simple schema is very (very) small. > > We have a few options with regard to where to go from here: > > Continue with XRDS-Simple as a subset of XRDS with an indicator for =20= > parsers to know that the document is limited to the subset. > Make XRI use an enhanced version of XRDS-Simple instead of XRDS-=20 > Simple use a restricted version of XRDS. This is consistent with the =20= > proposal of splitting XRDS from XRI, giving it its own =20 > specification. The base schema can be called something else and make =20= > XRDS build on top of that. > Creating a separate schema with a different name as an alternative =20 > solution to XRDS. > > To be honest, I have pretty much made up *my* mind that option 1 is =20= > not going to work. Option 2 is the *right* solution, but if it=92s not = =20 > going to work out, option 3 is the way to go. I find the political =20 > and technical complications of option 1 not to be worth the hassle =20 > (but was well worth the effort so far as it got us a significant =20 > amount of quality groundwork in XRDS-Simple). > > --- > > I think the best next step is to draft what the =93clean=94 solution =20= > looks like. That is, applying the necessary tweaks to the XRDS-=20 > Simple schema including an HTTP XML namespace and renaming a couple =20= > of elements. It includes proposing a new protocol using the HTTP =20 > Link header and HTML Link element. Once we have that, compare the =20 > two and figure out what is the best way to move forward =96 =20 > politically and technically. The changes are minor, but in my =20 > opinion critical. > > EHL > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google =20 > Groups "XRDS-Simple" group. > To post to this group, send email to xrds-simple@googlegroups.com > To unsubscribe from this group, send email to = xrds-simple+unsubscribe@googlegroups.com > For more options, visit this group at = http://groups.google.com/group/xrds-simple?hl=3Den > -~----------~----~----~----~------~----~------~--~--- > --Apple-Mail-310--326711281 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; ">FYI<br><div><br><div>Begin = forwarded message:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" color=3D"#000000" = style=3D"font: 12.0px Helvetica; color: #000000"><b>From: = </b></font><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px = Helvetica">Eran Hammer-Lahav <<a = href=3D"mailto:eran@hueniverse.com";>eran@hueniverse.com</a>></font></div><= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" color=3D"#000000" = style=3D"font: 12.0px Helvetica; color: #000000"><b>Date: = </b></font><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px = Helvetica">August 11, 2008 4:33:19 PM PDT (CA)</font></div><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" color=3D"#000000" = style=3D"font: 12.0px Helvetica; color: #000000"><b>To: </b></font><font = face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">"<a = href=3D"mailto:xrds-simple@googlegroups.com";>xrds-simple@googlegroups.com<= /a>" <<a = href=3D"mailto:xrds-simple@googlegroups.com";>xrds-simple@googlegroups.com<= /a>></font></div><div style=3D"margin-top: 0px; margin-right: 0px; = margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" = size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: = #000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"3" = style=3D"font: 12.0px Helvetica"><b>[xrds-simple] Starting over... = Sorta</b></font></div><div style=3D"margin-top: 0px; margin-right: 0px; = margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" = size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: = #000000"><b>Reply-To: </b></font><font face=3D"Helvetica" size=3D"3" = style=3D"font: 12.0px Helvetica"><a = href=3D"mailto:xrds-simple@googlegroups.com";>xrds-simple@googlegroups.com<= /a></font></div><div style=3D"margin-top: 0px; margin-right: 0px; = margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> = </div><div> <font face=3D"Calibri, Verdana, Helvetica, Arial"><span = style=3D"font-size:11pt">My work on the second draft of XRDS-Simple has = been stuck in a one-step-forward-two-steps-back pattern. The reason for = that is my objectives for the project changed from a small clarification = spec that was aimed to make OAuth Discovery easier to understand, to = creating a simple discovery protocol for HTTP resources that will become = a building block for the open web. The problem I keep getting stuck on, = is the desire to create something clean and simple vs. the argument = (I=92ve made many times before) of running code. The running code = argument seems to be losing. For the past 10 months I have spent most of = my =93technical=94 time thinking about discovery. I feel I have a very = clear idea at this point as to what I would like the HTTP discovery = specification to look like.<br> <br> I would have probably avoided = opening this up has the XRI Resolution 2.0 passed the OASIS vote and = became a standard. But given the current state of things over at OASIS, = and the discussions with the W3C TAG, it is a given that the 2.0 = specification is going to be changed (I think as required by the OASIS = rules). This creates an opportunity to reset this effort and better = align it with my objectives.<br> <br> ---<br> <br> The discovery = specification contains two components:<br> <br> = </span></font><ol><li><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt">A document format for describing = the properties of an HTTP resource. </span></font></li><li><font = face=3D"Calibri, Verdana, Helvetica, Arial"><span = style=3D"font-size:11pt">A protocol for the association and retrieval of = the discovery document using the resource URI.<br> = </span></font></li></ol><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt"><br> For #1 we have been using a = stripped down version of XRDS with 2 elements added (MustSupport and = TemplateURI).<br> For #2 we have been using the Yadis protocol as = adopted by XRI Resolution 2.0 section 6 with some minor consistency = modifications.<br> <br> ---<br> <br> I have been convinced that the = Yadis protocol is not consistent with intentions of HTTP with regard to = using the Accept header, which should return an equivalent = representation of the resource itself, not its metadata. In addition, an = IETF draft is aimed at providing a partial solution (<font = color=3D"#0000FF"><u><a = href=3D"http://tools.ietf.org/id/draft-nottingham-http-link-header-02.txt"= >http://tools.ietf.org/id/draft-nottingham-http-link-header-02.txt</a></u>= </font>) seems like the right approach to replace the X-XRDS-Location = header, and is in line with both the HTML and AtomPub way of doing a = similar thing.<br> <br> For the sake of full disclosure, some of my = reservation are influenced by the internal feedback I received from my = Yahoo! coworkers with regard to what will and will not be allowed on the = Yahoo! front page. The two primary Yahoo! concerns are serving anything = other than the HTML representation of the front page (proxy serving the = XRDS document instead of the HTML document to an end user), and = bandwidth waste caused by including the X-XRDS-Location header on every = front page request. While this concern might not be shared by others, I = believe the solution should be easily implementable by small and large = providers alike.<br> <br> ---<br> <br> I (still) like the XRDS-Simple = schema. I don=92t like the way it builds on top of a larger schema and = removes support from it, and I find the element name =91Service=92 to be = too confusing. I don=92t mind (but hate explaining) why it uses an XML = namespace that starts with an xri:// scheme. And the overall structure = could be tweaked to make it more trivial to understand. Every once is a = while I get confused about the =93right=94 way to implement something in = XRDS. This is not good. The delta between my desired schema and the = current XRDS-Simple schema is very (very) small.<br> <br> We have a few = options with regard to where to go from here:<br> <br> = </span></font><ol><li><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt">Continue with XRDS-Simple as a = subset of XRDS with an indicator for parsers to know that the document = is limited to the subset. </span></font></li><li><font face=3D"Calibri, = Verdana, Helvetica, Arial"><span style=3D"font-size:11pt">Make XRI use = an enhanced version of XRDS-Simple instead of XRDS-Simple use a = restricted version of XRDS. This is consistent with the proposal of = splitting XRDS from XRI, giving it its own specification. The base = schema can be called something else and make XRDS build on top of that. = </span></font></li><li><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt">Creating a separate schema with a = different name as an alternative solution to XRDS.<br> = </span></font></li></ol><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt"><br> To be honest, I have pretty = much made up *my* mind that option 1 is not going to work. Option 2 is = the *right* solution, but if it=92s not going to work out, option 3 is = the way to go. I find the political and technical complications of = option 1 not to be worth the hassle (but was well worth the effort so = far as it got us a significant amount of quality groundwork in = XRDS-Simple).<br> <br> ---<br> <br> I think the best next step is to = draft what the =93clean=94 solution looks like. That is, applying the = necessary tweaks to the XRDS-Simple schema including an HTTP XML = namespace and renaming a couple of elements. It includes proposing a new = protocol using the HTTP Link header and HTML Link element. Once we have = that, compare the two and figure out what is the best way to move = forward =96 politically and technically. The changes are minor, but in = my opinion critical.<br> <br> EHL<br> <br> <br> <br> = <br> <br> <br> <br> <br> = <br> <br> <br> </span></font> <br> = --~--~---------~--~----~------------~-------~--~----~<br> You received = this message because you are subscribed to the Google Groups = "XRDS-Simple" group. <br> To post to this group, send email to <a = href=3D"mailto:xrds-simple@googlegroups.com";>xrds-simple@googlegroups.com<= /a> <br> To unsubscribe from this group, send email to <a = href=3D"mailto:xrds-simple+unsubscribe@googlegroups.com";>xrds-simple+unsub= scribe@googlegroups.com</a> <br> For more options, visit this group at = <a = href=3D"http://groups.google.com/group/xrds-simple?hl=3Den";>http://groups.= google.com/group/xrds-simple?hl=3Den</a> <br> = -~----------~----~----~----~------~----~------~--~---<br> </div> = <br></blockquote></div><br></body></html>= --Apple-Mail-310--326711281-- --Apple-Mail-311--326711203 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGITCCAtow ggJDoAMCAQICEE2TeuJWprpXkMqh1ISkswAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTAyMjIwMzEwMVoXDTA4MTAyMTIwMzEw MVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0GCSqGSIb3DQEJARYQamJy YWRsZXlAbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM8iEfzV7DTQKqBc qqx3ZYfq/PyiZJs5HEov8vnHG6eRv1YE6zp0DuPyIbKeNRlHYda+Wd0Ux7VGtroEzGlhgqUzj1Xi MP9YN7b4qrQlyeTwA1vTuNGNl217ZgZ9gwrc2Agf0I5qNiYf4KDiWC573hLmTqBuG2zh63lUjFbW lpNddY+7mGYRfBer3cQaayYf4lIz2IEtT4E2XQrseVp2pzuwM9QgLa0J6V8b8fJSXcSD/o8z+/oQ 2jmwfR+APh18EPU2oOJYyxE0riYCcsbJA4Ff+puvnP5ExiitqxkEVHobvNq2NbAd+d7Y+JQ4Rj9R VqYXoBGvXxhXUUCpSzbrzYsCAwEAAaMtMCswGwYDVR0RBBQwEoEQamJyYWRsZXlAbWFjLmNvbTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAD/Ix3ZLWcsqfURljbMYCoCUZweW1PtfbO0v JbxXyhBvsrlGpoZbJuoWoPIy5Q4KxypJ1A5he0JsysixLZCJySi1yiHQ78fZt2r0aDxMRY4PKukx gPNr5gmb4hBAov095Evd1eq9fuknhe60XCri3k7FmHcKax0NQ3AfG23VwhtgMIIDPzCCAqigAwIB AgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7 TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRA HmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYy aHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0P BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG 9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8 /a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQ Gls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBNk3riVqa6V5DKodSEpLMAMAkGBSsOAwIaBQCgggFv MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDgxMTIzNTA1N1ow IwYJKoZIhvcNAQkEMRYEFJZrgvp49homuO0Jinr/07vS9N+6MIGFBgkrBgEEAYI3EAQxeDB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQTZN64lamuleQyqHUhKSz ADCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQTZN64lamuleQyqHUhKSzADANBgkqhkiG9w0BAQEFAASCAQCEzqxaWQisY47xWnXh u2uPpNkBMUmK0Yx23gGsGLnUDr5IjAPvRroOBxOfAszlwLAGs9jjkGbRZZTe3At1iGk5ejHtjrDE t8KBjyhTaGsMMfedaSbU+jkZ07QaczGMo+GCL9bGrz9tcOh9kWzsUVYbXMFDfglqkOOTndV1Qh8x fTFUiIgnk4WIwoWeXxJhGBmQZ3D/yLYcDJzCTe+KX391+V+oMOMflbpe7jcEgaafYHBJDwLZDkzy rHF7BW3OJZeUoHpCMr/LmAYIIq5XtwRvRRYle1uC8Ks7YE6Xt3v8j5cL72PlVRseLWoWjNMIcjAA /q5gm+OE+NqxAPJnE6k9AAAAAAAA --Apple-Mail-311--326711203--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]