[Bug 16302] possible unnecessary insertion of U+0020 SPACE in mime type expression

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16302

Michael[tm] Smith  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NEEDSINFO

--- Comment #9 from Michael[tm] Smith  2012-10-06 03:55:30 UTC ---
Not sure what action if any I need to take on this. Re-assign to one of the W3C
XHR editors?

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[Vincent Scheib]

For those with threaded email clients, at Arthur's suggestion I've filed an
issue to track this topic.
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0040.html.


On Tue, Oct 2, 2012 at 4:50 PM, Rick Waldron  wrote:

>
> On Tuesday, October 2, 2012 at 6:14 PM, Florian Bösch wrote:
>
> Speaking from the point of view of a web developer having to use this
> feature. It is quite painful having to perform an end-run about failure
> modes that are unspecified, undocumented and a moving target. In my
> understanding, this is precisely the intent of a specification, to avoid
> such incompatibilities and headaches for developers.
>
> 1) If it is intended that additional failure modes are to be randomly
> introduced by vendors, then this should be made explicit in the
> specification.
> 2) If such wording is added to the specification, I don't see any residual
> value in the specification since any developer will have to perform the
> trial&error endrun repeatedly patching things up as the failure modes move,
> we can just skip the specification altogether.
>
> As I read through this thread, I was thinking exactly the same thing that
> Florian has said here. Looking forward to real feature completion ;)
>
> Rick
>
>
>
> On Wed, Oct 3, 2012 at 12:08 AM, Vincent Scheib  wrote:
>
> I agree that pointer lock is quite useful outside of fullscreen, but
> before attempting to codify that in the specification I would want buy
> in from other browser vendors. I can appreciate an argument to remain
> restricted to fullscreen.
>
> Application developers can automatically escalate to requesting
> fullscreen upon the first pointerlockerror given the current behavior
> of FireFox.  It's more code, but not a burdensome amount.
>
> If future abuse of the feature appears on the web, there may be other
> criteria used by browsers to suppress the feature. The specification
> states "The user agent determines if pointer lock state will be
> entered" which allows for browsers to add additional constraints. I
> could word that more explicitly if it would help. But my intent was
> specifically to allow browsers to use additional discretion. E.g. see
> the 'A full screen approach' in the specification's non-normative
> security section. Also, note that Chrome allows users to enter global
> suppression of the feature via the content settings preference, a
> override accepted similarly by the specification.
>
> Also, a small nit regarding "chrome requires the pointer lock request
> to fail if not resulting from a user interaction target". Chrome
> allows pointer lock without any user gesture if requested when in
> fullscreen. Out of fullscreen a user gesture (click, key press) is
> required. See
> http://www.chromium.org/developers/design-documents/mouse-lock
>
> On Tue, Oct 2, 2012 at 2:59 PM, Florian Bösch  wrote:
> > On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay 
> > wrote:
> >>
> >> On 10/02/2012 11:55 PM, Florian Bösch wrote:
> >>>
> >>> I'd like to point out that vendors are using additional failure
> criteria
> >>> to determine if pointerlock succeeds that are not outlined in the
> >>> specification. Firefox uses the fullscreen change event to determine
> >>> failure and chrome requires the pointer lock request to fail if not
> >>> resulting
> >>> from a user interaction target. I think that Firefoxes interpretation
> is
> >>> less useful than Chromes,
> >>
> >> But safer
> >
> > Also not in conformance to the specification (hence a bug).
> Additionally, it
> > will make it really difficult to follow the specification since
> > non-fullscreen mouse capture is specifically intended by the
> specification
> > by not adding that failure mode *to* the specification (there's a fairly
> > long discussion on this on the chrome ticket for pointerlock resulting in
> > what Chrome does now).
> >
> >
> >>  and that Chromes interpretation should be amended
> >>>
> >>> to the spec since it seems like a fairly good idea.
> >>>
> >> I'm not yet convinced that it is safe enough.
> >> Also, it is not properly defined anywhere.
> >
> > So either Chrome is also implementing in conformance to the
> specification,
> > or the specification is changed. Ipso facto, the specification is not
> > complete since I don't think Chrome will drop this failure mode, and it
> > seems like Firefox is intending to follow Chromes lead because otherwise
> it
> > wouldn't be possible to implement non-fullscreen pointerlock.
>
>
>
>

RE: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor

[Israel Hilerio]

On Wednesday, October 3, 2012 6:50 PM, Jonas Sicking wrote:

>On Wed, Oct 3, 2012 at 9:48 AM, Joshua Bell  wrote:
>> On Wed, Oct 3, 2012 at 1:13 AM, Odin Hørthe Omdal  wrote: 
>>>
>>> So, at work and with the spec in front of me :-)
>>>
>>>
>>> Odin claimed:
>>>
 There is a note near the algorithm saying something to that point, 
 but the definite text is up in the prose "let's explain IDB" section IIRC.
>>>
>>>
>>> Nope, this was wrong, it's actually right there in the algorithm:
>>>
>>>
>>> >> -for-iterating-a-cursor>
>>>
>>> # If direction is "prevunique", let temp record be the last record in 
>>> # records which satisfy all of the following requirements:
>>> #
>>> #   If key is defined, the record's key is less than or equal to key.
>>> #   If position is defined, the record's key is less than position.
>>> #   If range is defined, the record's key is in range.
>>> #
>>> # If temp record is defined, let found record be the first record in 
>>> # records whose key is equal to temp record's key
>>>
>>> So it'll find the last "foo", and then, as the last step, it'll find 
>>> the top result for "foo", giving id 1, not 3. The prevunique is the 
>>> only algo that uses that temporary record to do its search.
>>>
>>> I remember this text was somewhat different before, I think someone 
>>> clarified it at some point. At least it seems much clearer to me now 
>>> than it did the first time.
>>
>>
>> Since I have it the link handy - discussed/resolved at:
>>
>> http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0599.htm
>> l
>>
>>>
>>> Israel Hilerio said:

 Since we're seeing this behavior in both browsers (FF and Canary) we 
 wanted to validate that this is not by design.
>>>
>>>
>>> It would bet several pennies its by design, because the spec needs 
>>> more framework to explain this than it would've needed otherwise. 
>>> What that exact design was (rationale et al) I don't know, it was 
>>> before my time I guess. :-)
>>
>>
>> Yes, the behavior in Chrome is by design to match list consensus.
>>
>> (FWIW, it's extra code to handle this case, and we've had bug reports 
>> where we had to point at the spec to explain that we're actually 
>> following it, but presumably this is one of those cases where someone 
>> will be confused by the results regardless of which approach was 
>> taken.)
>
>Yes, this was very intentional. The goal was that reverse iteration would 
>always return the same set of rows as forward iteration, just in reverse 
>order. This seemed like the most easily understandable and >explainable 
>behavior.
>
>Consider for example a UI which renders an address book grouped by first 
>letter and showing the first name in that letter. It would seem strange if the 
>user changing z-a or a-z shows different names.
>
>/ Jonas

Thanks everyone for the explanations.  Jonas, your last example clarified 
things for me.  We'll file a bug on our side.

Israel

Re: CfC: publish FPWD of Push API; deadline October 12

[Jonas Sicking]

Hi All,

As usual, this is not the official mozilla position, as there is no such thing.

Several of us at at mozilla has been looking at push quite a bit
lately. We still don't have a clear idea of exactly what we think a
push system should look like. However we are concerned that a system
like the one in http://dvcs.w3.org/hg/push/raw-file/default/index.html
would be hard to implement at internet scale in a manner which keeps
it stable enough to be reliable for webapp developers.

First of all the fact that a single message from the application
server to the notification server can cause millions of messages from
the notification server to end-user devices makes us concerned that
it's too easy to DoS the notification server.

Second, using a message passing mechanism puts a lot of responsibility
on the notification server to never lose any messages. In the event of
a server crash or server overload the current solution seems to have
no way for the notification server to avoid dataloss.

As points of reference, both Apple and Google has been creating
similar Push solutions for iOS and Android respectively. Both of these
systems have struggled with scalability. The result for Apple was to
delay their solution for a year. The result for google was to
deprecate the system and they are working on designing something new.
The system proposed here is more powerful than both Apple's and
Google's system.

Finally we also have some security concerns. The messages passed
through the current API will likely very often end up being cleartext.
Application developers certainly can make sure to always encrypt the
messages on the server and then manually decrypt them in the client
(using for example the new crypt API). The API already requires
passing two cryptographically strong tokens to the API. Requiring
developers to also decrypt the message in the client means involving a
third cryptographically strong token. This is a lot for developers to
get right and if they don't, there's a risk of privacy or even
security problems.

These are all hard problems to solve, and so far we do not have a
counter proposal. But I figured that I should raise these concerns
since they seem relevant.

I'm also very aware that in the past I have pointed at message-passing
based protocols in the past as mozilla experiments. However lately we
have started at looking at alternatives due to the scalability issues
discussed above. Letting people know about this is another reason I'm
writing this email.

But since we don't have a counter proposal, and since I personally
generally think that people should be allowed to publish working
drafts, I don't oppose this FPWD.

But I can't say with certainty at this time that this is an API that
we're planning on implementing.

/ Jonas

On Fri, Oct 5, 2012 at 4:38 AM, Arthur Barstow  wrote:
> The Push API Editors would like to publish a First Public Working Draft of
> their spec and this is a Call for Consensus to do so, using the following
> spec as the basis .
>
> This CfC satisfies the group's requirement to "record the group's decision
> to request advancement".
>
> By publishing this FPWD, the group sends a signal to the community to begin
> reviewing the document. The FPWD reflects where the group is on this spec at
> the time of publication; it does _not_ necessarily mean there is consensus
> on the spec's contents.
>
> If you have any comments or concerns about this CfC, please reply to this
> e-mail by October 12 at the latest. Positive response is preferred and
> encouraged and silence will be considered as agreement with the proposal.
>
> -Thanks, AB
>

RE: publish WD of Shadow DOM; deadline Oct 10

[Carr, Wayne]

Yes, publish!

People often don't know to look at the editor's draft and they wind up looking 
at docs the WG has gone beyond.  So, we should publish regular WDs where the 
editor's draft has changed as often as possible.

>-Original Message-
>From: Arthur Barstow [mailto:art.bars...@nokia.com]
>Sent: Wednesday, October 03, 2012 3:39 PM
>To: public-weba...@w3c.org
>Subject: CfC: publish WD of Shadow DOM; deadline Oct 10
>
>Dimitri would like to publish a new Working Draft of Shadow DOM and this is a
>Call for Consensus to do so, using the following document as the basis
>file/tip/publish/shadow/index.html>.
>
>Agreement to this proposal: a) indicates support for publishing a new WD; and 
>b)
>does not necessarily indicate support of the contents of the WD.
>
>If you have any comments or concerns about this proposal, please reply to this 
>e-
>mail by October 10 at the latest.
>
>Positive response to this CfC is preferred and encouraged and silence will be
>assumed to mean  agreement with the proposal.
>
>-Thanks, AB
>
>

Re: CfC: publish LCWD of Pointer Lock; deadline Oct 4

[Vincent Scheib]

Done,
May user agents apply additional restrictions on entering pointer
lock? [1] created and added to status section of specification.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297

On Fri, Oct 5, 2012 at 5:32 AM, Arthur Barstow  wrote:
> On 9/27/12 8:26 AM, ext Arthur Barstow wrote:
>>
>> This is a Call for Consensus to publish a LCWD of Pointer Lock using the
>> following document as the basis for the LC
>> .
>>
>> This CfC satisfies the group's requirement to "record the group's decision
>> to request advancement" for this LCWD. Note the Process Document states the
>> following regarding the significance/meaning of a LCWD:
>>
>> [[
>> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
>>
>> Purpose: A Working Group's Last Call announcement is a signal that:
>>
>> * the Working Group believes that it has satisfied its relevant technical
>> requirements (e.g., of the charter or requirements document) in the Working
>> Draft;
>>
>> * the Working Group believes that it has satisfied significant
>> dependencies with other groups;
>>
>> * other groups SHOULD review the document to confirm that these
>> dependencies have been satisfied. In general, a Last Call announcement is
>> also a signal that the Working Group is planning to advance the technical
>> report to later maturity levels.
>> ]]
>>
>> The proposed LC review period is 4 weeks.
>>
>> If you have any comments or concerns about this CfC, please send them to
>> public-webapps@w3.org by October 4 at the latest. Positive response is
>> preferred and encouraged and silence will be considered as agreement with
>> the proposal.
>
>
> Hi All - given the discussion in the "Is Pointer Lock feature complete i.e.
> LC ready?" thread (see f.ex. [1] and follow-ons), it appears we don't yet
> have consensus the spec is ready for LCWD.
>
> As such, I recommend we work toward consensus on the issues raised in this
> thread before proceeding with the LCWD. To help people track the issues
> raised, perhaps it would be helpful to create a related bug [2] (and to add
> a link to [2] in Status of the Document section).
>
> -AB
>
> [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0010.html
> [2]
> https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Pointer%20Lock&resolution=---
>
>
>
>

[Bug 19297] New: May user agents apply additional restrictions on entering pointer lock?

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297

   Summary: May user agents apply additional restrictions on
entering pointer lock?
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Pointer Lock
AssignedTo: sch...@chromium.org
ReportedBy: sch...@chromium.org
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


The pointer lock spec Working Draft 29 May 2012 is written specifying several
requirements to enter mouse lock, and leaving user agents to add additional
constraints to prevent nuisance and enforce security policies.  Specifically
the Element requestPointerLock method section [1] states "The user agent
determines if pointer lock state will be entered" and the Security section [2]
includes varying policies including 'A conservative approach' requiring user
gestures and 'A full screen approach' requiring full screen.

Initial implementations have added additional constraints beyond those
explicitly listed in [1]. Firefox 14 introduced pointer lock requiring that
fullscreen be entered and confirmed and that the pointer lock target match the
fullscreen element. Chrome 22 introduced pointer lock with a more permissive
policy, allowing pointer lock of any element after fullscreen has been
confirmed. Chrome also permitted pointer lock outside of fullscreen if it was
requested via a user gesture.

Concern was raised in public-webapps discussion [3] that all user agents should
use the same policy and that be incorporated into the specification.

[1] http://www.w3.org/TR/2012/WD-pointerlock-20120529/#methods
[2] http://www.w3.org/TR/2012/WD-pointerlock-20120529/#security
[3] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0010.html

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

[Tab Atkins Jr.]

On Fri, Oct 5, 2012 at 4:22 AM, Henri Sivonen  wrote:
> On Tue, Aug 21, 2012 at 9:17 PM, Tab Atkins Jr.  wrote:
>> Similarly, some of the a11y folks have recently been talking about
>> applying aria-* attributes via CSS, again, because it's just so much
>> more convenient.
>
> What's the rationale for this radical change of mind? Back when ARIA
> was introduced, the a11y wanted to specifically avoid the introduction
> of reflecting DOM properties for the ARIA attributes in order to force
> authors to use setAttribute() so that JAWS could retrieve the ARIA
> data via COM in ARIA-unaware legacy IE.
>
> If the a11y folks were so serious about being compatible with IE7 a
> few years ago, why isn't there now similar concern that applying ARIA
> by a new mechanism would leave behind IE10 and earlier, which,
> presumably, currently have the same sort of expected enterprise
> lifespan as IE7 had when aria was introduced?

I have no idea.  However, it seems irrelevant for my proposal - as
currently specified, CAS desugars into setAttribute calls.

~TJ

Re: CfC: publish LCWD of Pointer Lock; deadline Oct 4

[Arthur Barstow]

On 9/27/12 8:26 AM, ext Arthur Barstow wrote:
This is a Call for Consensus to publish a LCWD of Pointer Lock using 
the following document as the basis for the LC 
.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a 
LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

The proposed LC review period is 4 weeks.

If you have any comments or concerns about this CfC, please send them 
to public-webapps@w3.org by October 4 at the latest. Positive response 
is preferred and encouraged and silence will be considered as 
agreement with the proposal.


Hi All - given the discussion in the "Is Pointer Lock feature complete 
i.e. LC ready?" thread (see f.ex. [1] and follow-ons), it appears we 
don't yet have consensus the spec is ready for LCWD.


As such, I recommend we work toward consensus on the issues raised in 
this thread before proceeding with the LCWD. To help people track the 
issues raised, perhaps it would be helpful to create a related bug [2] 
(and to add a link to [2] in Status of the Document section).


-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0010.html
[2] 
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Pointer%20Lock&resolution=---

CfC: publish FPWD of Push API; deadline October 12

[Arthur Barstow]

The Push API Editors would like to publish a First Public Working Draft 
of their spec and this is a Call for Consensus to do so, using the 
following spec as the basis 
.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement".


By publishing this FPWD, the group sends a signal to the community to 
begin reviewing the document. The FPWD reflects where the group is on 
this spec at the time of publication; it does _not_ necessarily mean 
there is consensus on the spec's contents.


If you have any comments or concerns about this CfC, please reply to 
this e-mail by October 12 at the latest. Positive response is preferred 
and encouraged and silence will be considered as agreement with the 
proposal.


-Thanks, AB

Re: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[Arthur Barstow]

On 10/5/12 7:06 AM, ext Bryan Sullivan wrote:

- more info on serverProtocols


It still seems like the set of valid strings will need to be defined. 
Perhaps at this point, it would be sufficient if a related Issue Block 
was added. (I'll ask Mike to create a Bugzilla component for the spec.)



- additional references (I still need to update the respec biblio)


Yes, please do as this must be fixed before the FPWD is actually 
published in /TR/. (Robin provided some related info in [1].)



I would like to request a CFC for FPWD publication, if there are no more
substantive comments on the updated version.


I will start a CfC for the FPWD.

(If you haven't prepared a doc for publication as a TR, please see 
<http://www.w3.org/wiki/Webapps/SpecEditing> for some information about 
the PubRules and such.)


-Thanks, AB

[1] <http://krijnhoetmer.nl/irc-logs/webapps/20121005>



* serverProtocols - what are the expectations for the "valid" set of
values; where are they specified?


Good question. We need some means of registration of well-known services
so the protocols can be recognized.

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

[Henri Sivonen]

On Tue, Aug 21, 2012 at 9:17 PM, Tab Atkins Jr.  wrote:
> Similarly, some of the a11y folks have recently been talking about
> applying aria-* attributes via CSS, again, because it's just so much
> more convenient.

What's the rationale for this radical change of mind? Back when ARIA
was introduced, the a11y wanted to specifically avoid the introduction
of reflecting DOM properties for the ARIA attributes in order to force
authors to use setAttribute() so that JAWS could retrieve the ARIA
data via COM in ARIA-unaware legacy IE.

If the a11y folks were so serious about being compatible with IE7 a
few years ago, why isn't there now similar concern that applying ARIA
by a new mechanism would leave behind IE10 and earlier, which,
presumably, currently have the same sort of expected enterprise
lifespan as IE7 had when aria was introduced?

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[Bryan Sullivan]

Hi all,

With Eduardo's help I updated the spec [1] for Art's comments as below.
Here is a summary from the commit:
- security section text
- service bindings text
- more info on serverProtocols
- updated the definitions
- additional references (I still need to update the respec biblio)
- example code and flow in the Framework section
- general editorial cleanup

I would like to request a CFC for FPWD publication, if there are no more
substantive comments on the updated version. We look forward to a good
discussion on this API during TPAC and would like that to occur on a FPWD
basis.

Thanks
Bryan Sullivan



[1] http://dvcs.w3.org/hg/push/raw-file/default/index.html

On 9/27/12 3:09 AM, "EDUARDO FULLEA CARRERA"  wrote:

>On 27 sep 2012 at 05:51:51, SULLIVAN, BRYAN L wrote:
>> Thanks for the feedback, Art. I've responded below. I will work on a new
>> draft to address as many of your comments as I can.
>>
>> Thanks,
>> Bryan Sullivan | Service Standards | AT&T
>> +1-425-580-6514
>>
>> Arthur Barstow wrote on September 26, 2012 11:59 AM:
>>> specs before TPAC: CfC start deadline is Oct 15]
>>>
>>> On 9/26/12 1:49 PM, ext SULLIVAN, BRYAN L wrote:
 We've previously called for any comments to the current Push API draft
>>> [1], and would like to promote it to FPWD before TPAC. We haven't
>>> received any substantive comments as far as I know, which tells me that
>>> it could be in good shape for publication. With the addition of
>>> Telefonica (Eduardo) as co-editor and simplification / better alignment
>>> with proposals for B2G / Firefox OS, I believe we are in shape for FPWD
>>> now. So if I could request a CFC for publication as FPWD before Oct 15,
>>> that would be our preference.

 Alternatively we can put this on the agenda for TPAC and
>>> discuss/promote it then as possible. But in the absence of substantive
>>> comments (which tells me we have addressed most of the comments on the
>>> first ED), I think we should be ready for FPWD.

 [1] http://dvcs.w3.org/hg/push/raw-file/default/index.html
>>>
>>> The requirements for FPWD are relatively loose but because the
>>> publication of a FPWD starts a Call for (IP) Exclusions, it is helpful
>>> for some reviewers if the breath of the spec is mostly complete,
>>> although the depth can certainly be lacking.
>>>
>>> What is your view on the set of features/scope? Is the ED covering most
>>> of the scope? If there are any high priority features missing, what are
>>> they?
>>>
>>
>> IMO the ED is covering the scope well. I don't think any high priority
>>features
>> are missing. We removed some of the earlier proposed features in the
>> current draft.
>
>I agree we are covering most of the scope. It is a matter of adding more
>depth.
>>
>>> Based on a very quick scan, I noticed:
>>>
>>> * The Privacy and Security section is empty and I think it would be
>>> helpful if some additional informational was added before FPWD.
>>>
>>
>> I have some text I can add for that.
>>
>>> * The Specific Service Bindings section is empty. It seems like this
>>> should have some information before FPWD, especially if it is going to
>>> be a normative section. (Are some of these "bindings" specified outside
>>> the W3C?)
>>>
>>
>> I think this was intended to be an informative section, unless at least
>> one push service is proposed to be standardized. I can provide
>> informative text for SMS, SIP, and OMA Push. Browser-specific push
>> serices could also be included.
>>
>>> * Push Framework - it appears this section should be marked as
>>> non-normative. I think it would be helpful if some type of flow diagram
>>> was included as well as example application code to use the API
>>> (although this non-normative info is not necessarily a blocker for
>>> FPWD).
>>>
>>
>> Agreed, this should be informative.
>
>Yes, it is intended to be an informative section. Flow diagram would
>definitely be useful, though not necessary to go to FPWD
>>
>>> * serverProtocols - what are the expectations for the "valid" set of
>>> values; where are they specified?
>>>
>>
>> Good question. We need some means of registration of well-known services
>> so the protocols can be recognized.
>>
>>> Some editorial comments ...
>>>
>>> * Define "Web Intent Push Service provider", "Push server" and "webapp"
>>> or add a link to the definitions.
>>>
>>
>> Will do.
>>
>>> * Update the references that are out of date (e.g. HTML5).
>>>
>>
>> Will do. This is respec.js magic.
>>
>>> * Not clear what onopen event is since it isn't part of the PushService
>>> API
>>>
>>
>> I think this may have been an omission, or we were thinking to use a
>>listener
>> for changes to the readyState as the "open" event. I will check with
>>Eduardo
>> on that.
>
>I think for the time being we can remove onopen as there is no other
>reference to it in the draft.
>
>>
>>> -Thanks, Art
>>>
>>
>
>
>
>Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>nuestra polít

[Bug 19283] New: Investigate IDNA2003 separators

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19283

   Summary: Investigate IDNA2003 separators
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: URL
AssignedTo: m...@w3.org
ReportedBy: math...@qiwi.be
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Continuing the discussion in https://github.com/bestiejs/punycode.js/issues/11,
I wrote a simple test that sets URLs with IDNA2003 separators U+002E, U+3002,
U+FF0E, U+FF61 as the `src` of an `iframe` element in memory, and then returns
the resulting normalized `src`.

Chrome, Safari, Firefox:

http://xn--maana-pta.com/
http://xn--maana-pta.com/
http://xn--maana-pta.com/
http://xn--maana-pta.com/

Opera:

http://mañana.com/
http://mañana.com/
http://mañana.com/
http://mañana.com/

It seems all browsers tested so far support these separators for backwards
compatibility. I haven’t tested IE yet, or older versions of the other
browsers.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.