Re: [web-nfc] Review fixes for #44.

Hi Mark,

Thank you for the re-review.

On Tue, Sep 15, 2015 at 10:08 PM, Mark James <mrj@rbate.com> wrote:

> Some comments on the current draft
> <https://rawgit.com/zolkis/web-nfc/gh-pages/index.html>:
>
>    1. Both "UA" (user agent) and "suspended" should be better defined.
>
> I think UA is not explicitly defined any more, see also
https://html.spec.whatwg.org.
Yes, "suspended" should perhaps be more exactly defined.


>
>    1.
>    2. Some spelling mistakes:
>
>
Thanks, I have fixed these now.

>
>    1.
>    Improvements can also be made to some of the English, but that can
>    wait until a pre-release polish.
>
>
This is the pre-release polish :).

>
>    1.
>    2. What's the rationale for the 10s limit on a push timeout? I'm
>    interested in an app where a user can enter information into a webpage
>    that's continuously primed to send that information (directly or as a URL)
>    to an NFC peer, without a "send" button having to be pushed prior. To make
>    this work with the current spec, I'd have to code a push loop. What's the
>    problem with an infinite timeout when a push is only active while its page
>    is open and in focus, and when cancelPush can be called?
>
>
To keep the user aware of (close in time to) the NFC operation that
requires a user gesture of tapping, usually part of a user interaction
which has a specific NFC target (specific tag or specific peer), and
eventually a user permission bound to that gesture and the related NFC
operation. It is a fire-once operation also in lower level NFC (at protocol
level).

If your use case, if the target is any peer, and if it can be solved by a
loop, what is the problem?

Maybe unrelated, but we currently don't support Host Card Emulation.


>
>
>
> This version of the spec does not need to be perfect, but it
> should be a good base for the next iteration of the experimental
> implementation.
>
>
> It's essential that the experimental implementation allow "http" push and
> watch schemes, as suggested in Section 7.4: " Browsers may ignore this
> rule for development purposes only." Otherwise developers would have to
> develop and test on full web-servers with certificates.
>

A valid point - nevertheless an implementation detail and IMO it should not
be standardized by the spec itself.


>
>
> Given this, perhaps it's best for the semantics of the "*" and "https"
> watch schemes to differ, instead of the current spec's "In a *scheme*'*' will
> match only the allowed 'https' scheme." ( Section 11.4.2). The former
> should promiscuously allow an http development mode, while the latter can
> enforce production security.
>
>
Yes, this could be done, but I think we should not try to solve this in the
spec. Using NFC in an insecure context would need a different permission
and prompting policy, but it has been fixed in early days of the spec that
secure contexts are required. I think you may create an issue for tracking
this and for eliciting a discussion on the topic.

Best regards,
Zoltan

>