Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Lisa Dusseault wrote: Don't browser and OS libraries dispatch on URI scheme? I guess it's probably not as easy to extend as adding a new handler for a new Content-Type, but it's at least possible for a new URI scheme to start appearing (in email, Web pages, local docs, etc) and for the user to install an application which registers for handling that scheme, and suddenly they have new functionality without upgrading the OS or browser. At least for Windows that is true. To me, that's a pretty compelling and unfuzzy benefit. It doesn't apply to all proposed new URI schemes, but it arguably does for HELD. Lisa, I still have trouble understanding the use case. Why would a user *ever* want to follow a heldref URI, and have a custom application come up? http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-08 states: This specification defines an extensible XML-based protocol that enables the retrieval of LI from a LIS by a Device. This protocol can be bound to any session-layer protocol, particularly those capable of MIME transport. This document describes the use of HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer Security (HTTP/TLS) as transports for the protocol. So my understanding is: - client obtains the URI of a LIS (Location Information Server) - client uses this protocol to obtain Location Information (LI) from that LIS The locationRequest currently has exactly *two* parameters, locationTime (a timeout value), and locationType (a keyword). What I am trying to understand is why we need a 48 page spec to define something that could easily be a single GET request to an HTTP URI with two query parameters. (The MIME type for the response format is fine) Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Julian Reschke wrote: Well. There's definitively a total disconnect between that IESG recommendation, and the W3C TAG's point of view (see ongoing discussion on the TAG mailing list about the xri scheme). It would be good when both organizations could come up with consistent answers. If a new URI scheme is defined, it needs to state what it identifies, and how it is resolved. If it identifies an HTTP resource, and resolution is done via HTTP, then it seems to me you don't need it. Note: I totally disagree. I detest, abhor and condemn the idea that there is such a thing as a HTTP resource. An URI identifies a resource. One possibility of accessing that resource is by using HTTP; if the URI scheme is http:, there is an implication that the definer of the URI regarded this as the normal way of accessing the resource, and that whether the resource is static, dynamic or changeable is a matter strictly under the control of the manager of the server identified by the hostname in the URI. Certain usages of HTTP (in particular, the use of HTTP URLs for XML schemas) have tended to denigrate this implication, and say you should regard this as an identifier. Still, the usage is prevalent enough that people have complained that servers identified in popular XML schemas are getting hit with enough extra traffic to cause operational problems. Now, many resources can be accessed over HTTP. And many more will be. But in many cases, the guarantees given should be DIFFERENT; a mid: URI means that if you find a copy of the message with this message-ID, it's probably the same message - a tag: URI means someone intended this URI to be an unique reference, and you can figure out who it was given enough time and effort. And I haven't even mentioned URNs yet. The WG needs to be clear about what kinds of resources it's identifying, and what the properties it wants to embed as part of the URI scheme is. Usually, all the features and warts of HTTP won't be the answer. I don't speak for anyone but myself. But just based on Julian's comments, I stand with the IESG advice on this one, and think that the W3C TAG (if its recommendation is reported correctly) is off in the weeds. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
On 7 aug 2008, at 10.56, Harald Alvestrand wrote: If a new URI scheme is defined, it needs to state what it identifies, and how it is resolved. If it identifies an HTTP resource, and resolution is done via HTTP, then it seems to me you don't need it. Note: I totally disagree. I detest, abhor and condemn the idea that there is such a thing as a HTTP resource. An URI identifies a resource. FWIW: I agree with this. A URI is an identifier. Some of them might be possible to resolve using for example information given by the URI scheme, but that is definitely not a requirement. And it has never been one either. Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Hi Harald. Harald Alvestrand wrote: Julian Reschke wrote: Well. There's definitively a total disconnect between that IESG recommendation, and the W3C TAG's point of view (see ongoing discussion on the TAG mailing list about the xri scheme). It would be good when both organizations could come up with consistent answers. If a new URI scheme is defined, it needs to state what it identifies, and how it is resolved. If it identifies an HTTP resource, and resolution is done via HTTP, then it seems to me you don't need it. Note: I totally disagree. Interesting, as most of what follows is something I *do* agree with :-) The point I was trying to make is that when a specification defines a new URI scheme, it should be able to state what it identifies, and, if it's intended to be resolvable, how that resolution process works. This information isn't present in the HELD draft. I detest, abhor and condemn the idea that there is such a thing as a HTTP resource. I was using HTTP resource as in something identified by an HTTP URL. An URI identifies a resource. Yes. One possibility of accessing that resource is by using HTTP; if the URI scheme is http:, there is an implication that the definer of the URI regarded this as the normal way of accessing the resource, and that whether the resource is static, dynamic or changeable is a matter strictly under the control of the manager of the server identified by the hostname in the URI. Yes. Certain usages of HTTP (in particular, the use of HTTP URLs for XML schemas) have tended to denigrate this implication, and say you should regard this as an identifier. Still, the usage is prevalent enough that people have complained that servers identified in popular XML schemas are getting hit with enough extra traffic to cause operational problems. I've heard that as well, and tried to find out exactly *what* URLs were causing the problem. As far as I can tell, it was always because of URLs that were intended to be dereferenced, such as URLs of DTDs. (If this is incorrect, I'd love to see a pointer...). Now, many resources can be accessed over HTTP. And many more will be. But in many cases, the guarantees given should be DIFFERENT; a mid: URI means that if you find a copy of the message with this message-ID, it's probably the same message - a tag: URI means someone intended this URI to be an unique reference, and you can figure out who it was given enough time and effort. And I haven't even mentioned URNs yet. Yes. The WG needs to be clear about what kinds of resources it's identifying, and what the properties it wants to embed as part of the URI scheme is. Yes. This is what I was saying, wasn't I? Usually, all the features and warts of HTTP won't be the answer. I don't speak for anyone but myself. But just based on Julian's comments, I stand with the IESG advice on this one, and think that the W3C TAG (if its recommendation is reported correctly) is off in the weeds. It seems to me that you have been reading something into my comments that isn't there. HELD (as in draft 08), defines two new URI schemes, does not define what they identity, does not state how to resolve them, and has examples using untested HTTP/1.1 features for resolution. That's why I was asking whether a new naming scheme really is needed *here*. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Patrik Fältström wrote: ... FWIW: I agree with this. A URI is an identifier. Some of them might be possible to resolve using for example information given by the URI scheme, but that is definitely not a requirement. And it has never been one either. ... Just for the record: I agree with this, and didn't say anything else. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
it's surprising how much we agree on :-) Julian Reschke wrote: Certain usages of HTTP (in particular, the use of HTTP URLs for XML schemas) have tended to denigrate this implication, and say you should regard this as an identifier. Still, the usage is prevalent enough that people have complained that servers identified in popular XML schemas are getting hit with enough extra traffic to cause operational problems. I've heard that as well, and tried to find out exactly *what* URLs were causing the problem. As far as I can tell, it was always because of URLs that were intended to be dereferenced, such as URLs of DTDs. (If this is incorrect, I'd love to see a pointer...). Is it clearly stated somewhere that URLs of DTDs are intended to be dereferenced? (in the Murky Old Days we had DTDs identified by SGML identifiers, which I don't think I'll be able to dereference any time soon) Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Harald Alvestrand wrote: it's surprising how much we agree on :-) Julian Reschke wrote: Certain usages of HTTP (in particular, the use of HTTP URLs for XML schemas) have tended to denigrate this implication, and say you should regard this as an identifier. Still, the usage is prevalent enough that people have complained that servers identified in popular XML schemas are getting hit with enough extra traffic to cause operational problems. I've heard that as well, and tried to find out exactly *what* URLs were causing the problem. As far as I can tell, it was always because of URLs that were intended to be dereferenced, such as URLs of DTDs. (If this is incorrect, I'd love to see a pointer...). Is it clearly stated somewhere that URLs of DTDs are intended to be dereferenced? Well, an XML processor needs to read a DTD if it doesn't already have a copy of it (you can opt-out of that using the standalone declaration, but that's not the default, see text around http://www.w3.org/TR/xml/#sec-rmd). (in the Murky Old Days we had DTDs identified by SGML identifiers, which I don't think I'll be able to dereference any time soon) Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
On Thu, Aug 7, 2008 at 1:56 AM, Harald Alvestrand [EMAIL PROTECTED] wrote: Well. There's definitively a total disconnect between that IESG recommendation, and the W3C TAG's point of view (see ongoing discussion on the TAG mailing list about the xri scheme). That discussion is just too long and gnarly to summarize, but without touching on any of the actual technical issues: There is a strong perception among quite a few people, notably including the TAG, that the XRI people don't understand the technologies they're trying to replace; many of their statements beginning XRI is needed because... have been challenged as being simply technically wrong. The TAG is in fact clearly correct when they state that introduction of new URI schemes is quite expensive. So it comes down to a matter of cost/benefit, and a lot of people are not convinced that a real benefit has been established for XRI, relative to the existing Web. If a new URI scheme is defined, it needs to state what it identifies, and how it is resolved. If it identifies an HTTP resource, and resolution is done via HTTP, then it seems to me you don't need it. Actually, no. There are lots of identifiers that do not have a resolution requirement. Certain usages of HTTP (in particular, the use of HTTP URLs for XML schemas) have tended to denigrate this implication, and say you should regard this as an identifier. Still, the usage is prevalent enough that people have complained that servers identified in popular XML schemas are getting hit with enough extra traffic to cause operational problems. This has happened, usually due to clueless implementors. The most famous case is the DTD URIs appearing in the HTML !DOCTYPE, which certain developers who will remain nameless tried to retrieve every time they parsed an HTML page. Surprise surprise, it didn't work. It's a real risk. Any identifier that can be used to retrieve something will so be used, whether that's appropriate or not, and that's a risk we have to work into our plans. -Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Tim Bray wrote: ... If a new URI scheme is defined, it needs to state what it identifies, and how it is resolved. If it identifies an HTTP resource, and resolution is done via HTTP, then it seems to me you don't need it. Actually, no. There are lots of identifiers that do not have a resolution requirement. Correct. I was sloppy. However, in the context of HELD it stays true, as the identifiers *clearly* are intended to be resolvable (as they are used for location requests, and the whole document would be totally pointless if there was no way to resolve them). This has happened, usually due to clueless implementors. The most famous case is the DTD URIs appearing in the HTML !DOCTYPE, which certain developers who will remain nameless tried to retrieve every time they parsed an HTML page. Surprise surprise, it didn't work. Right. RSS vs Netscape is another example. Using public URIs for DTDs introduces a single point of failure. Using public URIs for XML namespaces do not, because processors do not *need* to resolve them. It's a real risk. Any identifier that can be used to retrieve something will so be used, whether that's appropriate or not, and that's a risk we have to work into our plans. Correct. That being said, do we have any evidence that URIs that appear as XML namespace names (and *only* there) have caused this kind of problem? BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Tim Bray wrote: The TAG is in fact clearly correct when they state that introduction of new URI schemes is quite expensive. To me it seems that this depends on the extent to which those new URI schemes are to be used in contexts where existing URI schemes are used. New URI schemes used in new contexts or applications are not overly burdensome. It should also be recognized that overloading URI schemes (as well as overloading HTTP) is also expensive, though in a different way. The consequence of overloading is that functionality is reduced and interoperability suffers. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
On Thu, Aug 7, 2008 at 10:23 AM, Keith Moore [EMAIL PROTECTED] wrote: The TAG is in fact clearly correct when they state that introduction of new URI schemes is quite expensive. To me it seems that this depends on the extent to which those new URI schemes are to be used in contexts where existing URI schemes are used. New URI schemes used in new contexts or applications are not overly burdensome. Right, but there's a contradiction lurking here. You probably wouldn't bother to use URI syntax unless you expected fairly wide utilization, or to benefit from the plethora of existing URI-parsing and -resolving software. The notion of wanting to use URI syntax but simultaneously requiring a new scheme is often a symptom of fuzzy thinking. And in the specific case of XRI, which seems designed as an extremely general-purpose thing, the cost is clearly very high, so the benefits need to be compelling. It should also be recognized that overloading URI schemes (as well as overloading HTTP) is also expensive, though in a different way. The consequence of overloading is that functionality is reduced and interoperability suffers. Got an example? I'm having trouble thinking of any problems I've run across that could be ascribed to this. -Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Tim Bray wrote: On Thu, Aug 7, 2008 at 10:23 AM, Keith Moore [EMAIL PROTECTED] wrote: The TAG is in fact clearly correct when they state that introduction of new URI schemes is quite expensive. To me it seems that this depends on the extent to which those new URI schemes are to be used in contexts where existing URI schemes are used. New URI schemes used in new contexts or applications are not overly burdensome. Right, but there's a contradiction lurking here. You probably wouldn't bother to use URI syntax unless you expected fairly wide utilization, or to benefit from the plethora of existing URI-parsing and -resolving software. Disagree. Neither wide utilization, nor ability to reuse existing software were ever necessary to make URIs useful. A compact notation for naming resources (and in some cases, suggesting how those resources can be accessed) is useful in its own right to almost any networked application, even if it has to implement its own URI parsing routines, and even if it doesn't utilize the HTTP infrastructure at all. Also, URIs have mindshare, the value of which should not be underestimated. People all over the world are used to dealing with them and - at some level - understand their limitations. The notion of wanting to use URI syntax but simultaneously requiring a new scheme is often a symptom of fuzzy thinking. If URIs were a good idea in the context of the web, it's hardly surprising that they might be a good idea in the context of other networked applications. And in the specific case of XRI, which seems designed as an extremely general-purpose thing, the cost is clearly very high, so the benefits need to be compelling. I haven't followed XRI enough to have an opinion about it. It should also be recognized that overloading URI schemes (as well as overloading HTTP) is also expensive, though in a different way. The consequence of overloading is that functionality is reduced and interoperability suffers. Got an example? I'm having trouble thinking of any problems I've run across that could be ascribed to this. -Tim The most obvious example that comes to mind is that protocols tend to evolve separately from one another, even when derived from a common ancestor - and the scope/applicability of each protocol is likely to change over time. Whenever any protocol (including HTTP) is adapted for some application that is sufficiently removed from its normal use, and especially if that new application itself attracts a lot of users or implementations, there is a tendency to tweak that original protocol to better align it with the new application. For instance, we can see how this has happened with email message headers when they've been adapted to NetNews and HTTP requests and responses. (It also happened when RFC 822 was adapted for use on BITNET and UUCP networks). If the protocol being adapted is HTTP, and HTTP URIs are used to name resources in the new application, interoperability of HTTP URIs will suffer. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
On Aug 7, 2008, at 10:47 AM, Tim Bray wrote: On Thu, Aug 7, 2008 at 10:23 AM, Keith Moore [EMAIL PROTECTED] wrote: The TAG is in fact clearly correct when they state that introduction of new URI schemes is quite expensive. To me it seems that this depends on the extent to which those new URI schemes are to be used in contexts where existing URI schemes are used. New URI schemes used in new contexts or applications are not overly burdensome. Right, but there's a contradiction lurking here. You probably wouldn't bother to use URI syntax unless you expected fairly wide utilization, or to benefit from the plethora of existing URI-parsing and -resolving software. The notion of wanting to use URI syntax but simultaneously requiring a new scheme is often a symptom of fuzzy thinking. Don't browser and OS libraries dispatch on URI scheme? I guess it's probably not as easy to extend as adding a new handler for a new Content-Type, but it's at least possible for a new URI scheme to start appearing (in email, Web pages, local docs, etc) and for the user to install an application which registers for handling that scheme, and suddenly they have new functionality without upgrading the OS or browser. To me, that's a pretty compelling and unfuzzy benefit. It doesn't apply to all proposed new URI schemes, but it arguably does for HELD. Lisa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
On Thu, Aug 7, 2008 at 3:55 PM, Lisa Dusseault [EMAIL PROTECTED] wrote: Right, but there's a contradiction lurking here. You probably wouldn't bother to use URI syntax unless you expected fairly wide utilization, or to benefit from the plethora of existing URI-parsing and -resolving software. The notion of wanting to use URI syntax but simultaneously requiring a new scheme is often a symptom of fuzzy thinking. Don't browser and OS libraries dispatch on URI scheme? I guess it's probably not as easy to extend as adding a new handler for a new Content-Type, but it's at least possible for a new URI scheme to start appearing (in email, Web pages, local docs, etc) and for the user to install an application which registers Well, yeah, but a lot of the infrastructure is deployed on dumb devices and, more important, if you stick to existing URI schemes and use them properly, it All Just Works. I know it seems like Those Web Guys Hate URI Schemes, and I get tired of quoting http://www.w3.org/TR/webarch/#URI-scheme at people, and I admit being prejudiced by the fact that a high proportion of new-uri-scheme proposals have historically been poorly-considered (not all, see RFC4151). But there's no getting around it: the cost of new schemes is very high, if you want to be part of the Web. -Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Tim Bray wrote: Don't browser and OS libraries dispatch on URI scheme? I guess it's probably not as easy to extend as adding a new handler for a new Content-Type, but it's at least possible for a new URI scheme to start appearing (in email, Web pages, local docs, etc) and for the user to install an application which registers Well, yeah, but a lot of the infrastructure is deployed on dumb devices and, more important, if you stick to existing URI schemes and use them properly, it All Just Works. That's ridiculous. First of all it's not as if HTTP is an optimal or even particularly efficient way of accessing all kinds of resources - so you want to permit URI schemes for as many protocols as can use them. Second, user agents and other tools that use URIs glean valuable information from the differences between URI schemes, and they do so without having to negotiate protocol details. Granted you don't want to make every clue that a UA might benefit from visible in the URI scheme. But it's silly to say that existing URI schemes are sufficient for all purposes. I know it seems like Those Web Guys Hate URI Schemes, and I get tired of quoting http://www.w3.org/TR/webarch/#URI-scheme at people, and I admit being prejudiced by the fact that a high proportion of new-uri-scheme proposals have historically been poorly-considered (not all, see RFC4151). No doubt. Then again, most proposals of any kind are poorly considered. (And IMHO the advice in the webarch document about URI scheme reuse is, as kindly as I can put it, so over-simplified as to be incorrect.) But there's no getting around it: the cost of new schemes is very high, if you want to be part of the Web. If you adopt a fairly narrow view of the web, perhaps. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
On Thu, Aug 7, 2008 at 4:47 PM, Keith Moore [EMAIL PROTECTED] wrote: That's ridiculous. First of all it's not as if HTTP is an optimal or even particularly efficient way of accessing all kinds of resources - so you want to permit URI schemes for as many protocols as can use them. Well, it's not as if the presence of the http: scheme requires you to use the protocol, and in fact a very high proportion of all accesses to such resources go sideways through various caching schemes and so on. The notion that the scheme implies the protocol is a common and very old misconception. But it's silly to say that existing URI schemes are sufficient for all purposes. Nobody has ever said such a thing. I and others have repeatedly argued that one or another specific proposal for a new URI scheme has a lousy cost-benefit ratio. That is the totality of this debate. -T ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
At 6:04 PM -0700 8/7/08, Tim Bray wrote: Well, it's not as if the presence of the http: scheme requires you to use the protocol, and in fact a very high proportion of all accesses to such resources go sideways through various caching schemes and so on. The notion that the scheme implies the protocol is a common and very old misconception. How did you measure the accesses to arrive at the conclusion that a very high proportion of all such accesses to such resources go sideways through various caching schemes and so on? Can you elaborate on what and so on means here? On your other point, the accuracy of the idea that the scheme implies the protocol varies enormously. Some schemes are nearly pure identifier, without strong bindings to a specific dereferencing protocol ( tag and info come to mind). But some schemes really do have a very strong binding to specific protocol mechanics and a specific URI in those schemes amount to instructions as to how to engage in that.See RFC 4501 for an example. It defines the dns uri scheme, using a scheme definition that has a very explicit usage model and that describes the common resolution mechanism using the DNS. It retains the point that other resolution mechanisms are possible, but how to use it in a DNS context is both quite clear and quite clearly understood to be the common case. regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Tim Bray wrote: On Thu, Aug 7, 2008 at 4:47 PM, Keith Moore [EMAIL PROTECTED] wrote: That's ridiculous. First of all it's not as if HTTP is an optimal or even particularly efficient way of accessing all kinds of resources - so you want to permit URI schemes for as many protocols as can use them. Well, it's not as if the presence of the http: scheme requires you to use the protocol, and in fact a very high proportion of all accesses to such resources go sideways through various caching schemes and so on. The notion that the scheme implies the protocol is a common and very old misconception. But it's not a misconception. In the vast majority of contexts if you name a resource using an HTTP URI then it's expected that if that resource is at all accessible over the Internet, it's accessible via HTTP using the information in that URI. But it's silly to say that existing URI schemes are sufficient for all purposes. Nobody has ever said such a thing. I and others have repeatedly argued that one or another specific proposal for a new URI scheme has a lousy cost-benefit ratio. That is the totality of this debate. -T I am sure that many URI proposals have poor cost-benefit ratios. That's reason to give them scrutiny, but not a reason to reject the idea of having new URI types, nor to overload existing URI types. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
