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

Hi Mark,

Thanks for your feedback.

On behalf of the editors, here's a summary of changes and actions triggered by your feedback:

> On 15 Sep 2015, at 22:08, Mark James <mrj@rbate.com> wrote:
> 
> Some comments on the current draft:
>  • Both "UA" (user agent) and "suspended" should be better defined.

The standard user agent definition boilerplate is at:

  https://rawgit.com/zolkis/web-nfc/gh-pages/index.html#dfn-ua


No further changes required to conform at this time.

For the definition of "suspended" I opened a new issue:

  https://github.com/w3c/web-nfc/issues/48


>  • Some spelling mistakes:
> 
>        ndef.TYPE_LENGHT
>        exceeption
>        var>record.type

These typos have been fixed with:

  https://github.com/zolkis/web-nfc/commit/c6ab4350f2ad576bef5d454f640c7b2c334866a7


> Improvements can also be made to some of the English, but that can wait until a pre-release polish.
> 
>  • 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?

Fixed by making the default value implementation-dependant:

  https://github.com/zolkis/web-nfc/commit/57d0487d0e93ad0df7d09588980ac9f940b412e3


For this change, we need to gather further feedback from implementers, consider whether not specifying the default will degrade the user experience.

>> 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.

This has been now clarified in each relevant step with an appropriate note:

  https://github.com/zolkis/web-nfc/commit/48863fa6a1d4e2e22954eb5b1bf73baae8bda73e


> 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.

Thanks,

-Anssi (CG chair)

Received on Wednesday, 16 September 2015 07:49:28 UTC