Re: [whatwg] Browser Signature Standards Proposal
Digital signatures is as you say just a variation of authentication. The things that the DS people wants to add are: - A process that differs from authentication from the user's point of view - A persistent trace of the authenticated operation. This is what the signature adds to the picture. HTTPS with client-side certificates have no connection to content data since it occurs at the transport level. Digital signatures are created at the application-level in the schemes that Channy and I talk about. But it is a fact that strong authentication is an alternative to digital signatures but some of use are trying to change that, not only for legal reasons but for making a difference between login and accept. Anders - Original Message - From: Alexey Feldgendler [EMAIL PROTECTED] To: whatwg@lists.whatwg.org Sent: Wednesday, November 01, 2006 09:29 Subject: Re: [whatwg] Browser Signature Standards Proposal On Wed, 01 Nov 2006 14:22:15 +0600, Channy Yun [EMAIL PROTECTED] wrote: What benefit does this provide over simply using HTTPS with a client-side certificate? Using HTTPS with a client-side certificate doesn't support digital signature.The digital signature is same with the signing or stamp of contract in real world. Many governments encourage to add digital signature to transactional data (form data). It legally assures data and transactions signed(added digital signature) by user's certificates. The purpose of a digital signature is to certify that the data submitted by the client were not forged by an attacker. HTTPS with a client-side certificate ensures the same. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] [HTML5] 3.10.9. The |abbr| element
On Nov 2, 2006, at 3:44 PM, Jonathan Worent wrote: --- Christoph Päper [EMAIL PROTECTED] wrote: First off I think the requirement for a |title| is too strict, because there are time and space saving abbreviations everyone knows -- i.e. either their expansion or their meaning -- that do not need an expansion, e.g. e.g. or AIDS. Therefore the second sentence should use 'may', not 'should'. Agreed. (At the least, the specification is currently ambiguous about whether title= is required.) I disagree. There is never a guarantee that people will know what an abbreviation stands for, I know what AIDS is but not what it stands for. But that applies not just to abbreviations, but to writing in general. All writing assumes a level of knowledge. If a blind biologist listening to a scientific journal heard DNA expanded as deoxyribonucleic acid on every page, that would quickly become infuriating, even if the UA was smart enough to do it for only the first occurrence on each page. (Temporarily turning off such expansions would be unreasonable if there were other, unfamiliar, abbreviations present; and trying to request expansions from the UA case-by-case would be tiresome.) ... abbr title=that isi. e./abbr This would not be correct usage because the abbreviation i.e. does not represent that is it means that though. In this case you using is to mark up the definition. I use abbr title=that isi.e./abbr not just because that's what it means, but because that's how it *should* be expanded if it needs to be expanded, for example if it is being read aloud. (Expanding it as id est would be pretentiously unreasonable.) Similarly in Mac abbrOS/abbr abbr title=10X/abbr, I don't give abbrOS/abbr a title=, because what OS stands for is never relevant in the context. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Browser Signature Standards Proposal
Alexey Feldgendler [EMAIL PROTECTED], 2006-11-02 15:23 +0600: On Thu, 02 Nov 2006 14:27:33 +0600, Anders Rundgren [EMAIL PROTECTED] wrote: - A process that differs from authentication from the user's point of view This is a problem of browser UI design, not of web standards. What do you expect might happen when N different browser vendors each go off on their own and, working in isolation from one another, independently design and implement their own interfaces for handling what we've been discussing? As I say above, this should be solved at browser UI level. The browsers should make it clear to the user that presenting a client-side certificate to a website is effectively an act of disclosing and proving the user's identity, and that every piece of information he sends to the server (every user action) is non-repudiable. I'd love to hear some concrete suggestions on how you'd propose going about making that all clear to users through the browser UI. I just hope it's not a dialog box with text saying Presenting a client-side certificate to a website is effectively an act of disclosing and proving your identity, and every piece of information you send to the server (every action) is non-repudiable, with a checkbox that says Don't show me this warning next time. (And, of course, presentation of any client-side certificates to the server should be optional, easily switchable, and obviously indicated.) Again, what do you expect would happen when N different browser vendors -- without getting together with one another to work on any kind of specification for a mechanism for handling all that -- independently design and implement their own mechanisms? --Mike smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] [HTML5] 3.10.9. The |abbr| element
Lachlan Hunt wrote: Abbreviation expansions should only be supplied when they help the reader to understand the content, not just because the word happens to be an abbreviation. I agree, unless using abbr with no title is useful to get the correct rendering of abbreviations in non-visual media. I guess e.g. aural browsers must cope with rendering of abbreviations like PET and DNA without needing explicit markup, but I think knowing this sort of thing is important in determining the wording of the spec. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] [HTML5] 3.10.9. The |abbr| element
James Graham wrote: Lachlan Hunt wrote: Abbreviation expansions should only be supplied when they help the reader to understand the content, not just because the word happens to be an abbreviation. I agree, unless using abbr with no title is useful to get the correct rendering of abbreviations in non-visual media. Using abbr without a title would be useful if it automatically referred to a previous instance with the title attribute. e.g. You could mark up the first occurance as like this abbr title=As Far as I KnowAFAIK/abbr Then, later in the document, you could use it without the title attribute abbrAFAIK/abbr and a UA could allow the user to discover the expansion. This idea is already somewhat supported in the current draft, but requires that it references the defining term of a previously marked up dfn, rather than just another occurrence of the same abbreviation. IMHO, that part of the spec needs fixing. http://www.whatwg.org/specs/web-apps/current-work/#the-dfn http://www.whatwg.org/specs/web-apps/current-work/#the-abbr -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Form Control Group Labels
Lachlan Hunt wrote: Matthew Raymond wrote: Example: | p | label group=genderGender:/label | | label for=m | input type=radio id=m name=gender value=m | Male | /label | | label for=f | input type=radio id=f name=gender value=f | Female | /label | /p I just realised a problem with this proposal. What if we want to associate a label with several controls, with different names? Here's a few use cases: 1. Seperate fields for a date (day, month, year) Note: I'm aware that type=date solves this specific use case, but this is still a very commonly used structure today and illustrates my point nicely. label group= ? Birthday:/label label for=day day: input type=text name=bday-day id=day/label label for=month month: select name=bday-month id=month optionJanuary/option ... /select /label label for=yearyear: input type=text name=bday-year id=year/label Just use space separation like in |class| attributes: | label group=day month yearBirthday:/label | label for=day day: | input type=text name=bday-day id=day | /label | | label for=month month: | select name=bday-month id=month | optionJanuary/option | ... | /select | /label | | label for=yearyear: | input type=text name=bday-year id=year | /label Note: It's also possible to solve that particular case using legendBirthday/legend in a fieldset. Yeah, this is getting very close to fieldset territory. We should be careful about defining new markup just because we don't like the default styling in most browsers. 2. Another use case is, which can't be solved using fieldset and legend, is a table of input elements, like this: The inputs could be checkboxes, text fields or whatever. table thead tr thlabel group= ? Apples/label thlabel group= ? Oranges/label thlabel group= ? Bananas/label tbody tr th scope=rowlabel group= ? Foo/label tdinput name=foo-apple tdinput name=foo-orange tdinput name=foo-banana tr th scope=rowlabel group= ? Bar/label tdinput name=bar-apple tdinput name=bar-orange tdinput name=bar-banana tr th scope=rowlabel group= ? Baz/label tdinput name=baz-apple tdinput name=baz-orange tdinput name=baz-banana /table Yeah, I can see use cases where the data is actually tabular in nature. I'm not sure, however, why the column header can't be used to label the group in this case: | table | thead |tr | th scope=colApples | th scope=colOranges | th scope=colBananas | tbody |tr | th scope=rowFoo | tdinput name=foo-apple | tdinput name=foo-orange | tdinput name=foo-banana |tr | th scope=rowBar | tdinput name=bar-apple | tdinput name=bar-orange | tdinput name=bar-banana |tr | th scope=rowBaz | tdinput name=baz-apple | tdinput name=baz-orange | tdinput name=baz-banana | /table The above markup is HTML 4.01 and effectively labels the all content. Perhaps I'm missing something, but I don't see why the th elements aren't good enough to be treated as group labels in the above case. That said, |class|-style space separation works here too: | table | thead |tr | th scope=col |label group=foo-apple bar-apple baz-appleApples/label | th scope=col |label group=foo-orange bar-orange baz-orangeOranges/label | th scope=col |label group=foo-banana bar-banana baz-bananaBananas/label | tbody |tr | th scope=row |label group=foo-apple foo-orange foo-bananaFoo/label | tdinput name=foo-apple | tdinput name=foo-orange | tdinput name=foo-banana |tr | th scope=row |label group=bar-apple bar-orange bar-bananaBar/label | tdinput name=bar-apple | tdinput name=bar-orange | tdinput name=bar-banana |tr | th scope=row |label group=baz-apple baz-orange baz-bananaBaz/label | tdinput name=baz-apple | tdinput name=baz-orange | tdinput name=baz-banana | /table Still, I think a solution integrated into the tabular markup would be preferable. Any other kind of solution is going to be verbose and awkward. I've come across this issue before, but the only accessible way to solve it that I know of is to add an individual label for every input and then hide it using CSS, so that it's read by screen readers but hidden to visual UAs. That would be verbose and awkward. ;) It could possibly be argued that [assistive] technology should just get smarter, and know that it should associate th elements with the form controls and read them out like labels, but AFAIK, they don't. We should try to get some feedback from people who know more about accessibility than we do. Oops! Should read the whole message before replying. Yeah, I'm not sure screen readers would benefit from new markup when they don't take full
Re: [whatwg] XMLHttpRequest connection limit
On 2-Nov-06, at 4:48 AM, Anne van Kesteren wrote: FYI: The list for raising issues on XMLHttpRequest is public- [EMAIL PROTECTED] Thanks, I'll bring up the topic there as well. Changing the policy on browser connection limits is lightweight enough, though, that whatwg could be very effective at realizing it. On Wed, 01 Nov 2006 17:34:24 +0100, Ted Goddard [EMAIL PROTECTED] wrote: [...] I would like to propose that the HTTP connection limit be standardized at two per user-initiated window. (For instance, Safari is not limited to two connections per browser.) This should be a relatively straightforward change in browser policy (browsers other than Safari, that is), but it is a significant enhancement for Ajax applications. I don't think changing HTTP is really in scope for the XMLHttpRequest specification. Changing the connection limit from two per process to two per window isn't changing HTTP at all. Perhaps you are referring to the following text in RFC 2616 Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. http://www.ietf.org/rfc/rfc2616.txt But what is the single-user client? Is it your router with a single IP address? A single host? A browser process? A browser window? In the case of a highly interactive Ajax application, the client is the window. In other words, there are perfectly valid reasons for allowing more than two HTTP connections from a single process, well within the guidelines for a SHOULD. Regards, Ted. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] XMLHttpRequest connection limit
On 2-Nov-06, at 5:05 AM, Dave Raggett wrote: well how about an XMLBEEPRequest specification then? Beep is kind of like a bidirectional version of HTTP and includes multiplexing capabilities with stream prioritization, see: http://beepcore.org/index.html Beep isn't in widespread use as yet, but is well thought off by the IETF folks. This would require the standardization of a JavaScript API for BEEP, but it would be worthwhile because BEEP is explicitly designed for building new protocols. BEEP messaging would probably map better into JavaScript than a pure socket API. (Would we want to insist that the payload be XML?) Of course, it wouldn't work if it was only implemented in the ICEbrowser ... (so I'm curious what other browser developers think of the idea) Regards, Ted. Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett
Re: [whatwg] [HTML5] 3.10.9. The |abbr| element
I can see what everyones reasoning for not requiring the title (I change my vote :) --- Lachlan Hunt [EMAIL PROTECTED] wrote: James Graham wrote: Lachlan Hunt wrote: Abbreviation expansions should only be supplied when they help the reader to understand the content, not just because the word happens to be an abbreviation. I agree, unless using abbr with no title is useful to get the correct rendering of abbreviations in non-visual media. Using abbr without a title would be useful if it automatically referred to a previous instance with the title attribute. e.g. You could mark up the first occurance as like this abbr title=As Far as I KnowAFAIK/abbr Then, later in the document, you could use it without the title attribute abbrAFAIK/abbr and a UA could allow the user to discover the expansion. This idea is already somewhat supported in the current draft, but requires that it references the defining term of a previously marked up dfn, rather than just another occurrence of the same abbreviation. IMHO, that part of the spec needs fixing. Would dfnabbr title=As Far as I KnowAFAIK/abbr/dfn satisfy this? http://www.whatwg.org/specs/web-apps/current-work/#the-dfn http://www.whatwg.org/specs/web-apps/current-work/#the-abbr -- Lachlan Hunt http://lachy.id.au/ Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates (http://voice.yahoo.com)
Re: [whatwg] XMLHttpRequest connection limit
Although the XMLHttpRequest has the capability of making a DOM available from the resulting text, the client and server don't have to make use of it. One could take the responseText and pass it to eval() if the other end sent JSON. A BEEP API should support any valid use of BEEP, just as XMLHttpRequest actually supports any valid use of HTTP, not just XML transfers. On 11/2/06, Ted Goddard [EMAIL PROTECTED] wrote: On 2-Nov-06, at 5:05 AM, Dave Raggett wrote: well how about an XMLBEEPRequest specification then? Beep is kind of like a bidirectional version of HTTP and includes multiplexing capabilities with stream prioritization, see: http://beepcore.org/index.html Beep isn't in widespread use as yet, but is well thought off by the IETF folks. This would require the standardization of a JavaScript API for BEEP, but it would be worthwhile because BEEP is explicitly designed for building new protocols. BEEP messaging would probably map better into JavaScript than a pure socket API. (Would we want to insist that the payload be XML?) Of course, it wouldn't work if it was only implemented in the ICEbrowser ... (so I'm curious what other browser developers think of the idea) Regards, Ted. Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett
Re: [whatwg] Progressive rendering
On Thu, 02 Nov 2006 20:06:31 +0600, Kornel Lesinski [EMAIL PROTECTED] wrote: I'm thinking that footnotes would be flowed independently of normal content. Browser would flow normal content from the top of the page, and flow footnotes from the bottom of the page at the same time. Break when both meet. The only limitation here is that HTML of footnotes section has to be known in advance to compute styles for footnotes, however printing-while-downloading seems a bit extreme to me. It's not only about printing-while-downloading. It's about the ability to print an arbitrarily long document without consuming infinite memory for DOM. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Browser Signature Standards Proposal
On Thu, 02 Nov 2006 15:55:54 +0600, Michael(tm) Smith [EMAIL PROTECTED] wrote: This is a problem of browser UI design, not of web standards. What do you expect might happen when N different browser vendors each go off on their own and, working in isolation from one another, independently design and implement their own interfaces for handling what we've been discussing? Not in isolation. They should cooperate, of course, and come up with a common solution. But WHAT is not about browser UI, so it's out of scope here. WHAT should not try to compensate the lack of proper browser UI with features in HTML that duplicate features in HTTP/SSL. As I say above, this should be solved at browser UI level. The browsers should make it clear to the user that presenting a client-side certificate to a website is effectively an act of disclosing and proving the user's identity, and that every piece of information he sends to the server (every user action) is non-repudiable. I'd love to hear some concrete suggestions on how you'd propose going about making that all clear to users through the browser UI. I just hope it's not a dialog box with text saying Presenting a client-side certificate to a website is effectively an act of disclosing and proving your identity, and every piece of information you send to the server (every action) is non-repudiable, with a checkbox that says Don't show me this warning next time. Presentation of a client-side certificate should be an explicit action, like entering a password (and, in fact, presentation of some certificates actually requires entering a passphrase). There should be an UI widget, like a button or such, to present your identity to the website, with a choice of identities (certificates) to present. There should be an indicator which shows that you that a client-side certificate is in use. The client-side certificate chosen for one domain should not affect other domains. There should be a way to stop presenting the certificate. By default, this should automatically happen when closing the browser. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
