Re: [whatwg] WebSockets: UDP
On Wed, 02 Jun 2010 19:48:05 +0200, Philip Taylor excors+wha...@gmail.com wrote: I'm glad the discussion on this has taken off a bit. I've spoken to a few more game devs and even though it's still relatively few there's a slight majority that prefer the interface to be at the Torque/RakNet-level rather than at the UDP-socket-wrapper-level. I'm hoping I can talk a few of them into joining the list and taking a more active part in the discussions. So they seem to suggest things like: - many games need a combination of reliable and unreliable-ordered and unreliable-unordered messages. One thing to remember here is that browsers have other means for communication as well. I'm not saying we shouldn't support reliable messages over UDP, but just pointing out the option. I believe for example World of Warcraft uses this strategy and sends reliable traffic over TCP while movement and other real-time data goes over UDP. - many games need to send large messages (so the libraries do automatic fragmentation). Again, this is probably because games have no other means of communication than the NW-library. I'd think these large reliable messages would mostly be files that need to be transferred asynchronously for which browsers already have the tried and tested XMLHttpRequest. - many games need to efficiently send tiny messages (so the libraries do automatic aggregation). This is probably true for many other use-cases than games, but at least in my experience games typically use a bit-packer or range-coder to build the complete packet that needs to be sent. But again, it's a matter of what level you want to place the interface. Perhaps also: - Cap or dynamic limit on bandwidth (you don't want a single web page flooding the user's network connection and starving all the TCP connections) - Protection against session hijacking Great - Protection against an attacker initiating a legitimate socket with a user and then redirecting it (with some kind of IP (un)hijacking) to a service behind the user's firewall (which isn't a problem when using TCP since the service will ignore packets when it hasn't done the TCP handshake; but UDP services might respond to a single packet from the middle of a websocket stream, so every single packet will have to be careful not to be misinterpreted dangerously by unsuspecting services). I don't quite follow what you mean here. Can you expand on this with an example? -- Erik Möller Core Developer Opera Software
[whatwg] Comment on 6.6 Offline Web Applications
Hi there, I noticed the Application Cache does not allow to remove a single cached web application from the cache. Is that on purpose? I am under the impression the cache is here more an offline storage for webapps than a normal cache, and that in the long run browsers will have to implement an Offline Web Apps manager. Since the user is supposedly already provided with a dialog asking permission to make a webapp available offline, it makes sense to give him/her a way to remove a single application from the cache. /Daniel
Re: [whatwg] WebSocket set-cookie
On Fri, 07 May 2010 16:32:38 +0200, Simon Pieters sim...@opera.com wrote: establish a WebSocket connection [[ 41. ... If the entry's name is set-cookie or set-cookie2 or another cookie-related field name If the relevant specification is supported by the user agent, handle the cookie as defined by the appropriate specification, with the resource being the one with the host host, the port port, the path (and possibly query parameters) resource name, and the scheme http if secure is false and https if secure is true. [COOKIES] If the relevant specification is not supported by the user agent, then the field must be ignored. ]] At this point, the handshake can still fail. It seems bad to set cookies if the handshake fails. We want to process set-cookie when the handshake has succeeded (but before changing readyState and firing 'open'). ...but still in that same task that changes readyState and fires 'open'. -- Simon Pieters Opera Software
Re: [whatwg] WebSockets: UDP
On Thu, Jun 3, 2010 at 7:28 AM, Erik Möller emol...@opera.com wrote: [...] One thing to remember here is that browsers have other means for communication as well. I'm not saying we shouldn't support reliable messages over UDP, but just pointing out the option. Yep - the relevant use cases ought to be supported decently by the platform, but not necessarily by this extension to the platform (it might be a different extension or it might be (probably is) supported already). - Protection against an attacker initiating a legitimate socket with a user and then redirecting it (with some kind of IP (un)hijacking) to a service behind the user's firewall (which isn't a problem when using TCP since the service will ignore packets when it hasn't done the TCP handshake; but UDP services might respond to a single packet from the middle of a websocket stream, so every single packet will have to be careful not to be misinterpreted dangerously by unsuspecting services). I don't quite follow what you mean here. Can you expand on this with an example? I was thinking something like: A host at IP 11.11.11.11 on the public internet runs some UDP service, like DNS or TFTP or something a bit more secure. That service is restricted so it only responds to packets received from IP 22.22.22.22 (a trusted user). The UDP Web Socket handshake is carefully constructed so that it won't trigger dangerous behaviour in any of those services (like how the TCP Web Socket uses a safe HTTP-ish handshake). An attacker hijacks the IP 11.11.11.11 from the perspective of the user (by advertising new routes near the user), so the user's packets to that address go to the attacker. The attacker gets the user to visit a web page which sets up a UDP Web Socket with the attacker's server at 11.11.11.11, doing all the handshake authentication correctly. The attacker then releases its hijacked address, so any subsequent Web Socket packets will go to the original restricted service. Since they're being received from the trusted user, the service will trust them. Since the web browser has already done the Socket handshake, it will believe it's talking to a legitimate Web Socket server and will continue sending whatever data packets the attacker's script tells it to. The service will then be receiving and responding to attacker-controlled packets, and will never have seen the carefully constructed handshake that's designed to protect it. That's not a danger for TCP services since they'll reject unexpected packets from the middle of a TCP stream, but UDP services may accept packets from the middle of a UDP Web Socket stream. So it's not sufficient to carefully construct the Web Socket handshake packets to not trigger unwanted behaviour in non-Socket services. Every data packet sent on the Socket has to be carefully constructed too. (This might be a largely impractical or pointless attack, and there's probably much easier ways to attack the exposed service, but I don't know enough about security to judge that. Also I don't know what packet construction would be sufficiently careful. But it seems like a possible new concern that's introduced when using UDP in this context.) -- Philip Taylor exc...@gmail.com
[whatwg] Form validation against invisible controls
An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 8:16 AM, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. Adding @hidden to the list of things that skip validation is good. Adding display:none is not. That's a big layering violation that we authors have to suffer through with screen readers already. I'd greatly prefer not muddying the waters there. ~TJ
Re: [whatwg] Form validation against invisible controls
On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) You'd need to check the visibility or display also of all ancestors, that opacity is not 0, that the bounding box has enough size to render the form to the user and etc. That's quite complicated to specify. Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls.
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 8:42 AM, João Eiras jo...@opera.com wrote: On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) You'd need to check the visibility or display also of all ancestors, that opacity is not 0, that the bounding box has enough size to render the form to the user and etc. That's quite complicated to specify. Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. That's even worse - that defeats the time-honored trick to hide something visually without hiding it in any other way of absolutely positioning it off the screen. It might even mean that elements currently off the screen (but that can be scrolled to) wouldn't validate. ~TJ
Re: [whatwg] Form validation against invisible controls
On Thu, 2010-06-03 at 08:54 -0700, Tab Atkins Jr. wrote: On Thu, Jun 3, 2010 at 8:42 AM, João Eiras jo...@opera.com wrote: On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) You'd need to check the visibility or display also of all ancestors, that opacity is not 0, that the bounding box has enough size to render the form to the user and etc. That's quite complicated to specify. Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. That's even worse - that defeats the time-honored trick to hide something visually without hiding it in any other way of absolutely positioning it off the screen. It might even mean that elements currently off the screen (but that can be scrolled to) wouldn't validate. ~TJ But we really shouldn't be positioning things 'off screen' anyway. You should be considering people who aren't viewing the site through the traditional computer web browser. What about people who are using a speech or Braille browser? What about search engines (most of which specify in their terms that what you give them should equal the user experience) and basically any service that legitimately scrapes content (think web snippets, etc that some browsers are implementing) Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Form validation against invisible controls
Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being renderedrendering.html#being-rendered (e.g. it has the hidden editing.html#the-hidden-attribute attribute set) then user agents may report a script error. This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 2010/6/4 TAMURA, Kent tk...@chromium.org An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Form validation against invisible controls
On 6/3/10 11:42 AM, João Eiras wrote: Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. Gecko doesn't necessarily paint form controls that are outside the viewport, yet ignoring those seems wrong. -Boris
[whatwg] fixBrokenLink is not defined
I have noticed over the last year or so, the error fixBrokenLink often popping up. fixBrokenLink is not defined. I seem to recall at one point filing a bug but cannot find it in w3c Bugzilla http://www.w3.org/Bugs/Public/query.cgi http://dev.w3.org/html5/spec/Overview.html fixBrokenLink is not defined. The error can be a bit of a distraction when reading and discussing. The WhatWG-hosted one-pager causes Firefox to freeze for upwards of forty seconds; I'm not interested in that. What is fixBrokenLink? Is it DOM-traversal done onload? That's a known cause of such delay, and the larger the document, the longer the delay. Although I do not know for certain if this is the case with the spec on whatwg.org, fixBrokenLink seems a suspect possibility. It would be a good idea to look into the cause of the problem and see about using another approach.
Re: [whatwg] Comment on 6.6 Offline Web Applications
On Thu, Jun 3, 2010 at 15:01, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: Hi there, I noticed the Application Cache does not allow to remove a single cached web application from the cache. Is that on purpose? I am under the impression the cache is here more an offline storage for webapps than a normal cache, and that in the long run browsers will have to implement an Offline Web Apps manager. Since the user is supposedly already provided with a dialog asking permission to make a webapp available offline, it makes sense to give him/her a way to remove a single application from the cache. /Daniel Section 6.6.7 talks about expiration of cached data [1], but also includes a few notes about removing items from the store. It specifically states that user-agents could have a delete site-specific data feature which also covers removing application caches, but also hints towards a feature that removes caches on request of the user. The API does not state a way allowing an application to remove itself from the cache, which could be desirable for web authors. If there's interest for such an addition I'm willing to make a proposal, as it isn't hard to think about use-cases for such a feature. Regards, Peter Beverloo [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#expiring-application-caches
Re: [whatwg] fixBrokenLink is not defined
On Thu, 3 Jun 2010, Garrett Smith wrote: I have noticed over the last year or so, the error fixBrokenLink often popping up. fixBrokenLink is not defined. I seem to recall at one point filing a bug but cannot find it in w3c Bugzilla http://www.w3.org/Bugs/Public/query.cgi http://dev.w3.org/html5/spec/Overview.html fixBrokenLink is not defined. Does this error occur with the WHATWG versions of the spec? If not, then please report it to the W3C, not the WHATWG (it's probably an issue with Mike's spec splitter script). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comment on 6.6 Offline Web Applications
There is a way for the application to remove itself from the cache. If fetching the manifestUrl returns a 404 or 410 response, all traces of that manifestUrl are deleted from the cache. See section 6.6.4. On Thu, Jun 3, 2010 at 12:30 PM, Peter Beverloo pe...@lvp-media.com wrote: On Thu, Jun 3, 2010 at 15:01, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: Hi there, I noticed the Application Cache does not allow to remove a single cached web application from the cache. Is that on purpose? I am under the impression the cache is here more an offline storage for webapps than a normal cache, and that in the long run browsers will have to implement an Offline Web Apps manager. Since the user is supposedly already provided with a dialog asking permission to make a webapp available offline, it makes sense to give him/her a way to remove a single application from the cache. /Daniel Section 6.6.7 talks about expiration of cached data [1], but also includes a few notes about removing items from the store. It specifically states that user-agents could have a delete site-specific data feature which also covers removing application caches, but also hints towards a feature that removes caches on request of the user. The API does not state a way allowing an application to remove itself from the cache, which could be desirable for web authors. If there's interest for such an addition I'm willing to make a proposal, as it isn't hard to think about use-cases for such a feature. Regards, Peter Beverloo [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#expiring-application-caches
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 12:11 PM, TAMURA, Kent tk...@chromium.org wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error. This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 I think this isn't a feasible strategy to pursue. You'd have to carefully define what's not being rendered, and it will violate layering massively. CSS should not be able to override constraints set in HTML. The latter are part of the semantics of the form, and the former is supposed to only control presentation. If the user can't actually change the form to match requirements, that's a bug in the page. The browser should not try to guess what the page really meant using some inevitably complicated heuristic. It should respect what the page says, and make it not work. If the browser has a UI for form validation errors, it can use that to tell the user what the problem is in terms that the page author can understand, so the user can report it and the page can be fixed.
Re: [whatwg] fixBrokenLink is not defined
On 6/3/10, Ian Hickson i...@hixie.ch wrote: On Thu, 3 Jun 2010, Garrett Smith wrote: I have noticed over the last year or so, the error fixBrokenLink often popping up. fixBrokenLink is not defined. I seem to recall at one point filing a bug but cannot find it in w3c Bugzilla http://www.w3.org/Bugs/Public/query.cgi http://dev.w3.org/html5/spec/Overview.html fixBrokenLink is not defined. Does this error occur with the WHATWG versions of the spec? If not, then please report it to the W3C, not the WHATWG (it's probably an issue with Mike's spec splitter script). \ I'm not gonna check because that size freezes the browser.
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 3:48 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Thu, Jun 3, 2010 at 12:11 PM, TAMURA, Kent tk...@chromium.org wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 I think this isn't a feasible strategy to pursue. You'd have to carefully define what's not being rendered, and it will violate layering massively. CSS should not be able to override constraints set in HTML. The latter are part of the semantics of the form, and the former is supposed to only control presentation. If the user can't actually change the form to match requirements, that's a bug in the page. The browser should not try to guess what the page really meant using some inevitably complicated heuristic. It should respect what the page says, and make it not work. If the browser has a UI for form validation errors, it can use that to tell the user what the problem is in terms that the page author can understand, so the user can report it and the page can be fixed. I posted this on the Chromium bug, but I take the sentence Kent quotes to affect only the UI shown on a validation failure, not the actual results of validation. That is, if a control fails validation and has the hidden attribute, validation still fails, but the UA may display a message indicating the page has an error in addition to/instead of the normal validation failure message. I agree that it would be a mistake to exclude invisible elements from validation, as that would be a rathole (and seems conceptually wrong to me). PK
Re: [whatwg] Form validation against invisible controls
On 6/3/10, TAMURA, Kent tk...@chromium.org wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. Where? http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being renderedrendering.html#being-rendered (e.g. it has the hidden editing.html#the-hidden-attribute attribute set) then user agents may report a script error. That's about input type=hidden This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. You lost me on that one. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 That bug is describing an error when validating a control that cannot have focus. That's more specific from a control that is not visible. Is the issue in defining what is and what isn't focusable? 2010/6/4 TAMURA, Kent tk...@chromium.org An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
Re: [whatwg] URN or protocol attribute
On 3/11/2010 10:44 AM, Brett Zamir wrote: On 3/11/2010 10:31 AM, Ian Hickson wrote: I would recommend following a pattern somewhat like the Web's initial development: create a proof of concept, and convince people that it's what they want. That's the best way to get a feature adopted. This is described in more detail in the FAQ: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Ok, fair enough. I think I'll try that as a browser extension snip Just as a follow-up, I have now made a Firefox extension which supports two attributes on a/: uris and alternateURIs, whereby the former takes precedence over href, and the latter are accessible only by right-clicking links (though potentially discoverable by custom styling of such links (automatable by the extension)). My thought is that sites which have the following goals may be particularly interested: 1) Those wishing to maintain objectivity and refrain from endorsing specific sites, e.g., governments, news institutions, scholars, or sites like Wikipedia. Even for a site's internal links, use of alternateURIs could offer convenience (e.g., Wikipedia would no doubt wish to continue to use href to refer to its own ISBN page by default, but could use the alternateURIs attribute to allow right-clicks on the link to activate the URN link which in turn activates their chosen default handler, e.g., Amazon, Google Books, etc.). The same could be done for music, etc. 2) giving full user choice as to how to view the data (especially useful for information of common and particular interest to the site viewers, e.g., links to the Bible in a religious forum) 3) those wishing to try out new protocols of whatever type (not only URNs), such as chatting protocols, whether installed via web or browser extension, as the proposed markup gives them a convenient fall-back to href, so they don't have to have dead links for those whose browsers do not support the protocol. https://addons.mozilla.org/en-US/firefox/addon/162154/ Brett
Re: [whatwg] URN or protocol attribute
On 6/4/2010 12:59 PM, Brett Zamir wrote: On 3/11/2010 10:44 AM, Brett Zamir wrote: On 3/11/2010 10:31 AM, Ian Hickson wrote: I would recommend following a pattern somewhat like the Web's initial development: create a proof of concept, and convince people that it's what they want. That's the best way to get a feature adopted. This is described in more detail in the FAQ: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Ok, fair enough. I think I'll try that as a browser extension snip Just as a follow-up, I have now made a Firefox extension which supports two attributes on a/: uris and alternateURIs, whereby the former takes precedence over href, and the latter are accessible only by right-clicking links (though potentially discoverable by custom styling of such links (automatable by the extension)). My thought is that sites which have the following goals may be particularly interested: 1) Those wishing to maintain objectivity and refrain from endorsing specific sites, e.g., governments, news institutions, scholars, or sites like Wikipedia. Even for a site's internal links, use of alternateURIs could offer convenience (e.g., Wikipedia would no doubt wish to continue to use href to refer to its own ISBN page by default, but could use the alternateURIs attribute to allow right-clicks on the link to activate the URN link which in turn activates their chosen default handler, e.g., Amazon, Google Books, etc.). The same could be done for music, etc. 2) giving full user choice as to how to view the data (especially useful for information of common and particular interest to the site viewers, e.g., links to the Bible in a religious forum) 3) those wishing to try out new protocols of whatever type (not only URNs), such as chatting protocols, whether installed via web or browser extension, as the proposed markup gives them a convenient fall-back to href, so they don't have to have dead links for those whose browsers do not support the protocol. https://addons.mozilla.org/en-US/firefox/addon/162154/ Just to elaborate a little bit further, one possible future addition which could further enhance this experience would be to design a protocol (and corresponding markup-detection mechanism), say created: or wiki: which would first check via HEAD request whether the page were created or not, and then style the link accordingly and possibly alter the URL to lead directly to the editing or alternatively, it could make HEAD requests to try out a sequence of URLs, e.g., checking whether Citizendium had an article, and if not, creating a link to the Wikipedia article if present. While this could be done potentially via the server (e.g., this extension for Mediawiki: http://www.mediawiki.org/wiki/Extension:BADI_Pages_Created_Links ), I believe allowing client-side markup to do it would facilitate use of this potential more widely, allowing wikis or open-forums to link with one another in a way which prevents wasted visits by their users. Although URNs could also be used (as supported already potentially in the above extension) to try to find encyclopedic articles (e.g., urn:name:pizza), or better yet, through a new protocol which could suggest intended uses of the information (e.g., find:urn:name:pizza?category=order, find:urn:name:pizza?category=define, etc.) and thereby avoiding hard-coding information, the created: suggestion above could give authors more control than they have now if they did want to suggest a particular path-way. Brett
