Re: Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback
Hannes, None of the current OAuth WG document address discovery in any way, so clearly there will be no use of XRD. But the OAuth community predating the IETF had multiple proposals for it. In addition, multiple times on the IETF OAuth WG list, people have suggested using host-meta and XRD for discovery purposes. The idea that XRD was reused without merit is both misleading and mean-spirited. Personally, I'm sick of it, especially coming from standards professionals. XRD was largely developed by the same people who worked on host-meta. XRD predated host-meta and was designed to cover the wider use case. Host-meta was an important use case when developing XRD in its final few months. It was done in OASIS out of respect to proper standards process in which the body that originated a work (XRDS) gets to keep it. I challenge anyone to find any faults with the IPR policy or process used to develop host-meta in OASIS. XRD is one of the simplest XML formats I have seen. I bet most of the people bashing it now have never bothered to read it. At least some of these people have been personally invited by me to comment on XRD while it was still in development and chose to dismiss it. XRD was designed in a very open process with plenty of community feedback and it was significantly simplified based on that feedback. In addition, host-meta further simplifies it by profiling it down, removing some of the more complex elements like Subject and Alias (which are very useful in other contexts). XRD is nothing more than a cleaner version of HTML LINK elements with literally a handful of new elements based on well defined and widely supported requirements. It's entire semantic meaning is based on the IETF Link relation registry RFC. There is something very disturbing going on these days in how people treat XML-based formats, especially form OASIS. When host-meta's predecessor - side–meta – was originally proposed a few years ago, Mark Nottingham proposed an XML format not that different from XRD. There is nothing wrong with JSON taking over as a simpler alternative. I personally prefer JSON much better. But it would be reckless and counter productive to ignore a decade of work on XML formats just because it is no longer cool. Feels like we back in high school. If you have technical arguments against host-meta, please share. But if your objections are based on changing trends, dislike of XML or anything OASIS, grow up. EHL From: Hannes Tschofenig hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net Date: Sun, 3 Jul 2011 00:36:29 -0700 To: Mark Nottingham m...@mnot.netmailto:m...@mnot.net Cc: Hannes Tschofenig hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net, ietf@ietf.orgmailto:ietf@ietf.org IETF ietf@ietf.orgmailto:ietf@ietf.org, Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, oauth WG oa...@ietf.orgmailto:oa...@ietf.org Subject: Re: Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback I also never really understood why XRD was re-used. Btw, XRD is not used by any of the current OAuth WG documents, see http://datatracker.ietf.org/wg/oauth/ On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote: * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred by WS-*, but it seems very over-engineered for what it does. I understand that the communities had reasons for using it to leverage an existing user base for their specific user cases, but I don't see any reason to generalise such a beast into a generic mechanism. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Motivation to submit an idea in IETF?
The IETF, like any other standard body, isn't about publishing idea or inventing things, but all about enabling interoperability between discrete implementations and parties. Patents do not enable interoperability on their own because of their nature and limitations (at least in the US). However, patents are often involved when engineering interop solutions. The questions you have to ask yourself are: Are you looking to create a new market? Is this market more likely to succeed if it is open for all and free to participate or fee-based? Are you going to make a greater profit in an open (bigger) market or in a closed (usually smaller) market? EHL On 1/21/10 4:57 PM, Abhishek Verma abhishekv.ve...@gmail.com wrote: Hi, I have a basic question relating to patents and IETF. Assume that i have a nifty idea on how i can speed up, lets say, a database exchange in OSPF. My doubt is that why should i submit an IETF draft describing this, which can later become an RFC, when i can very well patent this idea? I understand that if i submit this to IETF, then there will be an RFC and all vendors will come out with inter-operable implementations. However, if i dont give it to IETF and rather submit a patent, i can do very well for the vendor that i work for. All customers using this vendor's boxes will now have access to patented database exchange in OSPF, which will effectively mean more business for this vendor. So, the question is, what is the motivation for somebody to write an internet-draft when the person can file a patent? I spoke to several people offline and i couldnt get any good answers. The typical response was that most ISPs prefer multiple vendors, and a patented solution will cause issues as the other vendor will not have that support. Is this the only reason? Thanks, Abhishek ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
I am supportive of updating *a* registry. The OAuth working group has an open requirement for standard identifiers to describe hash/digest functions. What is not clear to me is the relationship of this registry and: http://www.iana.org/assignments/hash-function-text-names/ which seems to overlap. I am not sure why we need both, and if we do (because they are protocol specific and required for interoperability), how should a new specification decide which to use or if a new registry is required. For example my uneducated reading of 4572 suggests it is not exactly the same use case as the previous RFCs using that registry. In addition, using different tokens for the same algorithm across protocols seems like a bad idea (lower case, upper case, SHA vs sha-1). And since both include MD5... arguments about appropriate hash algorithm to increase security fail. EHL -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: Friday, December 04, 2009 6:44 AM To: IETF-Announce Subject: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Additional Hash Algorithms for HTTP Instance Digests ' draft-bryan-http-digest-algorithm-values-update-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-01-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm- values-update-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag= 19094rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
This raises the obvious question - shouldn't we take greater action than simply update one of them? Should we consider combining them? Perhaps update the reason why we have them and make them more useful for other use cases? I am just looking for clarifications. EHL -Original Message- From: Anthony Bryan [mailto:anthonybr...@gmail.com] Sent: Friday, December 04, 2009 5:21 PM To: Eran Hammer-Lahav Cc: ietf@ietf.org; HTTP Working Group (ietf-http...@w3.org) Subject: Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC Eran, to my knowledge there is no relationship between the two registries, besides some overlap. The registry you mention appears to be just hash function names and references a few X.509 RFCs. I don't know about the history but it seems to be a more generic list. (We reference that registry in draft-bryan-metalink). Here is the registry draft-bryan-http-digest-algorithm-values-update would update: Hypertext Transfer Protocol (HTTP) Digest Algorithm Values http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml RFC 3230, which created this registry, doesn't refer to it by name, which isn't too helpful in finding it. The algorithms haven't been updated, so the newest entry is SHA, and some other references were inconsistent (different base64 RFCs) and outdated (SHA), which this draft fixes. It also includes values which are not in the other registry: UNIXsum, UNIXcksum. All digest-algorithm values are case- insensitive. (We also reference this registry in draft-bryan-metalinkhttp). I agree, SHA vs sha-1 in the registries could be confusing but both these registries have co-existed for 7 years. I don't know how much either has been used in practice, besides our 2 drafts. On Fri, Dec 4, 2009 at 12:42 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: I am supportive of updating *a* registry. The OAuth working group has an open requirement for standard identifiers to describe hash/digest functions. What is not clear to me is the relationship of this registry and: http://www.iana.org/assignments/hash-function-text-names/ which seems to overlap. I am not sure why we need both, and if we do (because they are protocol specific and required for interoperability), how should a new specification decide which to use or if a new registry is required. For example my uneducated reading of 4572 suggests it is not exactly the same use case as the previous RFCs using that registry. In addition, using different tokens for the same algorithm across protocols seems like a bad idea (lower case, upper case, SHA vs sha-1). And since both include MD5... arguments about appropriate hash algorithm to increase security fail. EHL -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: Friday, December 04, 2009 6:44 AM To: IETF-Announce Subject: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Additional Hash Algorithms for HTTP Instance Digests ' draft-bryan-http-digest-algorithm-values-update-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-01-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm - values-update-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddT ag= 19094rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Regarding RIM's recent IPR disclosures
Is every single RIM employee going to send this to the list? EHL From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Andrew Allen Sent: Thursday, November 19, 2009 6:11 PM To: ietf@ietf.org Subject: Regarding RIM's recent IPR disclosures With regard to the recent discussion on the IETF-Discussion list regarding RIM's recent IPR disclosures, I understand the community's concerns regarding the timeliness of the disclosure. As I'm sure everyone can understand, as employees of companies we are bound by confidentiality obligations and, in addition, cannot always control our company's internal processes. The community's concerns have been brought to the attention of my employer and they are in the process of evaluating the concerns. My company has asked for your patience while they take the time to evaluate the concerns and determine if there is an appropriate course of action in this matter to alleviate the concerns of the community. Your understanding is appreciated Best regards Andrew Allen Manager Standards Research In Motion Ltd Office +1 847-793-0861 x20824 BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-hammer-oauth (The OAuth Core 1.0 Protocol) to Informational RFC
This draft is the original community specification created outside the IETF. It was this work that inspired the creation of the OAUTH WG and is explicitly set as the initial draft for the WG in its charter. The draft is submitted as an informational RFC to document existing deployment and practices. It is not a WG product. EHL -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, October 27, 2009 7:12 AM To: IESG IESG Cc: IETF Discussion Subject: Re: Last Call: draft-hammer-oauth (The OAuth Core 1.0 Protocol) to Informational RFC I'm very confused about the relationship of this draft and the work the OAUTH WG is doing. Can you explain? On Oct 9, 2009, at 15:38 , The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The OAuth Core 1.0 Protocol ' draft-hammer-oauth-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hammer-oauth-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag =17736rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [IAOC] Request for community guidance on issue concerning a future meeting of the IETF
If by engage you mean continue to discuss the terms of having a meeting in China, then I agree. If the government there really wants to host an IETF meeting, they should be able to help changes these terms to focus on individuals and not the entire event or organization. But to suggest that without holding a meeting in China the IETF does not engage its Chinese members, that is simply false. Personally, I doubt I will be attending a meeting in China. Not because of any political reasons, but simply because the cost of such a meeting compared to the value it brings my employer (that is attending a meeting, not general IETF participation). My concerns are having access to the meeting via IRC and voice streams and not having to worry about where the meeting it taking place. I think bad behavior is more likely from people participating from outside China than at the event. And if all it takes to shut down such channels is someone saying something about Tibet on the IRC channel, then that's simply not acceptable. EHL -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Marshall Eubanks Sent: Saturday, September 19, 2009 3:17 PM To: Steve Crocker Cc: IAOC IAOC; IETF Discussion Subject: Re: [IAOC] Request for community guidance on issue concerning a future meeting of the IETF Speaking just for myself, I agree with Steve. I think it that is better to engage than to retreat. Nothing is certain, but I also think that it is highly likely that we would have a good meeting. Regards Marshall On Sep 19, 2009, at 3:55 PM, Steve Crocker wrote: The choice is between engaging and not engaging. Engaging is better. Not engaging isn't constructive. The Internet and the IETF are all about engaging, expanding, communicating and being open. Much of this dialog has been worried about possible extreme situations. Let's focus on the center. More than a billion people live in China and their use of the Internet is expanding rapidly. They are building much of the technology and contributing technically. It's to everyone's advantage to have comfortable, constructive interaction. Our first slogan was Networks Bring People Together. If you prefer to focus on the negatives, here's my analysis: If we don't go to China, we have charted a downhill course and the rest of the world will come together without us. The IETF will lose relevance. If we do go to China and something bad happens, the consequences will be much worse for China than for the IETF. The work of the IETF will suffer a bit, but we'll recover quickly enough. However, China's quest for engagement with the rest of the world will be hurt more seriously. Bottom line: We should go to China with a positive attitude. We're robust enough to deal with any consequences. If we don't go to China, however, we have weakened ourselves. Steve ___ IAOC mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/iaoc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Does being an RFC mean anything?
If someone fails to read the front page of an RFC which clearly states what that document is and is not, that is their problem. There is no excuse for stupidity or laziness. There is a real problem with people thinking that RFC == Free License. We need to educate people and maybe consider new ways to get that message out. But it has nothing to do with the status of the document. The purpose of RFCs is in the *name*: Request For Comments. How much more clear can you get? It is a memo publication channel for documents related to internet technologies. It is a way for people to communicate ideas and preserve them. Standards are just a small part of it. There is no connection between the document status (standard, info, experimental, etc.) to its IPR status. Yes, most standards tend to be free, but that is still a document by document distinction. And to argue that it is different elsewhere is wrong. For example, OASIS has plenty of standards that are not free. I am willing to bet that there are more fee-based licensed standards in the world than free ones. You have to understand the wide range of topics discussed in the IETF and the fact that a lot of it might be of no consequences to open source developers. It is not the job of the IETF to fight against the patent system. What we need to make sure is that the communities creating standards ensure that their expected audience can implement it. If you don't understand how something works, saying its broken is the lazy way out. Should we do a better job educating people about the IPR consequences of using RFCs? Of course! Should we make it harder for encumbered tech to make it into standards? Hell yeah! But we need to solve the problem where it belongs. As for TSG's comments: show me an organization this size that doesn't have people who worry more about their ass than the community they are in. You comment makes as much sense as saying that you would not vote for president because politics is dirty and all about self promotion. Grow up. EHL On 3/11/09 3:54 PM, TSG tglas...@earthlink.net wrote: Lawrence Rosen wrote: Because Larry - many of those here owe their ongoing $$$ livelihood to the lie the IETF has become. And so what you are suggesting is increasing the rolls of the unemployed by adding these individuals who's whole existence is the IETF. Its also these people in my opinion that make the IETF the laughingstock its become as you so rights notice that RFC's and the process for creating standards has degraded into a model where there really is no standard. Just my two cents Todd Glassey The recent threads about draft-housley-tls-authz have taught me something I didn't know about IETF, and I don't like what I've learned. There are, it appears, many types of IETF RFCs, some which are intended to be called Internet standards and others which bear other embedded labels and descriptions in their boilerplate text that are merely experimental or informational or perhaps simply proposed standard. One contributor here described the RFC series as a repository of technical information [that] will be around when I am no longer around. The world is now full of standards organizations that treat their works as more significant than merely technical information. Why do we need IETF for that purpose? If all we need is a repository of technical information, let's just ask Google and Yahoo to build it for us. Maybe our Internet standards should instead be created in an organized body that pays serious attention to the ability of the wide world to implement those standards without patent encumbrances. But even if IETF isn't willing to amend its patent policy that far-and most SDOs still aren't, unfortunately-at the very least we should take our work seriously. When someone proposes a serious RFC, we should demand that the water around that RFC be swept for mines-especially **disclosed** patent mines that any serious sailor would want to understand first. If IETF isn't willing to be that serious, maybe we should recommend that our work go to standards organizations that do care? As far as my time to volunteer for a better Internet, there are far better ways to do it than listening here to proposals that are merely technical information. At the very least, separate that into a different list than IETF.org so I know what to ignore! By the way, many of the same companies and individuals who are involved here in IETF are also active participants in W3C, OASIS, and the new Open Web Foundation, all of which organizations pay more attention to patents and the concept of open standards than what IETF seems to be doing here. So let's not be disingenuous, please. Almost everyone here has previous experience doing this the right way. /Larry Lawrence Rosen Rosenlaw Einschlag, a technology law firm (www.rosenlaw.com http://www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell:
RE: Does being an RFC mean anything?
-Original Message- From: Mohsen BANAN [mailto:lists-i...@mohsen.banan.1.byname.net] Sent: Wednesday, March 11, 2009 6:01 PM On Wed, 11 Mar 2009 17:31:27 -0700, Eran Hammer-Lahav e...@hueniverse.com said: Eran There is no connection between the document status (standard, info, Eran experimental, etc.) to its IPR status. You are dead wrong. See Section 10.3.2 of RFC-2026. If you are going to use strong language, you should at least make sure you are not contradicting yourself. There is no connection between the document status to its IPR status. Any of the document types can have any IPR status. The only thing the section you referenced says in relation to this discussion is that if a disclosure is made, the IETF has to attempt to obtain a RAND license and either way, has to document the result of this effort. Note that after 13 years RFC-2026 -- The Internet Standards Process -- Revision 3 October 1996 is still the latest. In other words, despite knowing about severe process problems nothing has been done for 13 years. As I said before, the real problem is that even RFC-2026 is mostly imaginary and that IETF has become a cult dominated by interests of proprietary big business. As we are seeing. My work obtaining licenses for open community specs and my role in the Open Web Foundation is all based on the view that standards should be free and unencumbered. There is nothing to prevent working groups from rejecting encumbered contribution or technology by consensus. Since the IETF process is completely open, it is easy for a committed community to make sure the right thing is done. In addition, while the IETF process has indeed failed to catch-up with the time, the community around it is getting pretty sophisticated. The recent work of the FSF (no matter how misguided) is proof that the little guy still has a voice here. The entire IETF process depends on community consensus. There is no reason to significantly alter the culture and openness of this organization for something that can be accomplished via other means. Big companies with deep pockets will find new avenues for their work if they don't like the way things are going on. There are many known examples of work leaving W3C to OASIS, etc. because some companies didn't like the terms. But the real damage is that the more strict the policy is, and the more rigid the process is, the less likely are people to participate. We all have jobs and employers and in most cases they control our IP and ability to participate in any such process. People come to the IETF because this is where the knowledge is. This is where the experience is for many internet technologies. The IETF does not have the power or means to stop anyone from changing their work or proposing competing standards. What it has is the voice of a community that still matters more than many. I have a lot of criticism for the IETF IPR process, or complete lack of meaningful protections. But I don't go around pointing fingers and make up conspiracy theories. I just talk to people, bring small and big players to the table, and try to be creative about it. And guess what, people are actually listening to what we are doing in the OWF. If you think I am full of it, just wait a year or two and let's talk again then. EHL ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
When you say IETF RFC, do you also include RFC-Editor track informational RFCs? EHL On 3/10/09 3:08 PM, Lawrence Rosen lro...@rosenlaw.com wrote: Phillip Hallam-Baker wrote: Institute the policy as you suggest and you have just given the patent trolls the power to place an indefinite hold on any IETF proposal. I have never suggested placing any kind of hold on any IETF proposal. Propose all you want. Publish the proposal. Try to convince people that it is a good proposal. Establish a WG to design away An IPR Disclosure has been filed in accordance with standard IETF procedure. What I've suggested is due diligence to determine the implications of that disclosure. Only THEN is publication as an IETF RFC justified. Experimental or not, industry standard or not, an IETF RFC encourages companies to implement and use the technology, and that may be patent infringement. Or it may be a bogus IPR disclosure that intelligent people could decide to ignore. I am certainly not giving patent trolls any more power than they deserve. In fact, I hope to dispose of this particular TLS patent troll once we get a small group of patent attorneys to analyze the IPR disclosure like professionals do it. Just like W3C does it. They don't give patent trolls power either. /Larry -Original Message- From: Hallam-Baker, Phillip [mailto:pba...@verisign.com] Sent: Tuesday, March 10, 2009 1:24 PM To: lro...@rosenlaw.com; Paul Hoffman; ietf@ietf.org Subject: RE: Consensus Call for draft-housley-tls-authz Institute the policy as you suggest and you have just given the patent trolls the power to place an indefinite hold on any IETF proposal. So instead of extorting payment for exercise of the claims they hold the standard hostage. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Lawrence Rosen Sent: Tuesday, March 10, 2009 3:28 PM To: 'Paul Hoffman'; ietf@ietf.org Subject: RE: Consensus Call for draft-housley-tls-authz Lawrence Rosen wrote: If we use different terminology to identify this IETF RFC, how does that change anything? Paul Hoffman replied: Because you earlier complained about IETF standards having known patent issues. Now we are talking about experimental protocols that are not standards. And I am saying that it doesn't make a bit of difference legally. If you infringe for experimental reasons, that is still infringement. I don't think we should publish under the IETF imprimatur if there are *unresolved* known patent issues about which ignorant and cautious people continue to speculate blindly. Why should any of us waste time and money on IETF and commercial and FOSS experiments if they may cost us too much money downstream? Its authors are free to publish draft-housley-tls-authz already. Google is free to index that document already. Why do you insist upon granting it an IETF RFC status without first deciding if the disclosed patent claims are likely bogus? /Larry -Original Message- From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] Sent: Tuesday, March 10, 2009 10:31 AM To: lro...@rosenlaw.com; ietf@ietf.org Subject: RE: Consensus Call for draft-housley-tls-authz At 10:22 AM -0700 3/10/09, Lawrence Rosen wrote: If we use different terminology to identify this IETF RFC, how does that change anything? Because you earlier complained about IETF standards having known patent issues. Now we are talking about experimental protocols that are not standards. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Internet Society joins Liberty Alliance Management Board: Why?
My concern regarding this announcement is the fact that it gives support to a misguided effort by Liberty Alliance. I think it is somewhat irresponsible for the ISOC to actively support an effort without first engaging the community at large to fully understand the dynamics of the identity communities involved. The people behind the IDtbd effort have been going around trying to sell this effort for a while. The reality is that at this point, the communities behind two of the most successful identity related protocols, OAuth and OpenID, have rejected this effort by Liberty, including many of the individual companies that support these communities. I find it personally offensive that Liberty have been going behind the OAuth's community's back trying get corporations to move their OAuth and OpenID efforts to IDtbd instead of the communities that drive these efforts forward. IDtbd is an effort to create a full-blown standard body to manage all identity related protocols, with its own set of IPR rules, process, and governance. They seek to nullify existing communities by positioning themselves as the authority in the space. Supporting this effort directly contradicts the current IETF effort to form an OAuth working group. EHL ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
