Re: Proposal for Modularizing Auth 2.0 Discovery
-- Best regards, Gavin Baumanis T: +61 -3 992 51099 F: +61 -3 992 52706 E: [EMAIL PROTECTED] Property Services RMIT University Level 6, 449 Swanston Street Melbourne VIC 3000 Australia On Saturday, March 03, 2007 at 17:26, in message [EMAIL PROTECTED], Mark Baker [EMAIL PROTECTED] wrote: snip I suggest just saying that any URI can be used, and let the community/market decide what actually gets used. Mark. Sure, and (as is done already), provide appropriate examples and perhaps even leave out (of the examples) the contested ones. Not saying they can't be used, but perhaps not advertising the contentious ones either? Who makes up the list of what is/isn't??? well the list, of course as is always the case. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OA2.0d11: Minor nit-pick regarding normalization
Hi Josh / Martin, For the sake of an appropriate short sentence, is it not appropriate to include Martin's text (or similar). Does anyone really want to have read 1/2 a dozen extra specifications for clarification of a single points that could be simply included in the OpenID spec? For the sake of allowing me to more easily adopt OpenID. Sure - we MUST have appropriate references, and SHOULD use a quote from the authorative document - if it is clearly understood. If not, I think it prudent to provide as a plain an English description / example as is possible. I have read a few specifications after being asked to implement/incorporate them into work I was doing here at the university - but for the most part I ended up throwing out the spec and visiting a wiki or a mailing list - with regards to sourcing information on how to implement the specification. I can't ever remember actually reading a spec from start to finish for the purpose of implementing it. Used it as a reference for information I collected elsewhere - most certainly... I realise the importance of the SPEC and I understand the technical space in which they live, but surely we should practice what we preach - ease of uptake etc in our own documentation? On Friday, February 02, 2007 at 20:19, in message [EMAIL PROTECTED], Josh Hoyt [EMAIL PROTECTED] wrote: On 2/1/07, Martin Atkins [EMAIL PROTECTED] wrote: The normalization table in appendix A.1 lists several examples of the normalization of URIs. The last few examples are as follows: http://example4.com/ = http://example4.com/ https://example5.com/ = https://example5.com/ example6.com = http://example6.com I believe that the last example should instead normalize to: http://example6.com/ You're right that the example needs to have the slash added. I don't think that we need any extra wording because RFC3986, which we reference for the normalization rules says: a URI that uses the generic syntax for authority with an empty path should be normalized to a path of /. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Off-topic: Re: Comments on Auth 2.0 - Pre-Draft 11
Joaquin / Josh, I clearly see the position you both have here. Overusing verbs can certainly lessen their importance within any document. And by the very nature of the work the community is doing and the people it involved, and the people likely to use the specification - it is pretty safe to say that anyone reading the document is going to have a level of reading comprehension that should make it irrelevant which we way go. - I personally haven't wondered whether something was a MUST have of not - I thought it was always clear enough. But you never know who will end up reading the document and for what purpose; and with that in mind, I'm going to have to +1, inline with Joaquin's perspective on this one. As the new guy - it leaves no doubt in my mind at all as to what MUST happen. And if I can get all the MUST HAVES implemented - then surely I SHOULD have a working implementation of the specification. Gavin Baumanis RMIT University, Melbourne, Australia. On Friday, December 15, 2006 at 08:55, in message [EMAIL PROTECTED], Josh Hoyt [EMAIL PROTECTED] wrote: On 12/14/06, Joaquin Miller [EMAIL PROTECTED] wrote: I have changed that text from needs to to MUST, although I think that the sentence before that (The end user's input MUST be normalized into an Identifier) is pretty unambiguous. I feel this is an excellent change. This style should be followed throughout. The problem with 'needs to' and 'MUST' in the same document is that it leaves the reader this little puzzle to puzzle over: What is the normative difference between 'needs to' and 'MUST'? Why is 'needs to' used here and 'MUST' there? Is 'needs to' weaker than 'MUST'? Is 'needs to' stronger than 'SHOULD'? I doubt that the needs to wording would have ever caused any problems with implementation. The sentence before states that you MUST normalize the input. The needs to was describing a condition that is necessary to check in order to perform the normalization. Anyone who was attempting to implement the normalization algorithm would see that it is necessary to determine the type of the input before continuing. I think that words like MUST and SHOULD are not necessary when describing how to do something whose importance has already been made clear (by a MUST, etc.). I have a hard time reading prose that uses those words excessively, because if they are over-used, they become noise (you already said I MUST normalize). Anyway, I think the OpenID 2.0 Authentication specification is pretty consistent about using the appropriately strong wording when it's not already clear whether something is required, so I think this discussion is mostly academic. Feel free to make requests if there are specific parts whose compliance is not obvious. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Spec Development Process Write-up
David, I don't know if its misrepresenting anything or not (I am pretty green when it comes to the IETF / their processes and creating a specification... But from my totally new perspective it reads easily and gives me the basic information I need to know / want to know with regards to what is official / what is under consideration and how I contribute / ask questions as required. If there was the complete intention - then I would say it is successfully completing its job. Recordon, David [EMAIL PROTECTED] Thursday, December 07, 2006 05:23 Added a section about how specs evolve from creation to being official. Anything I'm mis-representing? http://openid.net/specs.bml --David ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID IPR Policy Draft
Again - as the new guy... It gives me a pretty thorough understanding of what's expected. With regards to your Open Issue (2), Since it is from the community perspective would it not be appropriate to have; (obviously my text will require some tweaking ) When in doubt - Bring to our attention the possibility of a conflict at the earliest time As a a follow-up question - and I am assuming it is a legal question - but does the act of disclosing a conflict / possible conflict have any possible side-effect along the lines of disclosing commercial-in-confidence information etc? Recordon, David [EMAIL PROTECTED] Thursday, December 07, 2006 06:42 Hey guys, Been working with Gabe, and others, on starting to draft an IPR Policy for OpenID specifications. We'd appreciate feedback in terms of if what is written captures the correct intent of the community? We realize the language isn't technically as tight as it needs to be, though first want to make sure it is saying the right thing. It is largely based on the IPR Policy for Microformats. http://openid.net/wiki/index.php/IPR_Policy Thanks, --David ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
