[Bug 25914] No definition of parsing blob's scheme data

[bugzilla]

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

Anne  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #28 from Anne  ---
Don't check for "parse error", see if the algorithm returns failure.

Also, it may not return a host or port. You should probably check if it's a
relative scheme.

I think you probably just want to parse it and then say something like "return
/parsedURL/'s origin".

But maybe I should just bite the bullet and define origin for all URL schemes
we care about.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 25987] Blob URL parsing / fetching model

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25987
Bug 25987 depends on bug 25914, which changed state.

Bug 25914 Summary: No definition of parsing blob's scheme data
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Indexed DB Transactions vs. Microtasks

[Anne van Kesteren]

On Thu, Jun 19, 2014 at 7:48 AM, Domenic Denicola
 wrote:
> Hmm, it seems pretty related to me. In particular if we say that the IDB 
> microtask bucket always runs after all other microtask buckets, doesn't that 
> achieve the goals?

He said after each microtask (singular).


-- 
http://annevankesteren.nl/

Re: Indexed DB Transactions vs. Microtasks

[Adam Klein]

On Fri, Jun 6, 2014 at 5:51 PM, Jonas Sicking  wrote:

> On Thu, Jun 5, 2014 at 12:59 PM, Joshua Bell  wrote:
> > case 1:
> >
> >   var tx;
> >   Promise.resolve().then(function() {
> > tx = db.transaction(storeName);
> > // tx should be active here...
> >   }).then(function() {
> > // is tx active here?
> >   });
> >
> > For case 1, ISTM that "yes" matches the IDB spec, since control has not
> > returned to the event loop while the microtasks are running.
> Implementations
> > appear to agree.
>
> Yes. I believe that this is what the spec currently calls for.
>
> However I think it would actually be good to change the spec to say
> that the transaction is closed at the end of the current microtask.
>
> When we originally designed microtasks for Mutation Observers, one of
> the goals was to ensure that there were not accidental
> interdependencies between different event handlers to the same event.
> By flushing end-of-microtask work after each event handler you ensure
> that each event handler gets a clean slate.
>
> I realize that this is a backwards-incompatible change. However it
> seems pretty unlikely to break any existing content. So it'd be nice
> to give it a try.


While I agree that the original microtask intent would suggest we change
this, and I concur that it seems unlikely to break content, I worry about
the spec and implementation complexity that would be incurred by having to
support the notion of "at the end of the current microtask". It suggests
one of:

1. A new task queue, which runs after microtasks (nanotasks?)
2. The ability to put tasks at the start of the microtask queue rather than
at the end

(1) seems like a bad idea for a variety of reasons, not least of which that
it would soon lead us to need picotasks once an actor other than IDB saw a
need for it.

(2) strikes me as just plain hard to reason about. And again, if anyone
other than IDB tried to use that capability, it would become problematic.

Code running at end-of-microtask already has to deal with being in a
slightly different environment than "normal" event-handling code. I think
it might be worth avoiding additional complexity to make this quirk one of
those caveats.

- Adam

CORS, Preflight caching and Access-Control-Policy-

[Garet Claborn]

I was thinking about CORS and preflight caching lately, and came upon
these previous discussions:

http://lists.w3.org/Archives/Public/public-appformats/2008May/0039.html
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0228.html

Presumably there are a numerous others which I haven't read; so
apologies if my suggestion has been brought up previously. Still, I
thought to present a solution strategy in case there's anything of use
in it.

( 1. )
The simplest idea is to add mask and depth headers:

Access-Control-Policy-Path: /path/to/api
Access-Control-Policy-Mask-Path: /private
Access-Control-Policy-Mask-Path: /product/partner
Access-Control-Policy-Mask-Depth: 2

In this scheme, the intent would be that, assuming * for
Access-Control, and URL which is up to two levels more-deeply nested
than /path/to/api is publicly available and preflights may be cached
as a group.

So, this includes URLs such as
/path/to/api/products
/path/to/api/products/red  - but not
/path/to/api/products/red/small

Additionally this imposes that, regardless of depth, the
access-control does not apply to any url on or in
/path/to/api/private or
/path/to/api/product/partner

In this scheme, both Mask-Path and Mask-Depth are relative to the
Policy-Path. By applying a list of mask sub-paths and restricting
depth, security can be relaxed for only a small range of endpoints.


( 2. )
As a possible an extension to this, we could introduce sequential sets
where each Access-Control-* header refers to the Access-Control header
which appears most recently before it.

i.e.

Access-Control-Scheme: PUBLIC_API
Access-Control-Allow-Origin: *
Access-Control-Policy-Path: /path/to/api
Access-Control-Policy-Mask-Path: /private
Access-Control-Policy-Mask-Depth: 2

Access-Control-Scheme: PRIVATE_API
Access-Control-Allow-Origin: scheme://internal.host:port
Access-Control-Policy-Path: /path/to/api/private
Access-Control-Policy-Mask-Path: /private
Access-Control-Policy-Mask-Depth: 5


( 3 )

If elements of the prior two concepts were acceptable, it would be
possible for either an endpoint or a client-context (ex: a web service
or a page calling some ajax) to define a single broker for the given
service. This could be by either the calling 'page' or the service
defining a header:

Access-Control-Scheme: PUBLIC_API
Access-Control-Broker: scheme://internal.host:port/[optional]


The broker can in turn only assign access control to paths more deeply
nested than itself or sub-domains extending further left toward the
scheme (scheme://sub.internal.host:port).

In this case, the "Access-Control-Scheme" must match one provided by
the broker or else access will default to the current practice based
on return headers. If the service returns an Access-Control-Broker,
then a second preflight would be initiated. It is preferred that a
broker is known for clients implementing an API, or may be queried
somehow, allowing them to avoid access-based interaction with
services.

This should allow larger organizations to have fine-grained control
over multi-variant ranges and has the benefit of keeping preflight
contained to dedicated areas which may have the side-effect of
increasing security over current methods. At the same time, scripting
services becomes more convenient for UA which support this but are not
less capable of defining their own Access-Control per-endpoint.

One further note, any access-control broker should only be allowed to
specify a scheme for sub-domains of it's own host. Any path-based
broker should not be allowed to specify a scheme outside of it's
current host, including sub-domains. This stated with the idea that
the root-most URLs shall hold precedence but overrides are possible
only for deeper URL structures.

Thus service.domain.com/team1/api cannot define a broker to
service.domain.com/team2/api or
subsrv.service.domain.com/team1/api


Some aspects of this proposal could most likely be enhanced and/or
simplified. There's quite a bit I do not know about the current state
of discussion in this area. Simply, I hope that we'll eventually have
a cleaner interface towards securing CORS and automating access across
networks.

Cheers, -Garet Claborn
ga...@approach.im

[Bug 26142] New: execCommand() should work on and .

[bugzilla]

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

Bug ID: 26142
   Summary: execCommand() should work on  and .
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: HTML Editing APIs
  Assignee: a...@aryeh.name
  Reporter: andyearnshaw...@gmail.com
QA Contact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org

Currently, the editing spec defines that something is editable when the
following is true[1]:

> Something is editable if it is a node; it is not an editing host; 
> it does not have a contenteditable attribute set to the false state; 
> its parent is an editing host or editable; and either it is an HTML 
> element, or it is an svg or math element, or it is not an Element 
> and its parent is an HTML element.

I think this should be expanded to include HTML form fields that can accept
text input.  This is already the behaviour in Chrome and Internet Explorer for
some commands, though Firefox throws an error[2].

Although the majority of formatting commands might be useless, insertText, 
delete and forwardDelete could be useful for JavaScript based IMEs/virtual
keyboards, along with cut, copy, paste, undo, redo and selectAll from the
miscellaneous commands.  

There's also a use case for editors that switch between a designmode enabled
iframe for formatted editing and a text area for raw editing - these editors
would be able to reuse a lot of the same very short code (especially in the
case of "insertText") without having to slice, concat and set the element
values.

[1]: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editable
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1027560

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: CORS, Preflight caching and Access-Control-Policy-

[Anne van Kesteren]

On Tue, Jun 17, 2014 at 11:27 PM, Garet Claborn  wrote:
> Some aspects of this proposal could most likely be enhanced and/or
> simplified. There's quite a bit I do not know about the current state
> of discussion in this area. Simply, I hope that we'll eventually have
> a cleaner interface towards securing CORS and automating access across
> networks.

I might be missing something, but I don't see how these secure against
the IIS bug.

We could ignore that bug and put a warning sign in the specification,
as Ian suggested back then. Is there sufficient usage of CORS to add
the complexity? And, are server administrators okay with this being
possible?

The most attractive solution would be to do an OPTIONS * fetch of
sorts against a given host. Because basically the entire preflight
thing is a dance to figure out if the server knows about CORS.


-- 
http://annevankesteren.nl/

[Bug 26143] New: Create request early on

[bugzilla]

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

Bug ID: 26143
   Summary: Create request early on
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: ann...@annevk.nl
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

Refactor XMLHttpRequest to create a request early on and just fill in the
variables there rather than keep them around separately.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 26014] FormData.append with a string value appears not specified

[bugzilla]

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

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
You are receiving this mail because:
You are on the CC list for the bug.

30-day Public Review for Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0 - ends July 19th

[Paul Knight]

OASIS members and other interested stakeholders,

The OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings
(AMQP-BINDMAP) TC [1] members have recently approved a Committee
Specification Draft (CSD) and submitted it for 30-day public review:

Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version
1.0
Committee Specification Draft 01 / Public Review Draft 01
10 June 2014

Overview:

The AMQP WebSocket Binding specification defines a mechanism for tunneling
an AMQP connection over a WebSocket transport. It is applicable as an
approach for general firewall tunneling and for Web browser messaging
scenarios.

TC Description:

The purpose of the AMQP Bindings and Mappings (AMQP-BINDMAP) TC is to
define bindings of AMQP 1.0 core protocol to underlying transports other
than TCP, to define mappings of the AMQP 1.0 core protocol to existing
well-known programming APIs, and to define representations of the AMQP 1.0
message format in existing well-known languages.

For more information, see the TC Charter and FAQ.

Public Review Period:

The public review starts 20 June 2014 at 00:00 GMT and ends 19 July 2014 at
23:59 GMT.

This is an open invitation to comment. OASIS solicits feedback from
potential users, developers and others, whether OASIS members or not, for
the sake of improving the interoperability and quality of its technical
work.

URIs:

The prose specification document and related files are available here:

Editable source (Authoritative):
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.doc

HTML:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.html


PDF:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.pdf

ZIP distribution file (complete):

For your convenience, OASIS provides a complete package of the prose
document and related files in a ZIP distribution file. You can download the
ZIP file here:

http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.zip

Additional information about the specification and the OASIS Advanced
Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC can
be found at the TC's public home page:

https://www.oasis-open.org/committees/amqp-bindmap/

Comments may be submitted to the TC by any person through the use of the
OASIS TC Comment Facility which can be used by following the instructions
on the TC's "Send A Comment" page, or directly at:

https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=amqp-bindmap

Comments submitted by TC non-members for this work and for other work of
this TC are publicly archived and can be viewed at:

https://lists.oasis-open.org/archives/amqp-bindmap-comment/

All comments submitted to OASIS are subject to the OASIS Feedback License,
which ensures that the feedback you provide carries the same obligations at
least as the obligations of the TC members. In connection with this public
review of "Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB)
Version 1.0", we call your attention to the OASIS IPR Policy [2] applicable
especially [3] to the work of this Technical Committee. All members of the
TC should be familiar with this document, which may create obligations
regarding the disclosure and availability of a member's patent, copyright,
trademark and license rights that read on an approved OASIS specification.

OASIS invites any persons who know of any such claims to disclose these if
they may be essential to the implementation of the above specification, so
that notice of them may be posted to the notice page for this TC's work.

== Additional references:

[1] OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings
(AMQP-BINDMAP) TC
https://www.oasis-open.org/committees/amqp-bindmap/

[2] https://www.oasis-open.org/who/intellectualproperty.php

[3] https://www.oasis-open.org/committees/amqp-bindmap/ipr.php
https://www.oasis-open.org/policies-guidelines/ipr#s10.2.2
RF on RAND Mode

-- 
Paul Knight   - Tel: +1 781-861-1013
OASIS  - Advancing open standards for the
information society
Document Process Analyst