Re: Diagrams (Was RFCs should be distributed in XML)
IMHO, standardizing on _validated_ SVG with a library of well understood images that represented architectural components with attached semantics could be used to even start validating diagrams the same way we validate BNFs now. There are even UML to SVG tools for turning SVG drawings directly into code. And there are lots of free SVG tools -MM Steve Crocker wrote: The issue of diagrams is entangled in the long-standing discussion of proprietary formats. There is a huge benefit in having a format that *everyone* can access without difficulty or cost. I can't begin to tell you the impact I felt when I walked into a university half way around the world in an underdeveloped country and had a graduate student show me some pretty sophisticated stuff he had done based on RFCs he had downloaded from the net. ASCII is an enormous advantage from that respect. -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Reexamining premises (was Re: UN plans to take over our job!)
> Might I suggest all participants in this discussion figure out what you really want to use DNS for if you were to assume it didn't exist in the first place. Imagine going back in time to 1986 and explaining to everyone at the IETF the way things would develop and then, after they've stopped laughing, imagine what kind of system would have resulted. My personal suspicion is that two things would be very different: There wouldn't be one monolithic namespace/protocol/system. At least two systems would exist: one for hiding IP network layer topology from apps and another for describing and naming services for end users. The system that faced the users would be inherently trademark friendly and wouln't be hierarchical. The output of such a system wouldn't be an IP address but instead a complex record that described a compound object called a 'service'. It might be what people today call "peer to peer" (although I have yet to find a good definition of what that means) but that might not be an issue since the names wouldn't be hierarchical. What I find humorous is that this community's default position seems to be to attempt to play politics with those who are professionals at it rather than solving the problems with technology which is what you'd think we're good at -MM /me goes back to building rockets which is much more fun... -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reexamining premises (was Re: UN plans to take over our job!)
Anthony G. Atkielski wrote: Michael Mealling writes: As the result of a service lookup they only need something that identifies the class and subclass of the service the URI is an identifier for... What's wrong with "http" at the front, and/or a port number at the back? Those are network concepts. The "service" I'm talking about has to do with the task the user is actually attempting to accomplish. http://foo.com:1235/bla.php Tells me nothing about whether I can use that for the "I want the current weather report" service or if its a DAV entry point for doing collaborative document management That's my last one on this thread. I'm not in this business anymore -MM -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reexamining premises (was Re: UN plans to take over our job!)
Anthony G. Atkielski wrote: Michael Mealling writes: Well, I didn't want to get into specifics but from what I've seen a URI with a service identifier tag seems to be fine for everyone that has looked a the problem So you shouldn't be nervous, the web seems to be working just fine What do URIs not have now that they need? As the result of a service lookup they only need something that identifies the class and subclass of the service the URI is an identifier for... See the various specs that use NAPTR records for some examples of how the Service field is used... -MM -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reexamining premises (was Re: UN plans to take over our job!)
Anthony G. Atkielski wrote: Michael Mealling writes: To get specific for a moment, my suggestion here is that the IETF take a look at what the W3C and the general web community is doing around navigation, tagging (see Technorati, del.icio.us, flickr), advances in NLP that Google is working on, etc. Perhaps the solution is to tell the world that DNS isn't really meant for your grandmother or your favorite polititicain and instead we're going to do something at the web layer that's more in tune with how people are actually using the Internet, not how mail gets routed Do it with telephones first, as a proof of concept. If there's still a usable telephone network after that, then perhaps it might be worthy of consideration for the Internet. Being one of the co-authors of the ENUM spec, I've actually paid attention to how that's all working out. Have you checked into how Skype and VOIP in general are working internationally lately? Not an E.164 phone number anywhere in the entire thing. Its all identifiers that look like AOL screen names and peering agreements. And it seems to be working out just fine.... -MM -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reexamining premises (was Re: UN plans to take over our job!)
Anthony G. Atkielski wrote: Michael Mealling writes: The system that faced the users would be inherently trademark friendly and wouln't be hierarchical. There are lots of users of the Internet besides trademark holders. I don't see why this latter group deserves special consideration. Because, particular codifications of it in the law aside, it represents a pretty good description of how human beings cognitively use names and words. It has many centuries of operational experience and it apparently works for everything humans need it to. But for some reason those of us who designed the Internet seem to think we're above all of that and can dictate a system to the end users that's dissonate with how they actually think and view the world. The output of such a system wouldn't be an IP address but instead a complex record that described a compound object called a 'service'. I always get nervous when I hear talk like this. I can picture the 5000-page committee-designed specification already. Well, I didn't want to get into specifics but from what I've seen a URI with a service identifier tag seems to be fine for everyone that has looked a the problem So you shouldn't be nervous, the web seems to be working just fine -MM -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reexamining premises (was Re: UN plans to take over our job!)
Anthony G. Atkielski wrote: Michael Mealling writes: Again, you're conflating two different services that should be... Which is my point. Look at the problem from a purely requirements point of view and ignore what's been done to date. Look at the problem from an implementation point of view and remain realistic as to what is possible if one wants any semblance of order and performance. I have. As have others. See the following: draft-daigle-iris-slsreg-00.txt draft-hollenbeck-epp-sls-00.txt All very deployable and rather easy to build and setup... Reexamine the premises Don't fix what isn't broken. Well, given the origin of this thread, there are large numbers of users who consider the current system to be broken. And they have money and power so they're going to find a solution. The question is whether this organization is going to be involved in that answer or not. You can either sit back and feel smug about thinking your solution is right or you can address the perceived problems of the users and provide them with technical solutions to it -MM -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reexamining premises (was Re: UN plans to take over our job!)
Hallam-Baker, Phillip wrote: Beyond that, the mapping should be under control of the appropriate party. I don't want the moral equivalent to "Google-bombing" to be able to divert, say, my incoming mail. I don't think that this is what Michael was suggesting. His point as I understand it is that DNS is designed to resolve a name to a machine rather than a name,service pair to a machine. Sort of. What I was trying to get at was that DNS is designed to resolve an identifier to a machine for consumption by computer programs, not as a human factors component of a user facing system capable of helping humans get things done that humans care about. Its the difference between forcing my grandmother to learn SQL to do a search and giving her "Ask Jeeves". To get specific for a moment, my suggestion here is that the IETF take a look at what the W3C and the general web community is doing around navigation, tagging (see Technorati, del.icio.us, flickr), advances in NLP that Google is working on, etc. Perhaps the solution is to tell the world that DNS isn't really meant for your grandmother or your favorite polititicain and instead we're going to do something at the web layer that's more in tune with how people are actually using the Internet, not how mail gets routed And maybe that work doesn't belong here -MM -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reexamining premises (was Re: UN plans to take over our job!)
Steven M. Bellovin wrote: In message <[EMAIL PROTECTED]>, Michael Mealling writes: Steven M. Bellovin wrote: Reexamine the premises I am -- these are my premises. I lived far too long in the uucp world to enjoy non-unique names; they led to nothing but trouble. Again you're talking about mail routing and addressing mechanisms when the people that use DNS in their web browser are looking for a smart search interface that understands better what they're after and why. Why do those two applications have to use the same addressing scheme? Many of the political problems with DNS have nothing to do with routing email and have everything to do with the fact that its what your grandmother is using as an interface. Some of the other requirements are security requirements, and that's what I do for a living. Sure security requires a level of exactness that you shouldn't burden the user with or else he won't use the system I agree that the current DNS has serious problems, most notably in the trademark sphere. That doesn't mean that its other premises are wrong; there are other navigational systems that yield unique results besides treees. And what I'm suggesting is that uniqueness is a requirement of networks and system, not people. The issues the UN has with the way DNS is run have to do with the fact that you're trying to apply a requirement of the network to society and that creates problems. IMHO, we should look at building a system that works the way people use identifiers and identity and then get that to work with the existing network we have. -MM -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reexamining premises (was Re: UN plans to take over our job!)
Steven M. Bellovin wrote: There are several crucial attributes that are hard to replicate that way. One is uniqueness: whenever I do a query for a name, I get back exactly one answer, and it's the same answer everyone else should get. You're making assumptions that its one system. No other medium requires uniqueness for the names _people_ use. You and I are perfectly capable of understanding that there might be two Steven Bellovins in the world. Its the email routing system that requires uniqueness. There is no reason why the addresses that system uses need to be remotely understandable by humans. The identifier I use to look you up and be able to differentiate you from someone else would be run completely differently from the addressing system used to route a message through a store and forward network. This is the problem with "alternate" roots -- depending on where you are, you can get a different answer. It's also what differentiates it from a search engine -- my applications don't know how to make choices. And conflating all of that into one system is the problem. Take those things that humans use and separate them from those things that computers and networks need to get things done. Don't burden people with the uniqueness requirement when that's not the way they expect the world to work and don't burden the network with having to differentiate badly between service behaviors given nothing but an IP address and a port number. Beyond that, the mapping should be under control of the appropriate party. I don't want the moral equivalent to "Google-bombing" to be able to divert, say, my incoming mail. Again, you're conflating two different services that should be... Which is my point. Look at the problem from a purely requirements point of view and ignore what's been done to date. Finally, you need locality: people within an organization must be able to create their own names. Yep. It may be that some of these requiremets are fundamentally at odds with the notion of full decentralization. If you try and shove it all in one system, sure The addressing requirements of IP addresses and SMTP addresses are different and probably "fundamentally at odds with each other". Does that mean you still force both to use something that doesn't satisfy either system? No Reexamine the premises -MM -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Reexamining premises (was Re: UN plans to take over our job!)
Might I suggest all participants in this discussion figure out what you really want to use DNS for if you were to assume it didn't exist in the first place. Imagine going back in time to 1986 and explaining to everyone at the IETF the way things would develop and then, after they've stopped laughing, imagine what kind of system would have resulted. My personal suspicion is that two things would be very different: There wouldn't be one monolithic namespace/protocol/system. At least two systems would exist: one for hiding IP network layer topology from apps and another for describing and naming services for end users. The system that faced the users would be inherently trademark friendly and wouln't be hierarchical. The output of such a system wouldn't be an IP address but instead a complex record that described a compound object called a 'service'. It might be what people today call "peer to peer" (although I have yet to find a good definition of what that means) but that might not be an issue since the names wouldn't be hierarchical. What I find humorous is that this community's default position seems to be to attempt to play politics with those who are professionals at it rather than solving the problems with technology which is what you'd think we're good at -MM /me goes back to building rockets which is much more fun... -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[Fwd: TAG announces Last Call review of Architecture Document]
-Forwarded Message- From: Ian B. Jacobs <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: TAG announces Last Call review of Architecture Document Date: 09 Dec 2003 18:14:09 -0500 Dear www-tag, Below is a copy of the email I just sent to the W3C Chairs announcing the Last Call of the Architecture Document. The TAG looks forward to your reviews! _ Ian = On behalf of the Technical Architecture Group (TAG) [1], I am pleased to announce the publication of the 9 December 2003 "Architecture of the World Wide Web, First Edition" Last Call Working Draft. The document is available at: http://www.w3.org/TR/2003/WD-webarch-20031209/ Review end date: 5 March 2004 Mailing list : [EMAIL PROTECTED] (archive [2]) The TAG has scheduled an extended Last Call review period so that groups inside and outside of W3C have sufficient time to read and review this document. The review period will remain open through the W3C Technical Plenary Week 2004, where the TAG expects to meet with some of the Working Groups named below. Please find below the following information: * Which groups should review this document * Decision to advance to Last Call * Issues the TAG has addressed in the First Edition * Patent disclosures * The abstract and status section For more information on the purpose of a Last Call review, please consult section 7.4.2 of the W3C Process Document [3]. The TAG looks forward to your review comments, For Tim Berners-Lee, TAG co-Chair, and Stuart Williams, TAG co-Chair, Ian Jacobs, Architecture Document Editor [1] http://www.w3.org/2001/tag/ [2] http://lists.w3.org/Archives/Public/public-webarch-comments/ [3] http://www.w3.org/2003/06/Process-20030618/tr.html#last-call Which groups should review this document The intended audience for the document includes: 1. Participants in W3C Activities; i.e., developers of Web technologies and specifications in W3C, 2. Other groups and individuals developing technologies to be integrated into the Web, 3. Implementers of W3C specifications, 4. Web content authors and publishers. The TAG welcomes review from all interested parties. In particular, we request review from the following W3C groups: HTML WG [Steven Pemberton, Chair] Internationalization WG/IG [Addison Phillips, Chair] RDF Core WG [Dan Brickley, Brian McBride co-Chairs] SVG WG [Chris Lilley, Chair] XML Core WG [Paul Grosso, Norm Walsh co-Chairs] XML Schema WG [Michael Sperberg-McQueen, Dave Hollander, co-Chairs] Web Ontology WG [Jim Hendler, Guus Schreiber, co-Chairs] Web Services Description WG [Jonathan Marsh, Chair] Voice Browser WG[Jim Larson, Scott McGlashan co-Chairs] The Chairs of some of these groups have already confirmed with the TAG their intent to review the document. For other groups, the W3C Director will appreciate a response (sent to [EMAIL PROTECTED]) with or without review comments. = Decision to advance to Last Call = The TAG decided unanimously to advance to Last Call at their 4 Dec 2003 teleconference: http://www.w3.org/2003/12/04-tag-summary#lcdecision If the Last Call review is positive, the TAG expects to request to advance directly to Proposed Recommendation. = Issues the TAG has addressed in the First Edition = The TAG charter [4] describes a process for issue resolution by the TAG. In accordance with those provisions, the TAG maintains a running issues list [5]. The First Edition of "Architecture of the World Wide Web" does not address every issue that the TAG has accepted since it began work in January 2002. The TAG has selected a subset of issues that the First Edition does address to the satisfaction of the TAG; those issues are identified in the TAG's issues list. The TAG intends to address the remaining (and future) issues after publication of the First Edition as a Recommendation. [4] http://www.w3.org/2001/07/19-tag [5] http://www.w3.org/2001/tag/issues.html == Patent disclosures == There are currently no patent disclosures regarding "Architecture of the World Wide Web, First Edition" Patent disclosures regarding this document are listed here: http://www.w3.org/2001/tag/disclosures = Abstract of Architecture Document = The World Wide Web is a network-spanning information space of resources interconnected by links. This information space is the basis of, and is shared
Re: RFID and EPCglobal
On Thu, 2003-11-20 at 10:52, Richard Shockey wrote: > EPCglobal is focusing on the standards though I suspect there are aspects > of the protocols being discussed that should come to the IETF or IEEE for > proper peer review and/or standardization. There is an extensive discussion > of the use of the DNS and NAPTR RR's in the ONS specification. Being involved in those I can attest to the fact that no one is developing new protocols where they're not needed. So in effect the protocols being used have already been peer reviewed since those protocols were actually developed by other standards bodies -MM
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Wed, 2003-03-26 at 16:38, Tony Hain wrote: > Ted Hardie wrote: > > I think you may underestimate how much trouble this might cause in > > applications. > > As Dave Crocker noted in response to Margaret Wasserman's > > presentation to the APPs Open Area meeting, applications have > > been designed so that > > they > > do not know and don't need to know anything about network > > topology. > > If you > > require applications to understand the consequences of different > > unicast address > > scopes, you are changing a pretty fundamental assumption. > > While it is > > theoretically > > possible to change that assumption, it is a major piece of > > work, and I > > believe that > > the "sense of the room" was that the advantages of Site Local > > were not > > worth that > > amount of work. > > I am not arguing that every app need to know about topology. If this is > such a big deal, we should simply fix the API so that by default it only > returns global scope addresses, then add a new function for those apps > that are interested in the limited scope. This doesn't sound like rocket > science, and the arguments against it are coming across like 'we don't > want to change because it is too much work'. Rather than argue that > nobody can ever use a new feature, the basic approach should be that you > don't have to unless you want to. > Its not that 'we don't want to change because its to much work'. Its that the Internet architecture assured us that the hour glass model applied, that the network topology would remain abstracted within what to us is an opaque address space. One of the number one reasons its so easy for new application layer technologies to be deployed is that a developer doesn't need to know or care about any layer below TCP (or, in rare cases, UDP). If the lower layers want to change that hour glass model then we're talking about a serious breach of contract with the layers above it and a dangerous blow to the hour glass model. -MM
the 'hallway' jabber group chat
Just on a lark I tried creating a new chatgroup on conference.ietf.jabber.com called 'hallway' and apparently it worked. It seems that if we're going to create an chat equivalent of the working group meetings that we should extend the metaphor to include the other aspects of the week that facilitate the process Right now I'm the only one in the 'hallway'. ;-) -MM
Re: taking MARTA from airport to IETF55 hotel
On Wed, 2002-11-13 at 23:49, Michael Richardson wrote: > I arrived today and made some minor notes that might be of use to others. > (I've been to Atlanta many times for N+I, but always wind up having to > stay up in Buckhead, so taking the MARTA has become routine on visits to > Atlanta). > > In my moderate experience, Atlanta has the third best train link to the > airport. First is Zurich. Then Washington National, then Atlanta. I've > yet to do other than change planes in Amsterdam, and the EWR->NJ-Transit > link was not finished last I was there, so my rankings may change. > Just a word of warning: While MARTA may be great for getting from the airport to the hotel, that's about all its good for. Don't get here and expect something like DC or Boston. We're a car town and we like it that way. ;-) MARTA has only two real routes: North/South and East/West. And the busses are just there to annoy the rest of the people on the road. So be warned Plus, I-75/I-85 (or the Connector as its called) should be low traffic on the weekend unless someone's jack-knifed a 18-wheeler... -MM -- Michael Mealling <[EMAIL PROTECTED]> HHI, Inc.
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 04:36:22PM -0400, Clark C . Evans wrote: > On Thu, Jul 25, 2002 at 03:48:29PM -0400, Michael Mealling wrote: > | > > | >urn:dns:com.clarkevans:MyPackage > | > > | > Where the first three components are always small caps. > | > | The problem is that URNs are required to be non-reasignable. So if > | the part between the second and third colons is based off of a domain-name > | then you will have to timestamp it somehow. > > Ok, would this fly? > > urn:dns:yaml.clarkevans.com,2002;MyPackage > > Thank you both for humoring me. YAML needs something clean > like this for its type identifiers. I would prefer the NID be something other than 'dns'. As it stands it suggests that it in some way related to DNS when it really isn't except for the firs section. But 'pkg' doesn't seem right either since that suggests Java packages instead of what YAML wants to do with 'em. Got any other suggestions? -MM -- ---- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 03:29:33PM -0400, Clark C . Evans wrote: > On Thu, Jul 25, 2002 at 01:35:08PM -0400, Keith Moore wrote: > | ick. please don't embed URIs in URNs. that will just tempt people > | to use the embedded URIs and not treat them as URNs. > > I'm not set at all on using URIsh syntax. I just thought > it'd be the easiest approach. > > | I can see wanting to have a URN that's based on DNS, but there shouldn't > | be any expectation that you can derive a URI from the URN just by > | modifying the syntax. that defeats the whole purpose. > > Great. So, should this thingy be a URN NID? How about using > reverse DNS, aka Java package names? > >urn:dns:com.clarkevans:MyPackage > > Where the first three components are always small caps. The problem is that URNs are required to be non-reasignable. So if the part between the second and third colons is based off of a domain-name then you will have to timestamp it somehow. -MM -- -------- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 11:48:27AM -0400, Clark C . Evans wrote: > I'm looking for a URN scheme that uses DNS for uniqueness (perhaps in > conjunction with a date) but doesn't have any attached semantics. I'm > asking this beacuse XML has the "duck" problem. It uses URIs for > namespace names, but only the URI syntax (for uniqueness), thus you see > lots of http:// namespace names but the author never intended to support > the retrieval of content given the namespace name. Anyway, this is icky. > What XML really wanted was a URN that is based on DNS. As it turns out > YAML (http://yaml.org) has exactly the same situation, only we are in > a position to do this correctly. So, I was thinking something like... > > dnsurn://clarkevans.com/2002/my-data-type#my-format > > Thus, the scheme follows *exactly* the syntax of HTTP (to keep learning > curve down) only that the date is required immediately following the > domain name. The advantage of this over http is that it doesn't look > like a duck... "dnsurn" is not "http". A further advantage is that > someone can use everything to the right of the dnsurn: as a http: URL > if they wish by just replacing the scheme. > > I'm completely dogged for time... if something like this is possible > how hard would it be? I'm not looking forward to having the equivalent > of "XML namespaces considered harmful" threads on our YAML list and > thing something like this would serve to help not only YAML but also > XML... It sounds like you want the 'duri' namespace currently going through the process. It was written by Larry Masinter and is currently here: http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-03.txt The URN is of the form: urn:duri:: Examples: urn:duri:2001:http://www.ietf.org urn:tdb:20010814142327:file://this.example.com/c|/temp/test.txt urn:tdb:2001:data:,The%2520US%2520president etc... -MM -- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
Re: Last Call: An IETF URN Sub-namespace for Registered Protocol Parameters to BCP
On Wed, Jul 03, 2002 at 05:02:11PM -0400, Keith Moore wrote: > Sorry to have not been involved in the disucssion. Vacation and all.. Based on the discussion with Graham I am at a loss as to how to fix the document to satisfy your concerns. It seems that most of your concerns are more to do with the entire W3C promoted web architecture than with anything in particular with this proposal other than the desire for the individual syntactic elements to be as semantically free as possible. Is there anything that can be done to fix this document or are you opposed to even the intended purpose of it? -MM -- ---- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
Re: Last Call: An IETF URN Sub-namespace for Registered Protocol Parameters to BCP
ble", and it's certainly not > representative of the "best" practice that is currently known. > > If we're going to do anything like this at all (and I realize that > XML advocates really want something like this), we should: > > a) at least define what it means to resolve such URNs, and ideally >set up an initial resolution system for them. The IANA doesn't have the resources for that right now. > b) limit the protocol parameters to which it applies to those >which are justified by some use case, rather than applying >them to all protocol parameters. The document requires an RFC in order for a URN to be assigned. We never suggest assigning them to all protocol parameters. We originally though about the idea but after looking realized it was rather silly. Are you sure you're reading the right version? > c) make it clear that it is NOT acceptable to use those URNs >as substitues for the actual parameter values specified >in a protocol specification. Unless that protocol specification actually _uses_ the URN _as_ the protocol paramenter's name. Which some will > d) embed NO visible structure in the URNs - just assign each >parameter value a sequence number. people who want to use >those URNs in XML or whatever would need to look them up at IANA's >web site. > >actually if IANA assigned each parameter an OID then the oid URN >type could be used. _I_ wouldn't have a problem with that but the IANA and those who wanted this document to begin with might. I would gladly hear some debate on that. I suggest we be quick though. I know of at least one Working Group that has this as a normative reference and they're waiting on it -MM -- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
Re: comments on Friday scheduling (was Plenaries at IETF 53)
On Thu, Jan 17, 2002 at 11:34:35AM -0800, Dave Crocker wrote: > At 02:04 PM 1/17/2002 -0500, Jeffrey Altman wrote: > >Sunday with little to do other than catch up on work that really > >should have been done before I arrived. So maybe doing more on Sunday > >would be a possibility. > > This is an interesting suggestion. > > The two negatives are that a) some people do not work on Sunday, and 2) > those currently traveling to the IETF on Sunday would be forced to do it on > Saturday. > > That said, there are enough people who take advantage of the Saturday fare > benefit to make it worth considering using Sunday for WG meetings. But most of those who do this also use Sunday to have pre-IETF meetings. I've known several folks who have Sunday booked solid with business/design-team/etc meetings weeks before the actual IETF begins. I would personally prefer extending into Friday... -MM -- ---- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
Re: persistent domain names
On Thu, Nov 01, 2001 at 10:54:15AM +0100, Harald Alvestrand wrote:
> --On onsdag, oktober 31, 2001 09:17:34 -0500 Michael Mealling
> <[EMAIL PROTECTED]> wrote:
> >On Tue, Oct 30, 2001 at 09:15:35PM +, Zefram wrote:
> >>I'm looking for discussion of the problem more than the solution at this
> >>stage; my I-D does outline a couple of possible solutions, but
> >>considering the issues that have arisen already in respect of the
> >>problem statement, solution finding will have to wait a bit.
> >
> >BTW, If you want to use OIDs in URIs there's already RFC 3061. The only
> >problem is with resolution since there is no OID database and proving
> >who has what is not a simple operation at all...
>
> there are a couple of databases, such as http://www.alvestrand.no/objectid/
>
> but they are NOT authoritative, WOEFULLY incomplete, and you are generally
> lucky if you find what you are looking for.
>
> it would be fun :-) to populate the oid.urn.arpa zone with data from here -
> but not particularly useful, I think.
Yes it would. And if it even remotely succeeds you end up with a real
OID database that other things work off of. Once the DDDS documents
are done and the {uri|urn}.arpa delegations are created we could give it
a try.
If anyone is interested in the idea contact me directly and I'll see
how much support there is and if we could actually do something...
-MM
--
Michael Mealling| Vote Libertarian! | urn:pin:1
[EMAIL PROTECTED] | | http://www.neonym.net
Re: persistent domain names
On Tue, Oct 30, 2001 at 09:15:35PM +, Zefram wrote: > I'm looking for discussion of the problem more than the solution at this > stage; my I-D does outline a couple of possible solutions, but considering > the issues that have arisen already in respect of the problem statement, > solution finding will have to wait a bit. BTW, If you want to use OIDs in URIs there's already RFC 3061. The only problem is with resolution since there is no OID database and proving who has what is not a simple operation at all... -MM -- -------- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
Re: persistent domain names
On Tue, Oct 30, 2001 at 06:48:40PM -0500, [EMAIL PROTECTED] wrote: > On Tue, 30 Oct 2001 21:15:35 GMT, Zefram <[EMAIL PROTECTED]> said: > > I'm looking for discussion of the problem more than the solution at this > > stage; my I-D does outline a couple of possible solutions, but considering > > the issues that have arisen already in respect of the problem statement, > > solution finding will have to wait a bit. > > URI - we'll work with the ISSN example that you gave. Designing a DNS > that is fault-tolerant is well-understood (use multiple NS in different > AS, not all in the same /24 like certain famous sites did ;). Therefor, > for this discussion, "if issn.org goes away that URN space is hosed". > Very true - but let's think a bit deeper. "issn.org" is not likely > to go away unless the ISSN International Centre goes away - in which case > the ISSN system is in trouble anyhow. Woaah... I think there's a huge misunderstanding of the URI Resolution process here. Cutting out the original document's discussion here: 2.2 URI Resolution The URI resolution process defined by [NAPTR] refers URI resolvers through a series of domain names to route a resolution request to the appropriate authority that can give a location or other information for a resource. These referrals, being by name, implicitly assume that the name/identity mapping is persistent. In particular, consider URN types that are managed and resolved by a single organisation, for example the "ISSN" URN namespace described in [ISSN-URN]. In cases like this, resources critical to the handling of all URIs of a particular type are named within a domain managed by the single organisation responsible for that URI type. Any interruption of name resolution in that domain, or any compromise of the name/identity correspondence for that domain, would be highly disruptive. It is necessary in these cases that the name of a privately-managed domain be reliably persistent. The referrals are meant to be dynamic. That's the entire point of the URI Resolution process. If issn.org becomes disrupted either through some DNS problems or through the fact that ISSN changes their dns entries to be ISN.info or somesuch, the URI Resolution process still works if you do the delegation the way the documents suggest you do it. The ISSN organization could setup their NAPTR resolution process so that every day at 4:00 the delegation through (not to, but through) issn.org gets changed to some other domain-name. The entire process is dynamic enough using DNS' TTLs that there is no need for the domain-names to be persistent. The only one that does have to be persistent is the very first one (uri.arpa). In that one small sense, you are right. We do need some domains to be persistent. But we already have a process for doing that in the .arpa domain. But it should be done _EXTREMELY_ carefully. Persistence in the DNS is just the wrong way of going about it. Make your URIs persistently bound to the logical Resource and then use some dynamic resolution mechanism to make sure you can keep that resolution step in line with the logical binding -MM -- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
Re: rfc-index.txt in xml ?
On Thu, Mar 01, 2001 at 01:30:22PM -0500, Jerome Etienne wrote: > i am writting documents referencing many RFCs and to manually convert > the ascii of rfc-index.txt in the xml format described in rfc2629.2.4.1 > isn't very effective. > Where can i find the same list of RFCs in a more computer friendly > format than the 'ASCII for humans' of rfc-index.txt. See http://xml.resourc.eorg/public/rfc/bibxml/ You can copy the appropriate files to your local machine and then do this: ... %include.reference.RFC.2629; ... -MM -- -------- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Re: the advocates for non-ASCII RFC's
On Wed, Feb 28, 2001 at 01:26:07AM -0800, James P. Salsman wrote: > > Who are these people? > > Perhaps they are from the majority of humans who use languages > written with glyphs absent from ASCII (and I don't mean Smalltalk-79.) > > Or maybe they have a pressing need to use the International > Phonetic Alphabet entities because the "new economy" synchronous > telephony systems are insufficiently more useful than ordinary > "old economy" synchronous telephony systems, and the only way > some of the necessary engineering staff will ever get interested > in asynchronous telephony is if they get to use the IPA for their > latest compression schemes. > > Maybe they want to be able to include UNICODE art, which is much > like ASCII art but more creative. > > Whoever they are, and whatever they want, they will probably agree > that also having an English version, in ASCII, in addition to the > non-ASCII version if there is one, is a good thing. So what's stopping them from doing that now? I've seen versions of RFCs on the net where someone has either included comments in the document or translated it. I've even seen Powerpoint versions of an RFC. You could even put a pointer to it in the document itself. Since I use "Marshall's XML Stuff" I end up with the text version as well as an HTML version which I put up on cnrp.net. I could even imagine a slight change to the artwore tag to allow multiple representations of the artwork depending on the intended output. I send in the ASCII text since its canonical and make the other versions available for those that need it. Seems pretty simple to me -MM P.S. Until you can get /bin/vi to correctly handle the entire Unicode standard (BIDI), IMHO, 'UNICODE art' is up there with transporters and Faster Than Light warp engines -- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Re: XML, etc
On Tue, Feb 27, 2001 at 04:54:02PM +, Bob Braden wrote: > *> The other thing that would be nice is a way of getting all of the > *> authors current contact info in one place and up to date. > *> > > If you have a good idea on how to keep contact information > up to date, the RFC Editor would like to know. ;-) Point taken! ;-) I wasn't actually suggesting the secretariat or the RFC Editor attempt to keep it up to date. Instead just pull it out into a seperate, referenceable section much the way Marshall has done with the bibliography. People tend to do at least a little bit better job of maintaining their contact information when they know its going to be used -MM -- -------- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Re: HTML better for small PDAs
On Mon, Feb 26, 2001 at 06:30:56PM -0800, Marshall T. Rose wrote: > i agree. i'm not asking that we publish RFCs in any new formats. i'm > suggesting that we experiment for 9 months in the I-D area. One of the absolute best reasons to use the XML stuff (beyond the many other stated reasons) is the fact that Marshall has been graciously maintaining a bibliography on xml.resource.org that makes building your references section _much_ easier. If we do experiment with XML in the internet-drafts repository I really do think we should either migrate Marshall's bibliography or help him maintain it. The other thing that would be nice is a way of getting all of the authors current contact info in one place and up to date. -MM -- ---- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Re: Writing Internet Drafts on a Macintosh
On Thu, Feb 22, 2001 at 08:05:42AM -0800, Stephen McHenry wrote: > At 05:04 AM 2/22/2001, David C Lawrence wrote: > > > > Also, why isn't HTML an accepted format for Internet Drafts, pretty > > > > much everyone on the planet should be able to read an HTML file (even > > > > using Lynx on a terminal)? > > > > > > and that goes for pdf too, given that the irs uses it too :) > > > >It isn't accepted because flat, plain ASCII text is by far the most > >portable format on the planet and beyond. For example, there are > >plenty of IETFers who still read the drafts in email, and still use > >email clients that don't handle HTML natively. > > > >It is easiest to work with when you are on a "dumb" device. Pretty > >much any program that can handle text at all can handle unadorned > >ASCII, but HTML can be much more of a nuisance. > > Am I the only one that finds a certain bit of irony in the fact that the > last IETF conference provided "peek at the future" style networking - i.e., > 11MB 802.11 wireless throughout the entire hotel, so that people could > literally walk from one end of the hotel to the other with laptop perched > in the crook of one arm while using the other to do e-mail, web browsing > etc... but if you were using it on a non-MS world you will have known that life still isn't perfect when it comes to wireless interoperability. The IETF is about _interoperability_, not the latest and greatest feature set. > ...AND that these are the same people with archaic browsers and > e-mail clients that can't handle recent advances in technology - even to > the point of using "dumb" devices that can only handle ASCII? Its not that we have dumb devices, its that the OUTPUT of others peopls devices aren't interoperable enough to utilizied by ANY device. > This strikes me a little like the pilot of the space shuttle who still uses > an outhouse at home... But if that shuttle pilot were on an alien ship that had no concept of restrooms at all then you're left with whatever works... BTW, I use Marshall's xml2rfc stuff (RFC 2629) and it works perfectly. I can maintain my documents just like I do my code and then I can output it to both text and HTML (I hear nroff is coming soon). IMHO, the one great advantage to using ASCII documents is that it greatly cuts down on artwork in documents. If it really needs a picture then the author has to pass a pretty high bar to get it in the document. I don't want to read RFCs that act more like Powerpoint presentations -MM -- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Re: 49th-IETF conf room planning
On Mon, Dec 18, 2000 at 08:46:31PM -0800, Matthew Goldman wrote: > It makes absolutely no sense to have someone pre-pay a meeting fee, pay to > travel to a location, attempt to attend a meeting, and be turned-away. > > In addition, turning away people who wish to attend seems counter to the > IETF spirit. I think the operative word here is 'attend'. Keith's point is that you don't 'attend' an IETF meeting, you participate in one. But we've beaten this horse into a fine pulp long before now so I'm not going to belabor the point -MM -- -------- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Re: 49th-IETF conf room planning
On Mon, Dec 18, 2000 at 11:35:38PM -0500, Keith Moore wrote: > > > I fervently hope not. Las Vegas is the tobacco smoking capital of > > > the U.S. -- higher rates than anywhere else in the country, including > > > areas where they grow the stuff. It is also very hard to find good > > > quality food (but is awash in cheap buffets). > > > > Sorry, but I'd prefer Vegas vs. not being able to attend half of the > > meetings I planned to in San Diego simply because there was not enough > > space. I was very dishardened by this, and hope the meeting planners are > > able to plan for 3000+ attendees for future meetings. > > for many people, having smoke anywhere near the meeting rooms > is as much of a barrier to participation as having the meeting > rooms full. I was out there this past summer at Caesers Palace for a Lunar Development Conference and the only place I found smoke was in the Casino itself. The conference rooms and actual hotel rooms were smoke free and very nice (and cheap). In the Caesars Palace Conference center the hallways were as large as the subdivided Grand Ballroom in San Diego. Caesars would barely even notice us > I'd far rather we raise the bar for participants (i.e. only admit > those who have done their homework) than make more room for > non-participants. This wouldn't have helped in the DOMREG/WHOIS BOF. I did an informal survey and everyone in my part of the doorway was someone who should have been there and who had read the documents. Maybe the solution isn't Vegas but instead focusing on conference centers in the city in question instead of strictly hotel only facilities. -MM -- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Where is the OID "dot convention" spelled out?
For all the ASN.1 folks out there: I'm in the midst of writing up the OID URN namespace document (see http://www.ietf.org/internet-drafts/draft-mealling-oid-urn-00.txt) and it has come to my attention that none of the ASN.1 standards define the dot-notation that we use in all sorts of RFCs. I'm specifically referring to the practice of inserting dots in between each arc as in: 1.3.6.1.4.1 Is anyone aware if this is actually spelled out somewhere? I don't have the newest ASN.1 docs in front of me so if the're in there a page reference would be great. -MM -- -------- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Re: New mailing list for Common Indexing Protocol discussions
Martin Hamilton said this: > Hi, with the sad demise of Bunyip we lost the FIND working group's > mailing list. Not a disaster, since the RFCs (2651 through 2655) have > now been published, but it still leaves people doing stuff with CIP > without a place to meet up and talk. Just as an FYI, I have the FIND list archive and I'm in the process of putting it up on an ftp server. I'll let the new list know about the archive when its up... -- -------- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
