Closed Bug 897312 Opened 11 years ago Closed 10 years ago

B2G NFC: Define protocol to communicate between nfcd and b2g

Categories

(Firefox OS Graveyard :: NFC, defect)

Product:
Firefox OS Graveyard
Component:
NFC
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:-)

Status:
RESOLVED WONTFIX
Project Flags:
blocking-b2g -

People

(Reporter: allstars.chh, Assigned: arno)

References

Details

Attachments

(1 file, 10 obsolete files)

(v1.9) Nfcd/Gonk Protocol Specification
1.15 MB, application/pdf
Details 
Answering/continuing comment #164 in WebNFC bug 674741:

@Yoshi:
The svic github branches (gaia and gecko) have "master" which is basically M-C master with NFC code, and nfc_json_protocol as a WIP branch (it does not yet pass a session id from the nexus-s only "reference" NFCD implementation to use to drive events using the APIs). System App and Nfc-demo has the current gaia side changes. We'll be updating that in a few days hopefully, and merge to the gaia and gecko svic masters and create new patches. It's not totally usable as of this message, but the protocol messages should still happen provided nfc is enabled.

The JSON can be swapped eventually with some other marshaling method.
If needed, in our nexus-s-uicc config builds, we do:
adb shell setprop nfc.enabled true && adb stop b2g && adb start b2g

This is related to the (not quite up to date) feature bug for a Settings UI setting:
https://bugzilla.mozilla.org/show_bug.cgi?id=866907
Thanks for the detailed info. :)
Hi, Garner
Does the "P2P" in the tech of TechDiscoveredNotification mean this discovered Nfc tech is a Device, so if this notification doesn't contain "P2P" means this is a Tag?

Also back to the WebAPI, What's the data inside ontechdiscovered ?

Thanks
Also from Comment 2, it reminds me we don't have PDU from enable/disable, right?
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #5)
> Also from Comment 2, it reminds me we don't have PDU from enable/disable,
> right?

Sorry, should be "we don't have PDU for enable/disable".
Yes, there is no pdu. There is a system properties call in gonk that tells the nfcd system daemon to shut down (as defined in the gonk-misc/init.b2g.rc file), as the app can't start itself after it is stopped (Or it can, but it'll likely require the process to be alive using resources, idle waiting in a thread).
Okay, I'll move the discussion of settings to Bug 866907.
Assignee: nobody → allstars.chh
Blocks: 860907
Attachment #780135 - Attachment description: (v3) This document describes the NFC API interaction between gecko and the actual NFC library and hardware implementation. → (v1.2) This document describes the NFC API interaction between gecko and the actual NFC library and hardware implementation.
Version 1.3 of the nfcd/Gonk protocol specification.
(In reply to Garner Lee from comment #7)
> Yes, there is no pdu.

There is a PDU description now (not implemented yet), to configure the power levels (on/off) of the NFC hardware. 

To answer an earlier question, the TechDiscovered notificaiton only contains the list of technologies {NDEF, NDEF_WRITABLE, P2P, MIFARE, etc.}. P2P to my knowledge is never a tag, and always another NFC device with P2P support.
(In reply to Garner Lee from comment #10)
> (In reply to Garner Lee from comment #7)
> > Yes, there is no pdu.
> 
> There is a PDU description now (not implemented yet), to configure the power
> levels (on/off) of the NFC hardware. 
> 

What are the values of the status in the ConfigResponse?
Attachment #780135 - Attachment is obsolete: true
Comment on attachment 793475 [details]
NfcGonkMessage.h

Hi, Arno and Garner

This is the header file which is done according to your protocol specification.
Can you take a look in it and see if I have done something wrong here?

I add some TODO in the header file, one of them is Error code.
I think the Error code you used is from Android,
I am not sure how many error code are still useful for FirefoxOS, so I left it mostly empty here.

I will try to add more error code when integrating this header with nfcd.

Thanks
Attachment #793475 - Flags: feedback?(dgarnerlee)
Attachment #793475 - Flags: feedback?(arno)
Attached file C++ classes for nfcd/Gonk PDUs (obsolete) — 
Yoshi: this is the header file we use for marshalling the nfcd/Gonk PDUs into a binary format. It is C++ based and uses STL. We have a matching implementation on the JS side. We might merge our proposals.
Attached file JS implementation of nfcd/Gonk PDUs (obsolete) — 
Here is the matching JS implementation for the nfcd/Gonk PDUs that also shows details of the little endian encoding.
Comment on attachment 793475 [details]
NfcGonkMessage.h

Comparing your and our proposal, I see the following differences:

- You use C structs; we use C++ classes
- You define the data structures, but not the marshalling, unmarshalling API;
  our C++ classes have both
- We make use of STL; you use a argc/argv style for parameters. Memory ownership
  is not clear
Comment on attachment 793475 [details]
NfcGonkMessage.h

Hi, Arno

The marshalling/unmarshalling is split to Bug 902051.

And ......Oops I didn't know you're working on the implementation, too.

These bugs (this bug and Bug 902051, and many other b2g-nfc bugs) are filed weeks ago on Bugzilla, and they are open to public. Also I have CCed you in the bugs.

If you're interested in some bugs or even like to work on them, or have different opinions, ..etc, feel free to discuss that on Bugzilla, I could set the Assignee to you so we don't have to work on the same thing.
Attachment #793475 - Flags: feedback?(dgarnerlee)
Attachment #793475 - Flags: feedback?(arno)
sorry, I didn't understand the purpose of bug 902051 since this is not JSON but binary marshalling. Also, this bug mentions 'protocol' in the title so I assumed it is not just data structures but also the marshalling. Anyways, you can resolve this how you see fit (e.g., assign those bugs to me)
Hi, Arno
I assign this bug to you.

Also can you share your cpp source?
whether in Bugzilla or Github or something.
(Hope the license is clear :P)

We will check whether the Cpp API can help us in nfcd.

Thanks
Assignee: allstars.chh → arno
here are the C++ sources:
https://github.com/svic/b2g-nfcd/commit/644a1ae7f6d498ca34fb5d8847e555ea4e784085

We have not yet updated the code for the 1.3 protocol spec. We are also not yet making use of the binary protocol. After we agree on the API, we will integrate it with nfcd (I guess one todo for next week)
Comment on attachment 793475 [details]
NfcGonkMessage.h

Hi,

I have some comments about the protocol structures. Strictly speaking, it's currently not a protocol, but an API.

>/**
> * NFC parcel format.
> *
> * NFC Request:
> *    4 bytes of parcel size. (Big-Endian)
> *    4 byte of request type. Value will be one of NfcRequest.
> *    4 bytes of token number.
> *    (Parcel size - 8) bytes of request data.
> *
> * NFC Response:
> *    4 bytes of parcel size. (Big-Endian)
> *    4 byte of response type. Value will be NFCC_MESSAGE_RESPONSE.
> *    4 bytes of token number.
> *    4 bytes of error code. Value will be one of NfcErrorCode.
> *    (Parcel size - 12) bytes of response data.
> *
> * NFC Notification:
> *    4 bytes of parcel size. (Big-endian)
> *    4 byte of response type. Value will be NFCC_MESSAGE_NOTIFICATION.
> *    4 bytes of notification type. Value will one of NfcNotification.
> *    (Parcel size - 8) bytes of notification data.
> *
> * Except Parcel size is encoded in Big-Endian, other data will be encoded in
> * Little-Endian.
> */

I'd suggest to make everything BE.

>/**
> * Message types sent from NFCC (NFC Controller)
> */
>typedef enum {
>  NFCC_MESSAGE_RESPONSE = 0,
>  NFCC_MESSAGE_NOTIFICATION = 1
>} NFCCMessageType;

In general, I'm not a big fan of using typedef for hiding enum and struct. It makes the resulting code harder to understand because it obfuscates the purpose of the type.

>/**
> * Error code.
> */
>typedef enum {
>  NFC_ERROR_SUCCESS = 0,
>//TODO Error Code
>} NfcErrorCode;
>
>/**
> * Power saving mode.
> */
>typedef enum {
>  /**
>   * No action, a no-op to be able to mimic optional parameters once
>   * additional config parameters will be introduced.
>   */
>  NFC_POWER_SAVING_NO_OP = -1,
>
>  /**
>   * Exit power saving mode.
>   */
>  NFC_POWER_SAVING_EXIT = 0,
>
>  /**
>   * Enter power saving mode.
>   */
>  NFC_POWER_SAVING_ENTER = 1,
>} NfcPowerSavingMode;
>
>/**
> * NFC technologies.
> */
>typedef enum {
>  NFC_TECH_NDEF = 0,
>  NFC_TECH_NDEF_WRITABLE = 1,
>  NFC_TECH_P2P = 2,
>} NfcTechnology;
>
>/**
> * NDEF Record
> * @see NFCForum-TS-NDEF, clause 3.2
> */
>typedef struct {
>  uint8_t tnf;
>
>  int typeLength;

The size of an int is vaguely defined. Use uint32_t here.

>  uint8_t *type;

The pointers need to go. I suggest to have a variable-length data-array field at the end of the structure. Store the actual type, id and payload in that array, and store length and offset of these values in the structures.

>
>  uint8_t idLength;
>  uint8_t *id;
>
>  //TODO : For Short Record, length is only 1 byte.
>  int payloadLength;
>  uint8_t payload;
>} NdefRecord;

All these structures need to have __attribute__((packed)) specified. Otherwise the resulting memory layout might not be compatible among different programs.

More generally speaking, I still think we should not define NdefRecords and NDefMessages at the protocol level if possible. We should rather encode them in nfcd into something we can easily parse in JS, and only pass opaque blobs between nfcd and Gaia. For example, we could encode Ndef* structures in JSON, hand them over to Gaia, and eval() them there to decode them. I don't know if this is a security problem, though.

>/**
> * NDEF Message.
> */
>typedef struct {
>  int numRecords;
>  NdefRecord *records;
>} NdefMessage;

Again __attribute__((packed)), the int, and the pointer.

>//TODO: Use String16 for SessionId?
>/**
> * Session Id.
> */
>typedef struct {
>  uint32_t strLength;
>  char* sessionId;
>} NfcSessionId;

ditto

>typedef struct {
>  /**
>   * The sessionId must correspond to that of a prior
>   * NfcNotificationTechDiscovered.
>   */
>  NfcSessionId sessionId;
>
>  NfcPowerSavingMode powerSave;
>} NfcConfigRequest;
>
>typedef struct {
>  /**
>   * The sessionId must correspond to that of a prior
>   * NfcNotificationTechDiscovered.
>   */
>  NfcSessionId sessionId;
>
>  /**
>   * possible values are : TODO
>   */
>  int status;
>} NfcConfigResponse;
>
>typedef struct {
>  /**
>   * The sessionId must correspond to that of a prior
>   * NfcNotificationTechDiscovered.
>   */
>  NfcSessionId sessionId;
>
>  NfcTechnology technology;
>} NfcConnectRequest;
>
>typedef struct {
>  /**
>   * The sessionId must correspond to that of a prior
>   * NfcNotificationTechDiscovered.
>   */
>  NfcSessionId sessionId;
>
>  //TODO Parcel doesn't have API for boolean, should we use bit-wise for this?

Using bits here is fine IMHO.

>  /**
>   * The NDEF is read-only or not.
>   */
>  uint8_t isReadOnly;
>
>  /**
>   * The NDEF can be configured to read-only or not.
>   */
>  uint8_t canBeMadeReadonly;
>
>  /**
>   * Maximum length of the NDEF.
>   */
>  uint32_t maxNdefLength;

Is that the maximum NDEF length that the tag accepts or emits? Because if it's the maximum emitted length, we can just drop the field and handle the length on a per-message base.

>} NfcGetDetailsResponse;


I think that's all. For the rest of the file, it's just the same.

Best regards
Thomas



>typedef struct {
>  /**
>   * The sessionId must correspond to that of a prior
>   * NfcNotificationTechDiscovered.
>   */
>  NfcSessionId sessionId;
>
>  /**
>   * NDEF Message to be transmitted.
>   */
>  NdefMessage ndef;
>} NfcNdefReadWritePdu;
>
>typedef enum {
>  /**
>   * NFC_REQUEST_CONFIG
>   *
>   * Config NFCD options.
>   *
>   * data is NfcConfigRequest.
>   *
>   * response is NfcConfigResponse.
>   */
>  NFC_REQUEST_CONFIG = 0,
>
>  /**
>   * NFC_REQUEST_CONNECT
>   *
>   * Connect to a specific NFC-compatible technology.
>   *
>   * data is NfcConnectRequest.
>   *
>   * response is NULL.
>   */
>  NFC_REQUEST_CONNECT = 1,
>
>  /**
>   * NFC_REQUEST_CLOSE
>   *
>   * Close an open connection that must have been opened with a prior
>   * NfcConnectRequest.
>   *
>   * data is NfcSessionId, which is correlates to a technology that was
>   * previously discovered with NFC_NOTIFICATION_TECH_DISCOVERED.
>   *
>   * response is NULL.
>   */
>  NFC_REQUEST_CLOSE = 2,
>
>  /**
>   * NFC_REQUEST_GET_DETAILS
>   *
>   * Request the NDEF meta-data. The 'technology' field in
>   * NfcNotificationTechDiscovered must include NFC_TECH_NDEF.
>   *
>   * data is NfcSessionId, which is correlates to a technology that was
>   * previously discovered with NFC_NOTIFICATION_TECH_DISCOVERED.
>   *
>   * respose is NfcGetDetailsResponse.
>   */
>  NFC_REQUEST_GET_DETAILS = 3,
>
>  /**
>   * NFC_REQUEST_READ_NDEF
>   *
>   * Request the scanned NDEF message. The 'technology' field in
>   * NfcNotificationTechDiscovered must include NFC_TECH_NDEF.
>   *
>   * data is NfcSessionId, which is correlates to a technology that was
>   * previously discovered with NFC_NOTIFICATION_TECH_DISCOVERED.
>   *
>   * response is NfcNdefReadWritePdu.
>   */
>  NFC_REQUEST_READ_NDEF = 4,
>
>  /**
>   * NFC_REQUEST_WRITE_NDEF
>   *
>   * Write a NDEF message. The 'technology' field in
>   * NfcNotificationTechDiscovered must include NFC_TECH_NDEF_WRITABLE or
>   * NFC_TECH_P2P.
>   *
>   * data is NfcNdefReadWritePdu.
>   *
>   * response is NULL.
>   */
>  NFC_REQUEST_WRITE_NDEF = 5,
>
>  /**
>   * NFC_REQUEST_MAKE_NDEF_READ_ONLY
>   *
>   * Make the NDEF message is read-only. The 'technology' field in
>   * NfcNotificationTechDiscovered must include NFC_TECH_NDEF_WRITABLE.
>   *
>   * data is NfcSessionId, which is correlates to a technology that was
>   * previously discovered with NFC_NOTIFICATION_TECH_DISCOVERED.
>   *
>   * response is NULL.
>   */
>  NFC_REQUEST_MAKE_NDEF_READ_ONLY = 6,
>} NfcRequest;
>
>typedef struct {
>  NfcSessionId sessionId;
>  int numOfTechnogies;
>  NfcTechnology* technology;
>} NfcNotificationTechDiscovered;
>
>typedef enum {
>  NFC_NOTIFICATION_BASE = 1000,
>
>  /**
>   * NFC_NOTIFICATION_TECH_DISCOVERED
>   *
>   * To notify a NFC-compatible technology has been discovered.
>   *
>   * data is NfcNotificationTechDiscovered.
>   */
>  NFC_NOTIFICATION_TECH_DISCOVERED = 1001,
>
>  /**
>   * NFC_NOTIFICATION_TECH_LOST
>   *
>   * To notify whenever a NFC-compatible technology is removed from the field of
>   * the NFC reader.
>   *
>   * data is char* sessionId, which is correlates to a technology that was
>   * previously discovered with NFC_NOTIFICATION_TECH_DISCOVERED.
>   */
>  NFC_NOTIFICATION_TECH_LOST = 1002,
>} NfcNotification;
>
>#ifdef __cplusplus
>}
>#endif
>
>#endif // NFC_GONK_MESSAGE_H
Comment on attachment 793573 [details]
C++ classes for nfcd/Gonk PDUs

Hi

>#ifndef __PDU_H__
>#define __PDU_H__
>
>#include "codec.h"

I guess codec is the component that does the actual encoding. So the code below is really just the interface,right? And codec can be freely choosen (e.g., binary, JCSON, etc)?

>
>class NDEFRecord {
>public:
>    UShort tnf;
>    vector<Octet> type;
>    vector<Octet> id;
>    vector<Octet> payload;
>    
>    void marshall(Codec* codec);
>    static NDEFRecord unmarshall(Codec* codec);
>};

It looks to me like there is tons of copying involved here. First to the vectors and from the vectors to codec.

Best regards
Thomas
Hi,

It seems to me that there is a lot of copying involved in the proposed binary protocols and APIs. Our communication  is machine-local, so copying messages has probably the biggest impact on performance, memory  and power consumption.

When we switch to the binary protocol, we should really try to minimize this copying IMHO. Ideally we receive an NDefMessage from the driver library and just briefly look at it to determine the amount memory that we need to hold it in its marshaled form. We allocate this much memory and marshal the incoming data directly into this buffer.

The allocation should be done from shared memory between nfcd and Gecko, so once we have the marshaled message, Gecko can start parsing it immediately, no extra copying between the address spaces here.

I think we can get away with two copy operations. And exchanging messages from Gecko to nfcd can be implemented in the same way.

Best regards
Thomas
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #21)
> >/**
> > * NFC parcel format.
> > *
> > * NFC Request:
> > *    4 bytes of parcel size. (Big-Endian)
> > *    4 byte of request type. Value will be one of NfcRequest.
> > *    4 bytes of token number.
> > *    (Parcel size - 8) bytes of request data.
> > *
> > * NFC Response:
> > *    4 bytes of parcel size. (Big-Endian)
> > *    4 byte of response type. Value will be NFCC_MESSAGE_RESPONSE.
> > *    4 bytes of token number.
> > *    4 bytes of error code. Value will be one of NfcErrorCode.
> > *    (Parcel size - 12) bytes of response data.
> > *
> > * NFC Notification:
> > *    4 bytes of parcel size. (Big-endian)
> > *    4 byte of response type. Value will be NFCC_MESSAGE_NOTIFICATION.
> > *    4 bytes of notification type. Value will one of NfcNotification.
> > *    (Parcel size - 8) bytes of notification data.
> > *
> > * Except Parcel size is encoded in Big-Endian, other data will be encoded in
> > * Little-Endian.
> > */
> 
> I'd suggest to make everything BE.
> 
This is the same encoding used from RIL, which uses the same encoding from Android.
Parcel size is written in Big-Endian,
whereas the parcel data is written by binder, which is Little-Endian.


> >  int payloadLength;
> >  uint8_t payload;
> >} NdefRecord;
> 
> All these structures need to have __attribute__((packed)) specified.
> Otherwise the resulting memory layout might not be compatible among
> different programs.
>

Again this is also using the same idea from RIL, which uses the same idea from Binder.

For example a message looks like

{
  int a;
  uint_8 b;
  int c;
 
}


So the sender side could use Binder API or the Buf object from ril_worker to do

writeUint32(a);
writeUint8(b);
writeUint32(c);

And the receiver side did the same way.
 
a = ReadUint32
b = ReadUint8
c = ReadUint32

without worrying the padding.
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #23)
> Hi,
> 
> It seems to me that there is a lot of copying involved in the proposed
> binary protocols and APIs.

the largest STL vector will be payload which will be on the average 100, 200 bytes based on most common tag types. This is not a graphics driver where you move megabytes of texture maps. For an HTML-based platform where the majority of the code is written in JavaScript that is an interesting concern. The codec implementation is taken from an older (open source) project of mine and there is a helper class Buffer (see the github link I posted in another comment) that is a wrapper around malloc that adds reference counting. I will change the STL vectors to Buffer. Would that be a compromise?

Arno
Hi Arno

(In reply to arno from comment #25)
> (In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #23)
> > Hi,
> > 
> > It seems to me that there is a lot of copying involved in the proposed
> > binary protocols and APIs.
> 
> the largest STL vector will be payload which will be on the average 100, 200
> bytes based on most common tag types. This is not a graphics driver where
> you move megabytes of texture maps. For an HTML-based platform where the
> majority of the code is written in JavaScript that is an interesting
> concern.

You seem to imply that we don't need to take performance into account just because a good part of our software is written in an interpreted (and thus slow?) language. I don't think we should design software with this kind of reasoning.

> The codec implementation is taken from an older (open source)
> project of mine and there is a helper class Buffer (see the github link I
> posted in another comment) that is a wrapper around malloc that adds
> reference counting. I will change the STL vectors to Buffer. Would that be a
> compromise?

Sure, but we're not a standards committee, where they all compromise so that everyone gets some of their interfaces into the final spec. ;) Let's just try to minimize the unnecessary overhead where possible.

Best regards
Thomas
(In reply to arno from comment #25)

>  For an HTML-based platform where the
> majority of the code is written in JavaScript that is an interesting
> concern. 

While I see why you are saying that, the underlying platform does a lot of work to make js not wasteful. Take a look at the implementation of JS strings for instance. We're not simply moving std::string around...

Any saving that we can do is good since that let more resources available, especially if that doesn't imply huge engineering effort.
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #22)
> Comment on attachment 793573 [details]
> C++ classes for nfcd/Gonk PDUs
> 
> Hi
> 
> >#ifndef __PDU_H__
> >#define __PDU_H__
> >
> >#include "codec.h"
> 
> I guess codec is the component that does the actual encoding. So the code
> below is really just the interface,right? And codec can be freely choosen
> (e.g., binary, JCSON, etc)?

sorry, missed this one. Yes, Codec is a base class. Right now there is a LECodec and a BECodec.

Arno
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #26)
> > The codec implementation is taken from an older (open source)
> > project of mine and there is a helper class Buffer (see the github link I
> > posted in another comment) that is a wrapper around malloc that adds
> > reference counting. I will change the STL vectors to Buffer. Would that be a
> > compromise?
> 
> Sure, but we're not a standards committee, where they all compromise so that
> everyone gets some of their interfaces into the final spec. ;) Let's just
> try to minimize the unnecessary overhead where possible.

well, Thomas, I have done my share of standards work and trust me, I'm no fan. Just trying to reach an agreement between engineers. :) I will use the malloc() wrapper which will get rid of the deep vector copies.

Arno
Blocks: 894689, 894323, 894672, 904246, 894678, 894676, 894320, 894673, 894691
No longer blocks: b2g-nfc
Depends on: 907252

        Attachment #792561 -
        Attachment is obsolete: true

    
    

    
  
There might be a need a command added for chipset independent firmware upgrades to the NFC hardware.

    
    

    
  
(In reply to Garner Lee from comment #31)
> There might be a need a command added for chipset independent firmware
> upgrades to the NFC hardware.

Every vendor has their firmware upgrade procedure. For example, they may have their proprietary protocol to communication with their chips. And OEM should handle it in factory mode. I wonder if we really need to have this kind of command in nfcd communication protocol.
Component: DOM: Device Interfaces → NFC
Product: Core → Boot2Gecko
Version: Trunk → unspecified

    
    

    
  
Hi, Anro and Garner
Do you think sessionId is neccesary?

It seems to me we can remove sessionId.
Do you have any comment we need to keep this?

For example, you expect when calling ndefRead with a session ID which is already techLost, we should return error, "sessionId not found".
But why do we need to enforce this sessionId checking?


Thanks

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #33)
> Hi, Anro and Garner
> Do you think sessionId is neccesary?
> 
> It seems to me we can remove sessionId.
> Do you have any comment we need to keep this?
> 
> For example, you expect when calling ndefRead with a session ID which is
> already techLost, we should return error, "sessionId not found".
> But why do we need to enforce this sessionId checking?

Yoshi: what if you approach a second time a different tag to the phone and then the app does the ndefRead (or worse ndefWrite)? It will do the interaction with the wrong tag. If you try to maintain the necessary session state on the Gonk side implicitly via tech lost/discovered, you could have a race condition between nfcd and Gonk.

Arno

    
    

    
  
(In reply to arno from comment #34)
> Yoshi: what if you approach a second time a different tag to the phone and
> then the app does the ndefRead (or worse ndefWrite)? It will do the
> interaction with the wrong tag.

So for the WebAPI, you also need to expose some ID (Like SessionId), right?
Otherwise from the API, how does the ndefRead call map to the corresponding on-tech-discovered ?

For example, 
APP  <-- tech-discvoered (A)---   Nfc Chip
APP  <-- tech-lost       (A)---   Nfc Chip 
APP  <-- tech-discvoered (B)---   Nfc Chip

APP  ---- ndef-read ----------->  Nfc Chip

How do you tell which tag the APP wants to read when it calls this ndefRead function? 
It's tag A or tag B?

Also for some Nfc technology, or for some Nfc Chip, it's possible to have two sessions (connect to two different tags), right? If I recall correctly in the last work week. 

So if we need to have session in implementation,
does it mean that we also need to have this in WebAPI level?

And from the W3C NFC API, it will have a NFCTag or NFCPeer object,
So for the app, it could call NFCTag.readNdef()
and this object could map to the 'session' you mention.

I think if we need to make sure the 'session' is correct, we need to update our WebNFC API as well.
 
How do you think ?

    
    

    
  
Also the 'session' should be maintained from the gecko side, not from the daemon.
Those Nfc Libraries doesn't have the concept of session, or some Id/Handle when calling those ndefRead/Write, so it's more reasonable to maintain the session *only* in gecko.

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #35)
> (In reply to arno from comment #34)
> > Yoshi: what if you approach a second time a different tag to the phone and
> > then the app does the ndefRead (or worse ndefWrite)? It will do the
> > interaction with the wrong tag.
> 
> So for the WebAPI, you also need to expose some ID (Like SessionId), right?
> Otherwise from the API, how does the ndefRead call map to the corresponding
> on-tech-discovered ?

This may not be the right bug to discuss this and Garner can clarify, but to my understanding there is a map between session ID and DOM request IDs. There is no need to expose the session ID to the WebAPI.

Arno

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #36)
> Also the 'session' should be maintained from the gecko side, not from the
> daemon.
> Those Nfc Libraries doesn't have the concept of session, or some Id/Handle
> when calling those ndefRead/Write, so it's more reasonable to maintain the
> session *only* in gecko.

The session starts the moment you hold a tag close to a phone and ends when the tag is removed from the reader field. The most logical place to create the session ID is where the tag is first detected (in nfcd). With what you propose, PDU TechDiscovered would not have a session ID but it would be created on the Gonk side and then communicated back to nfcd (this would require a new PDU?). There is a potential race condition again that can be avoided if nfcd creates the session ID.

Arno

    
    

    
  


  

        Attachment #796939 -
        Attachment is obsolete: true

    
    

    
  
To be addressed in v1.6:
1. Update the Base PDU, currently there are 6 kinds Base PDU actually.
- Request with SessionId,
- Request without SessionId, like ConfigRequest
- The same goes for Response and ConfigResponse.
- Notification with SessionId
- Notification without SessionId, like InitializedNotification.

2. Swap the position for status and sessionId in Response PDU, so status comes first, then sessionId.
Because each Response has a status code, but not every Response has a session, like ConfigResponse.

    
    

    
  
3. The first 4 bytes of each PDU should be the size of PDU in Big-Endian.

    
    

    
  
Hi, Anro and Siddartha
Can you also share your implementation of the state machine?
Is it done in gecko or nfcd?

You purposed when the state is in some pending state, issuing another request will fail.
Can you eloborate more on this? with some sample code.


Thanks

    
    

    
  
It seems to me the 'synchronous' handling could be done inside nfcd,
so neither gecko nor the protocol will need to worry about this.
So we could remove some pending state in the protocol.

And if the request can be asynchronous, we need to add token in the protocol.

    
    

    
  
Hi Arno
What's the powerLevel value in ConfigRequest?

In v1.3, you called it 'powerSave' and 0 is exit power saving mode, and 1 is to enter.
But now you removed that in the protocol, and rename it to powerLevel.

Can you update the what are the possible values for powerLevel?
What values are to enable/disable NFC hardware,
and what values are used to enable/disable discovery?

Thanks

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #44)
> It seems to me the 'synchronous' handling could be done inside nfcd,
> so neither gecko nor the protocol will need to worry about this.
> So we could remove some pending state in the protocol.
> 
> And if the request can be asynchronous, we need to add token in the protocol.

Yoshi: synchronization can just as easily be done on the gecko side. Actually, it makes sense to do it on the gecko side so that not every nfcd implementation needs to do this (in case someone else wants to implement the protocol). Last but not least I suggest to stabilize the protocol and integration of our implementation before making further changes. We can discuss this during the next work week.

I will update the protocol spec with your other feedback tomorrow.

Arno

    
    

    
  
There's no PUSH in the document, is it intensional?

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #47)
> There's no PUSH in the document, is it intensional?

We use the same NDEF write PDU in our reference implementation. There is no need to add another PDU. If nfcd is in P2P tech discovered state, it will do the PUSH.

Arno

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #45)
> Hi Arno
> What's the powerLevel value in ConfigRequest?
> 
> In v1.3, you called it 'powerSave' and 0 is exit power saving mode, and 1 is
> to enter.
> But now you removed that in the protocol, and rename it to powerLevel.
> 
> Can you update the what are the possible values for powerLevel?
> What values are to enable/disable NFC hardware,
> and what values are used to enable/disable discovery?
> 
> Thanks

Hi Arno
Can you update this for us?

We need these values for our nfcd.

Thanks.
Flags: needinfo?(arno)

    
    

    
  
(In reply to arno from comment #48)
> We use the same NDEF write PDU in our reference implementation. There is no
> need to add another PDU. If nfcd is in P2P tech discovered state, it will do
> the PUSH.
> 
> Arno

AFAIK, the difference between ndefPush and ndefWrite is ndefPush will write the NDEF when P2P link is established, and if the P2P link is not established yet, nfc daemon needs to cache this NDEF, and when P2P is established, daemon will write this NDEF.

What will happen if the app calls ndefPush *without* a previous P2P Tech discovered state?
Gecko will expect daemon will cache this NDEF, right?

But in this case, gecko sends a NDEF_WRITE_PDU, daemon will find there's no P2P tech discovered before so daemon will drop this NDEF.

Is this what ndefPush should do?

If it is, I think we don't need to have ndefWrite and ndefPush two APIs, we just need ndefWrite. 

Thanks

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #49)
> (In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #45)
> > Hi Arno
> > What's the powerLevel value in ConfigRequest?
> > 
> > In v1.3, you called it 'powerSave' and 0 is exit power saving mode, and 1 is
> > to enter.
> > But now you removed that in the protocol, and rename it to powerLevel.
> > 
> > Can you update the what are the possible values for powerLevel?
> > What values are to enable/disable NFC hardware,
> > and what values are used to enable/disable discovery?
> > 
> > Thanks
> 
> Hi Arno
> Can you update this for us?
> 
> We need these values for our nfcd.
> 
> Thanks.

As currently implemented, it's only 0 and 1. If more powerlevels than {0,1} have no sensible mapping in the NFC libaries, I can be convinced to opportunistically change the property name back from powerlevel to powersave.

    
    

    
  
(In reply to Garner Lee from comment #51)

> As currently implemented, it's only 0 and 1. If more powerlevels than {0,1}
> have no sensible mapping in the NFC libaries, I can be convinced to
> opportunistically change the property name back from powerlevel to powersave.

Is 1 for enabling discovery or enabling NFC hardware?

I remembered in NFC work week you said there will be some values for enable/disable NFC hardware.

    
    

    
  
I think, Just to clarify, power levels use-case is different to enable / disable hardware. 

1) Power levels : {0,1}
  0: When the back-light turns off, then High level OS (FxOS) should notify NFC hardware to get into    power save mode
  1: Vice-Versa, When back-light is ON, notify NFC hardware of the same

<< This usecase is similar to RIL_SCREEN_STATE ON/OFF >>

2) However, User can explicitly turn on / off NFC through Settings App. Therefore another config values, 2-tuple needs to be defined for enable / disable of NFC hardware.

**** Maybe we can discuss #3 & #4 later ****

3) On a side note, I think we may also have to define "SCREEN_LOCKED / UNLOCKED" scenarios so that it enables more optimized way of configuring NFC-Controller polling.

4) Also note that in Android, Nfc Adapter is turned on / off after taking airplane mode settings into consideration

    
    

    
  
(In reply to Siddartha P from comment #53)
 > 2) However, User can explicitly turn on / off NFC through Settings App.
> Therefore another config values, 2-tuple needs to be defined for enable /
> disable of NFC hardware.
> 
Hi, Sidd
Thanks for the info,
can you let us know once you implemeneted the enable/disable nfc hardware?
We will add this feature (enable nfc hardware) to our daemon.

Thanks

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #50)
> (In reply to arno from comment #48)
> > We use the same NDEF write PDU in our reference implementation. There is no
> > need to add another PDU. If nfcd is in P2P tech discovered state, it will do
> > the PUSH.
> > 
> > Arno
> 
> AFAIK, the difference between ndefPush and ndefWrite is ndefPush will write
> the NDEF when P2P link is established, and if the P2P link is not
> established yet, nfc daemon needs to cache this NDEF, and when P2P is
> established, daemon will write this NDEF.
> 
> What will happen if the app calls ndefPush *without* a previous P2P Tech
> discovered state?
> Gecko will expect daemon will cache this NDEF, right?
> 
> But in this case, gecko sends a NDEF_WRITE_PDU, daemon will find there's no
> P2P tech discovered before so daemon will drop this NDEF.
> 
> Is this what ndefPush should do?
> 
> If it is, I think we don't need to have ndefWrite and ndefPush two APIs, we
> just need ndefWrite. 
> 
> Thanks

Hi Arno Garner and Sidd

Can you help to reply this question?

Thanks

    
    

    
  
Hi Anro Garner and Sidd

Now we have another questions.

When two devices are 'touching' each other (use 'touch' here for I don't know the correct verb here),

shouldn't both devices get a ontechdiscovered callback with tech is P2P at this time?
But it seems in your nfcd, you didn't send a notification for this.

See https://github.com/svic/b2g-nfcd/blob/master/src/com_android_nfc_NfcService.cpp#L88

We think the ontechdiscovered should be called when two devices are touching each other.

That brings another question,
Device A and Device B are touching each other, both get a ontechdiscovered callback,
now Device A calls ndefPush, now daemon on the device B receives this ndef, but it seems there's no PDU can be notified to Gecko for this.

Can you help to check this ?

Thanks

        Attachment #793475 -
        Attachment is obsolete: true

    
    

    
  
Yes Yoshi, thats the intent. Both the devices should get 'ontechDiscovered' with P2P.
Our 'nfcd'master never had this change. However I have local changes that I never pushed it to master.

Note that when two devices are bought together (Device A & Device B), both have started their snep server.
Upon ndefPush from say Device A, snepClient gets started and sends the PDU. At this moment, Device A becomes the 'initiator' while Device B becomes the 'target' as per SNEP protocol. So are you saying that despite DEVICE B getting the ndef message, gecko cannot be notified.

I can try and check on our reference impl. on nexus-s
Flags: needinfo?(arno)

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #50)
> (In reply to arno from comment #48)
> > We use the same NDEF write PDU in our reference implementation. There is no
> > need to add another PDU. If nfcd is in P2P tech discovered state, it will do
> > the PUSH.
> > 
> > Arno
> 
> AFAIK, the difference between ndefPush and ndefWrite is ndefPush will write
> the NDEF when P2P link is established, and if the P2P link is not
> established yet, nfc daemon needs to cache this NDEF, and when P2P is
> established, daemon will write this NDEF.
> 
> What will happen if the app calls ndefPush *without* a previous P2P Tech
> discovered state?
> Gecko will expect daemon will cache this NDEF, right?
> 
> But in this case, gecko sends a NDEF_WRITE_PDU, daemon will find there's no
> P2P tech discovered before so daemon will drop this NDEF.
> 
> Is this what ndefPush should do?
> 
> If it is, I think we don't need to have ndefWrite and ndefPush two APIs, we
> just need ndefWrite.

An NDEFWriteRequest is only permissible in state NDEF Connected, which means that a P2P device has to be in the vicinity. In our reference implementation (as reflected in the protocol spec) nfcd does not cache a pending NDEF write request. In fact, we want to support the case where the app is asked for the NDEF message to be pushed at the time another P2P device is brought close. This will allow use cases such as the YouTube app adding the time index of the video that is being watched at the time of NDEF Push. See Android API:
http://developer.android.com/reference/android/nfc/NfcAdapter.html#setNdefPushMessageCallback(android.nfc.NfcAdapter.CreateNdefMessageCallback, android.app.Activity, android.app.Activity...)

Arno

    
    

    
  
(In reply to Siddartha P from comment #57)
> 
> Note that when two devices are bought together (Device A & Device B), both
> have started their snep server.
> Upon ndefPush from say Device A, snepClient gets started and sends the PDU.
> At this moment, Device A becomes the 'initiator' while Device B becomes the
> 'target' as per SNEP protocol. So are you saying that despite DEVICE B
> getting the ndef message, gecko cannot be notified.
> 
Yes, which PDU is used to notify gecko (on Device B) a Ndef is received?

    
    

    
  
(In reply to arno from comment #58)
> (In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #50)
> > (In reply to arno from comment #48)
> > > We use the same NDEF write PDU in our reference implementation. There is no
> > > need to add another PDU. If nfcd is in P2P tech discovered state, it will do
> > > the PUSH.
> > > 
> > > Arno
> > 
> > AFAIK, the difference between ndefPush and ndefWrite is ndefPush will write
> > the NDEF when P2P link is established, and if the P2P link is not
> > established yet, nfc daemon needs to cache this NDEF, and when P2P is
> > established, daemon will write this NDEF.
> > 
> > What will happen if the app calls ndefPush *without* a previous P2P Tech
> > discovered state?
> > Gecko will expect daemon will cache this NDEF, right?
> > 
> > But in this case, gecko sends a NDEF_WRITE_PDU, daemon will find there's no
> > P2P tech discovered before so daemon will drop this NDEF.
> > 
> > Is this what ndefPush should do?
> > 
> > If it is, I think we don't need to have ndefWrite and ndefPush two APIs, we
> > just need ndefWrite.
> 
> An NDEFWriteRequest is only permissible in state NDEF Connected, which means
> that a P2P device has to be in the vicinity. In our reference implementation
> (as reflected in the protocol spec) nfcd does not cache a pending NDEF write
> request. In fact, we want to support the case where the app is asked for the
> NDEF message to be pushed at the time another P2P device is brought close.
> This will allow use cases such as the YouTube app adding the time index of
> the video that is being watched at the time of NDEF Push. See Android API:
> http://developer.android.com/reference/android/nfc/NfcAdapter.
> html#setNdefPushMessageCallback(android.nfc.NfcAdapter.
> CreateNdefMessageCallback, android.app.Activity, android.app.Activity...)
> 
> Arno

So ndefPush will be called even when the techdiscovered is not happening yet,
and now when nfcd receives a NDEF_WRITE_REQUEST(which should be ndefPush),
it will discard it immediately because the session is incorrect(or there is no session in the PDU).

I do think we need a PDU for ndefPush.

    
    

    
  
Hm...I just removed pushNDEF from the API based on past discussion.

From what I understand, techDiscovered (P2P "tech") will eventually happen. This means if it were cached, it has to be replaced (and state managed) with the latest and greatest application state the app wants to push.

For this to actually happen, we need a UI relevant API that's not written yet for a callback.

We can do this 2 ways:

1) a distinct ndef-p2p-discovered message (which has a limitation of starting the app when not already running: feature? bug?).

2) P2P callback only a running app can set and receive (if we go by the W3C draft spec, we add a p2p callback to the DOM, and have Nfc.js push a call to __DOM_IMPL_.onpeerconnection(...) in the new nsNfc.js navigator DOM I just pushed to SVIC master. That can still call writeNDEF(records), using write PDUs.

We'd still need to lock a one to one app relationship to the hardware in either case (We can't have 3 applications get a onpeerconnection event).

My vote: I sort of like not overloading APIs so long as it doesn't explode the number of PDUs in the process (REST-ful?). Let's decide quickly what's better for the nfcd protocol.

    
    

    
  
Yoshi,

sorry for the slow response. This is a reply to comments #55, #56, #59, and #60. Consider the following scenario:

- A P2P device is brought close to your phone.
- nfcd send [P2P] as the tech list to Gonk.
- If the currently visible app has *not* registered an onpeerfound callback, nothing happens.
- If an onpeerfound callback is registered, we do the "shrinking UI" of the top-most
  application. Note that at this point we do *not* call the onpeerfound callback.

From now on there are two different scenarios:

1. The other P2P device sends an NDEF:
   - nfcd sends an updated tech list [P2P, NDEF] to Gonk
   - The "shrinking UI" is removed and the NDEF is delivered via the regular
     NDEF dispatch mechanism (possibly launching a different app)

2. The user taps on the "shrinking UI" to indicate s/he wants to send (i.e., push)
   an NDEF message to the other peer:
   - Remove the "shrinking UI"
   - call the onpeerdiscovered callback of the top-most application. This will
     notify the app that a P2P device has been discovered.
   - inside the onpeerdiscovered callback the app calls writeNDEF() to push the
     NDEF to the peer

We do not believe that there can be a race condition between the two scenarios. If both users tap the "shrinking UI" at the same time, you may have already gone through scenario 1 and the incoming NDEF will be delivered via the usual NDEF dispatch mechanism.

We hope that this clears things up. Note that in scenario 1 there is an updated tech list (first [P2P] and then [P2P, NDEF]). We do not think there is the need for a ndefPush API.

G&S&A

    
    

    
  
(In reply to arno from comment #62)
> Yoshi,
> 
> sorry for the slow response. This is a reply to comments #55, #56, #59, and
> #60. Consider the following scenario:
> 
> - A P2P device is brought close to your phone.
> - nfcd send [P2P] as the tech list to Gonk.

Okay, this is the 1st techdiscovered here.

> 1. The other P2P device sends an NDEF:
>    - nfcd sends an updated tech list [P2P, NDEF] to Gonk

Oh, this is the 2nd techdiscovered.
I have questions here.

1. Is the sessionId in these two techdiscovered different?
2. Shouldn't nfcd send a tech-lost for the 1st techdiscovered?

>    - The "shrinking UI" is removed and the NDEF is delivered via the regular
>      NDEF dispatch mechanism (possibly launching a different app)
> 

You and Sidd haven't said which PDU is used to notify a NDEF even now. See comment 59
Can you describe the detail to NDEF dispatch ?

> 
> We do not believe that there can be a race condition between the two
> scenarios. If both users tap the "shrinking UI" at the same time, you may
> have already gone through scenario 1 and the incoming NDEF will be delivered
> via the usual NDEF dispatch mechanism.
> 
> We hope that this clears things up. Note that in scenario 1 there is an
> updated tech list (first [P2P] and then [P2P, NDEF]). We do not think there
> is the need for a ndefPush API.
> 

Actually, I am not sure quite sure what you're talking about, sorry for my stupiedness. :(

I am talking about PDU only, not about the API, nor the UI.
I just want to know when Gecko sends a NDEF_WRITE PDU, how do we know we need to cache it (for push) or not?

The ndefPush you mentioned in called when ontechdiscovered happended, and you said that daemon should check the sessionId for the previous techdiscovered. In this case, which ontechdiscovered? the 1st or the 2nd one?

Also what if the app calls ndefPush even ontechdiscovered not happening yet?
So what sessionId will be included in the NDEF_WRITE_PDU ?

And please reply Comment 54, enable/disable nfc hardware in Config PDU.

And finally, which PDU is used to notify a NDEF is received? as I've asked in the beginning of this comment.

thanks

    
    

    
  


  
Changes:
- Added NDEF_FORMATABLE to tech list (renamed numerals)
- Framing
- Resolve inconsistencies with only three base PDUs
- Define powerLevel of ConfigRequest

        Attachment #801486 -
        Attachment is obsolete: true

    
    

    
  
Hi, Siddartha

So the gecko receives the ontechdiscovered with {P2P, NDEF} when the ndef pushed by the other device comes,
then gecko will have to call ndefRead
So nfcd has to keep the ndef util ndefRead is called.

What if the other side of NFC devices pushes 'two' NDEFs ?
Now the gecko will call two ndefRead ?
And in the daemon side, which ndef (the 1st or the 2nd) shall be read by gecko ?
FIFO?
Or should we add some ID mapping ?

Why cannot we just add a PDU for this kind of notification and pass the ndef directly?

Also I have another question about two ontechdiscovered in P2P mode,
the 2nd ontechdiscovered seems not so correct, because P2P is contained in both ontechdiscovered, why P2P will be discovered twice?

Shouldn't we rename the 2nd ontechdiscovered to like 'on-ndef-received' or 'on-tech-changed'?

Thanks

    
    

    
  
Hi Yoshi,

>> So nfcd has to keep the ndef util ndefRead is called.
Yes, we may have to keep 'ndef' till gecko does a 'ndefRead'. If in case passive tag / P2P device is removed from the vicinity, then nfcd sends a onTechLost notification. In that case, nfcd will clear our 'ndef Message' object (that was waiting to be read).

>> What if the other side of NFC devices pushes 'two' NDEFs ?
 Can you send two / multiple NDEF messages in one shot ? I don't think you can do it on Android. However NDEF message can contain two records. But in effect , again one ndef notification.

That said, maybe you can hack a tag to contain two separate NDEF messages, but I think Android would parse the only first NDEF message based on its length, (and will ignore the second NDEF msg)

Did I understand your question correctly here ? 

So in short, If a second NDEF message were to be notified to Gecko, nfcd should get a 'techLost' for the first ndef message.What do you think?

>> Why cannot we just add a PDU for this kind of notification and pass the ndef directly?

Isn't NdefReadResponse exactly do the same ? But I also get your point. If the assumption is that somehow, nfcd may send multiple (two) NDEF messages in one shot, then we may revisit. But since that may not happen, we should be ok. What do you think?

 >> Also I have another question about two ontechdiscovered in P2P mode.
Once nfcd notifies Gecko of P2P device in near vicinity, Gecko notifies the same to the upper layers.
In order for the second P2P tech-discover to happen, user must take away the phone from the near-field and bring it back again. In that case nfcd will notify with 'onTechLost()'  before notifying again with 'onTechDiscovered(P2P, NDEF)'.

I hope I understood your questions correctly here...

    
    

    
  
(In reply to Yoshi Huang(OOO ~ 10/14)[:allstars.chh][:yoshi] from comment #65)
> What if the other side of NFC devices pushes 'two' NDEFs ?
> Now the gecko will call two ndefRead ?

Let me add some thoughts to this discussion. A passive tag may contain multiple TLV blocks, therefore it is quite possible for a tag to carry more than one NDEF message (of course not every TLV block needs to be NDEF, but that is another issue). Likewise, you can pipe any data over an existing LLCP connection in P2P mode (not just NDEF messages). It would be quite possible to send two NDEF messages over the same LLCP connection.

Here is what Android does: if a tag contains multiple NDEF messages, only *one* NDEF_DISCOVERED intent will be fired. The dispatch is based on the type of the first NDEF record of the first NDEF message. The recipient application can access all NDEF messages (in fact, the Android API returns an array of NDEF messages). In P2P mode, Android allows to send only *one* NDEF message. This makes sense if you consider the use of NFC (0-click interaction). I don't think there is a good use case for sending multiple NDEF messages during one P2P interaction.

Here is what we can (should) do: right now the tag reading API only returns the first NDEF message. We might want to generalize that to return an array of NDEF messages to mimic the Android API. For P2P, we should only allow one NDEF message to be sent. This also gets around having to buffer NDEF messages at the receiving side.

> Also I have another question about two ontechdiscovered in P2P mode,
> the 2nd ontechdiscovered seems not so correct, because P2P is contained in
> both ontechdiscovered, why P2P will be discovered twice?

Well, the intent was that the second ontechdiscovered has an updated tech list (that is why the "tech" field is a byte array). If you like, we can rename the "tech" field to "cumulativeTech". Introducing a new PDU seems like overkill.

Arno

    
    

    
  
(In reply to Siddartha P from comment #66)
> Hi Yoshi,
> 
> >> So nfcd has to keep the ndef util ndefRead is called.
> Yes, we may have to keep 'ndef' till gecko does a 'ndefRead'. If in case
> passive tag / P2P device is removed from the vicinity, then nfcd sends a
> onTechLost notification. In that case, nfcd will clear our 'ndef Message'
> object (that was waiting to be read).
> 
Why does daemon have to keep this ndef?
Why cannot it pass to gecko?

> >> What if the other side of NFC devices pushes 'two' NDEFs ?
>  Can you send two / multiple NDEF messages in one shot ? I don't think you
> can do it on Android. 
>
The Device A calls
connect,
writeNdef-1,
close,
connect,
writeNdef-2,
close

Cannot NFC do this?

> 
> So in short, If a second NDEF message were to be notified to Gecko, nfcd
> should get a 'techLost' for the first ndef message.What do you think?
>
doesn't make sense to me.
SessionId will be different when the 2nd NDEF is received.

> Isn't NdefReadResponse exactly do the same ? 
No, although the PDU may looks similar.
One is response and the other is a notification.

>But I also get your point. If
> the assumption is that somehow, nfcd may send multiple (two) NDEF messages
> in one shot, then we may revisit. But since that may not happen, we should
> be ok. What do you think?
> 
I think the protocol isn't correct when in P2P mode, I don't think is it okay here.

>  >> Also I have another question about two ontechdiscovered in P2P mode.
> Once nfcd notifies Gecko of P2P device in near vicinity, Gecko notifies the
> same to the upper layers.
> In order for the second P2P tech-discover to happen, user must take away the
> phone from the near-field and bring it back again. In that case nfcd will
> notify with 'onTechLost()'  before notifying again with
> 'onTechDiscovered(P2P, NDEF)'.
> 
Sorry I didn't understand your question.

By your proposal, when device A writes a NDEF, device B will get a tech-discovered(NDEF, P2P),
not when the two devices are tapping each other.
When tapping each other, they will only get tech-discovered(NDEF).

    
    

    
  
(In reply to arno from comment #67)
> (In reply to Yoshi Huang(OOO ~ 10/14)[:allstars.chh][:yoshi] from comment
> #65)
> > What if the other side of NFC devices pushes 'two' NDEFs ?
> > Now the gecko will call two ndefRead ?
> 
> Here is what Android does: ...
> In P2P mode, Android allows to send only *one*
> NDEF message. This makes sense if you consider the use of NFC (0-click
> interaction). I don't think there is a good use case for sending multiple
> NDEF messages during one P2P interaction.
> 
But we're talking about WebAPI and Gonk protocol on FirefoxOS here,
if it's NFC-compatible,
I'd like to ask the correct behavior here.

So from your WebNFC prososal, writeNdef for P2P mode can be called only once in the same session?
Can you add some documentation for this?
And daemon or the nfc-library will reject the 2nd writeNdef in P2P?

> 
> > Also I have another question about two ontechdiscovered in P2P mode,
> > the 2nd ontechdiscovered seems not so correct, because P2P is contained in
> > both ontechdiscovered, why P2P will be discovered twice?
> 
> Well, the intent was that the second ontechdiscovered has an updated tech
> list (that is why the "tech" field is a byte array). If you like, we can
> rename the "tech" field to "cumulativeTech". Introducing a new PDU seems
> like overkill.
> 
Making things correct is not overkill, I think.

BTW, can you update the documentation in WebNFC, https://wiki.mozilla.org/WebAPI/WebNFC ?
Specially in the P2P mode. Can you give more examples on the reader/writer side ?
Also can readNDEF be called in P2P mode?

The 2nd ontechdiscovered(P2P, NDEF) doesn't quite make sense here,
also it didn't make sense that daemon has to keep the ndef until gonk is calling READ_NDEF, and is the READ_READ called by Gecko itself or Gaia App?

    
    

    
  
Also from W3C NFC, there is a callback for receiving NDEF in P2P mode, call onmessageread.

Can you show your proposal for receiving NDEF in P2P mode?

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #69)
> (In reply to arno from comment #67)
> > (In reply to Yoshi Huang(OOO ~ 10/14)[:allstars.chh][:yoshi] from comment
> > #65)
> > > What if the other side of NFC devices pushes 'two' NDEFs ?
> > > Now the gecko will call two ndefRead ?
> > 
> So from your WebNFC prososal, writeNdef for P2P mode can be called only once
> in the same session?
> Can you add some documentation for this?
> And daemon or the nfc-library will reject the 2nd writeNdef in P2P?

Yes, the second writeNdef should result in an error. We will update the Wiki accordingly. Again, note that Android's API does not allow to send two NDEF messages over a P2P connection. If we do something else here (e.g., allow the sending two NDEF messages) we will loose interoperability with Android.

> > > Also I have another question about two ontechdiscovered in P2P mode,
> > > the 2nd ontechdiscovered seems not so correct, because P2P is contained in
> > > both ontechdiscovered, why P2P will be discovered twice?
> > 
> > Well, the intent was that the second ontechdiscovered has an updated tech
> > list (that is why the "tech" field is a byte array). If you like, we can
> > rename the "tech" field to "cumulativeTech". Introducing a new PDU seems
> > like overkill.
> > 
> Making things correct is not overkill, I think.

How do you define "correct"? If you accept that NDEF is a technology, it is an elegant solution to update the technology list.

> Also can readNDEF be called in P2P mode?

No, it cannot. Garner will add new IDL in similar to the W3C's NFCPeer interface. This interface will not have a read function.

> The 2nd ontechdiscovered(P2P, NDEF) doesn't quite make sense here,
> also it didn't make sense that daemon has to keep the ndef until gonk is
> calling READ_NDEF, and is the READ_READ called by Gecko itself or Gaia App?

You can argue about the second TECH_DISCOVERED but in our opinion it is a clean and elegant solution. nfcd has to maintain state anyways and keep the (at most) one NDEF message is not a problem.

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #70)
> Also from W3C NFC, there is a callback for receiving NDEF in P2P mode, call
> onmessageread.
> 
> Can you show your proposal for receiving NDEF in P2P mode?

All NDEF messages are delivered using the same mechanism, independent of their origin (passive tag or P2P): via the MozActivity mechanism. One strength of our API proposal is that an app will be launched in response to an incoming NDEF message. This is not supported by W3C. Their onmessageread assumes that the application is already running.

    
    

    
  
(In reply to arno from comment #71)
> > Making things correct is not overkill, I think.
> 
> How do you define "correct"? If you accept that NDEF is a technology, it is
> an elegant solution to update the technology list.
> 
                         ^^^^^^^^

Aha, again, "update" the technology list through a "tech-discovered" callback,
to notify gonk that a NDEF technology is discovered, *but actually it tries to notify there's a NDEF Message is received in daemon side.*

For Tag, it makes sense to notify gonk that the other end (the Nfc Tag) has a compliant Nfc-technology, so the gecko could pass the callback to Gaia, and let Gaia app to decide whether it needs to read that tag or not.

But for device, this callback actually means a NDEF is received in daemon side.
Not a NDEF technology is discovered.
Which is totally differnt than the situation above.

> 
> > The 2nd ontechdiscovered(P2P, NDEF) doesn't quite make sense here,
> > also it didn't make sense that daemon has to keep the ndef until gonk is
> > calling READ_NDEF, and is the READ_READ called by Gecko itself or Gaia App?
> 
> You can argue about the second TECH_DISCOVERED but in our opinion it is a
> clean and elegant solution. nfcd has to maintain state anyways and keep the
> (at most) one NDEF message is not a problem.

I know it isn't a problem, but it doesn't make sense.
Why does daemon has to keep the ndef anyway?
Why cannot daemon pass it to gecko?
Why cannot Gecko passe the NDEF to Gaia that a NDEF is received from the remote-end device?

    
    

    
  
(In reply to arno from comment #72)
> One
> strength of our API proposal is that an app will be launched in response to
> an incoming NDEF message. This is not supported by W3C. Their onmessageread
> assumes that the application is already running.

W3C does support system-message. http://www.w3.org/2012/sysapps/runtime/

But W3C NFC hasn't included this yet, because other priority API, like W3C telephony API, W3C Messaging API are still in-discussion.

But still, even the app is already running, I'd like to see how your API delivers the ndef.

    
    

    
  
(In reply to arno from comment #71)
> (In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #69)
> > (In reply to arno from comment #67)
> > > (In reply to Yoshi Huang(OOO ~ 10/14)[:allstars.chh][:yoshi] from comment
> > > #65)
> > > > What if the other side of NFC devices pushes 'two' NDEFs ?
> > > > Now the gecko will call two ndefRead ?
> > > 
> > So from your WebNFC prososal, writeNdef for P2P mode can be called only once
> > in the same session?
> > Can you add some documentation for this?
> > And daemon or the nfc-library will reject the 2nd writeNdef in P2P?
> 
> Yes, the second writeNdef should result in an error. We will update the Wiki
> accordingly. Again, note that Android's API does not allow to send two NDEF
> messages over a P2P connection. If we do something else here (e.g., allow
> the sending two NDEF messages) we will loose interoperability with Android.
> 

Hi arno
  I have question about the second NDEF write through P2P connection.
  Following is the test flow :
  1. Establish p2p connection for two Nexus4 with mozilla nfcd.
  2. One device's SnepClient connect to another device's SnepServer
     SnepClient and SnepServer implementation is almost the same as android.
  3. Use SnepClient put function to send first NDEF message through the connection.
     from log SnepServer did receive the ndef message.
  4. Use SnepClient put function to send second NDEF message through the connection.
     from log SnepServer did receive the ndef message.

  So it will be ok we send multiple NDEF message through a Snep Client/Server connection.
  We can also send multiple NDEF message with each time when we want to send a NDEF message we create a new client   connect to remote SnepServer.

  So I am not sure which Android API do you mean cannot send two NDEF message ?

> > > > Also I have another question about two ontechdiscovered in P2P mode,
> > > > the 2nd ontechdiscovered seems not so correct, because P2P is contained in
> > > > both ontechdiscovered, why P2P will be discovered twice?
> > > 
> > > Well, the intent was that the second ontechdiscovered has an updated tech
> > > list (that is why the "tech" field is a byte array). If you like, we can
> > > rename the "tech" field to "cumulativeTech". Introducing a new PDU seems
> > > like overkill.
> > > 
> > Making things correct is not overkill, I think.
> 
> How do you define "correct"? If you accept that NDEF is a technology, it is
> an elegant solution to update the technology list.
> 
> > Also can readNDEF be called in P2P mode?
> 
> No, it cannot. Garner will add new IDL in similar to the W3C's NFCPeer
> interface. This interface will not have a read function.
> 
> > The 2nd ontechdiscovered(P2P, NDEF) doesn't quite make sense here,
> > also it didn't make sense that daemon has to keep the ndef until gonk is
> > calling READ_NDEF, and is the READ_READ called by Gecko itself or Gaia App?
> 
> You can argue about the second TECH_DISCOVERED but in our opinion it is a
> clean and elegant solution. nfcd has to maintain state anyways and keep the
> (at most) one NDEF message is not a problem.

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #74)
> (In reply to arno from comment #72)
> > One
> > strength of our API proposal is that an app will be launched in response to
> > an incoming NDEF message. This is not supported by W3C. Their onmessageread
> > assumes that the application is already running.
> 
> W3C does support system-message. http://www.w3.org/2012/sysapps/runtime/
> 
> But W3C NFC hasn't included this yet, because other priority API, like W3C
> telephony API, W3C Messaging API are still in-discussion.
> 
> But still, even the app is already running, I'd like to see how your API
> delivers the ndef.

MozActivity is always used to deliver an NDEF, even if the app already runs. There is no need to introduce different API.

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #73)
> I know it isn't a problem, but it doesn't make sense.
> Why does daemon has to keep the ndef anyway?
> Why cannot daemon pass it to gecko?
> Why cannot Gecko passe the NDEF to Gaia that a NDEF is received from the
> remote-end device?

we'll update the protocol so that NDEF messages are immediately passed to Gecko. Stay tuned...

    
    

    
  
(In reply to dlee from comment #75)
> (In reply to arno from comment #71)
> > (In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #69)
> > > (In reply to arno from comment #67)
> > > > (In reply to Yoshi Huang(OOO ~ 10/14)[:allstars.chh][:yoshi] from comment
> > > > #65)
> > > > > What if the other side of NFC devices pushes 'two' NDEFs ?
> > > > > Now the gecko will call two ndefRead ?
> > > > 
> > > So from your WebNFC prososal, writeNdef for P2P mode can be called only once
> > > in the same session?
> > > Can you add some documentation for this?
> > > And daemon or the nfc-library will reject the 2nd writeNdef in P2P?
> > 
> > Yes, the second writeNdef should result in an error. We will update the Wiki
> > accordingly. Again, note that Android's API does not allow to send two NDEF
> > messages over a P2P connection. If we do something else here (e.g., allow
> > the sending two NDEF messages) we will loose interoperability with Android.
> > 
> 
> Hi arno
>   I have question about the second NDEF write through P2P connection.
>   Following is the test flow :
>   1. Establish p2p connection for two Nexus4 with mozilla nfcd.
>   2. One device's SnepClient connect to another device's SnepServer
>      SnepClient and SnepServer implementation is almost the same as android.
>   3. Use SnepClient put function to send first NDEF message through the
> connection.
>      from log SnepServer did receive the ndef message.
>   4. Use SnepClient put function to send second NDEF message through the
> connection.
>      from log SnepServer did receive the ndef message.
> 
>   So it will be ok we send multiple NDEF message through a Snep
> Client/Server connection.
>   We can also send multiple NDEF message with each time when we want to send
> a NDEF message we create a new client   connect to remote SnepServer.
> 
>   So I am not sure which Android API do you mean cannot send two NDEF
> message ?

Don't compare LLCP to a general transport mechanism such as TCP. It would also be possible to push arbitrary binary data via LLCP but that would break interoperability with Android. While this would be possible on the nfcd level, Android's Java API does not allow to push anything but exactly one NDEF message during a P2P session:

http://developer.android.com/guide/topics/connectivity/nfc/nfc.html#p2p

    
    

    
  


  
Inline NDEF message in TechDiscoveredNotification if the discovered technology contains a NDEF message.

        Attachment #812904 -
        Attachment is obsolete: true

    
    

    
  
Thanks Arno.

But I think it still has some problems,
we should not use tech-discovered callback to deliver the NDEF in P2P.

P15.
<quote>
The TechDiscoveredNotification is sent by nfcd to notify Gonk that *a NFC-compatible technology has been discovered*.
</quote>

I think tech-discovered and ndef-received are two different things.

The former is to notify the enumeration of the NFC-compatible technologies on the other end(tag or device).
But the latter is to notify a NDEF has been received.

And below in the same page
<quote>
The origin of the discovered NDEF Message can either be a passive tag or on the receiving side of P2P push.
</quote> 

Is it a typo for the 'receiving side'? I think it should be 'sending side'.

Also I am not quite sure what this means.
What is the 'discovered NDEF Message' ?

Do you mean 'discovered NDEF technology'?
But if it's P2P, NDEF shouldn't be included in the techList.

'Discovered NDEF Message' is not a correct term per se.
In P2P, the NDEF Message is *received*. 
*Discovered* means the device itself has to seek and send inquiries to ask,
then it *discovered* the NDEF if there's any available.
But actually the NDEF is delivered by itself, sent by the other device.

Also does it mean that is it's a passive tag, then daemon has to read the NDEF beforehand?
But for the tag, the app should only get the NDEF if he wants to call readNdef.

P16
TechLostNotification is sent not only when a NFC tag is removed, but also a NFC device.

I'd suggest to add a NdefReceivedNotification, and move the ndefMsg to this notification.

What do you think?

thanks

    
    

    
  
After discussing with Dimi,
I re-phrase my questions.
Please ignore Comment 80

Sorry for the noise

(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #80)
> P15.
> <quote>
> The origin of the discovered NDEF Message can either be a passive tag or on
> the receiving side of P2P push.
> </quote> 
> 
> Is it a typo for the 'receiving side'? I think it should be 'sending side'.
> 
> Also I am not quite sure what this means.
> What is the 'discovered NDEF Message' ?
> 
> Do you mean 'discovered NDEF technology'?
> But if it's P2P, NDEF shouldn't be included in the techList when two devices tapping > each other .
> 
> Does it mean that is it's a passive tag> then daemon has to read the
> NDEF beforehand?
> Like Android does in 
> http://developer.android.com/reference/android/nfc/tec/Ndef.html#getCachedNdefMessage
> 
> P16
> TechLostNotification is sent not only when a NFC tag is removed, but also a
> NFC device.
>

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #81)
> After discussing with Dimi,
> I re-phrase my questions.
> Please ignore Comment 80

Yoshi: do you have additional questions? You wrote that you would re-phrase your questions but comment #81 didn't have any questions.

    
    

    
  
Sorry for not making clear,
I removed some questions from Comment 80,
so the remaining questions are in Comment 81

    
    

    
  
(In reply to arno from comment #78)
> Android's Java API does not allow to push anything but exactly one
> NDEF message during a P2P session:
> 
> http://developer.android.com/guide/topics/connectivity/nfc/nfc.html#p2p

Arno, can you help to explain why writing/receiving multiple NDEF Messages could break compatibility with Android during P2P session?

AFAIK, Android does support writing only one Ndef during P2P session.
But when it still can receive multiple NDEFs from a device during a P2P session, right?

So even FirefoxOS phones could write multiple NDEFs, Android phone still can receive those.

Or do we miss something?

Thanks

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #81)
> > P15.
> > <quote>
> > The origin of the discovered NDEF Message can either be a passive tag or on
> > the receiving side of P2P push.
> > </quote> 
> > 
> > Is it a typo for the 'receiving side'? I think it should be 'sending side'.

No typo. I do mean receiving side. There is a sender and a receiver of a NDEF message during a NDEF Push. The receiver will get a TechDiscoveredNotification with 'NDEF" in the tech list. In that sense it is similar to reading a passive tag. In both cases you have an incoming NDEF message what will be piggybacked with the TechDiscoveredNotification.

> > Also I am not quite sure what this means.
> > What is the 'discovered NDEF Message' ?

I mean the NDEF message that you either read from the passive tag or received during a P2P Push. Perhaps this language is better: "the NDEF message that triggered the TechDiscoveredNotification"

> > Do you mean 'discovered NDEF technology'?
> > But if it's P2P, NDEF shouldn't be included in the techList when two devices tapping > each other .

When two P2P devices are brought close to each other, both will get a TechDiscoveredNotification with only ["P2P"] as the tech list. Each peer will do the "shrinking UI" if appropriate. Only when one side actually pushes an NDEF message (when the user taps the shrinking UI) the other peer (the receiving side of the NDEF Push) will get a second TechDiscoveredNotification with a tech list ["P2P", "NDEF"]. In this case the NDEF message that was received will also be included in the TechDiscoveredNotification.


> > Does it mean that is it's a passive tag> then daemon has to read the
> > NDEF beforehand?
> > Like Android does in 
> > http://developer.android.com/reference/android/nfc/tec/Ndef.html#getCachedNdefMessage

Yes, but you already do this! How else do you know that the tag contains an NDEF message so that you can trigger the TechDiscoveredNotification with ["NDEF"] as the tech list? In nfcd you already read the payload if it is a NDEF message. Wasn't the whole point of the changes in 1.7 that you didn't want to cache this NDEF message but wanted to send it directly to Gonk?

> > P16
> > TechLostNotification is sent not only when a NFC tag is removed, but also a
> > NFC device.

Yes. Will fix this in 1.8

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #84)
> (In reply to arno from comment #78)
> > Android's Java API does not allow to push anything but exactly one
> > NDEF message during a P2P session:
> > 
> > http://developer.android.com/guide/topics/connectivity/nfc/nfc.html#p2p
> 
> Arno, can you help to explain why writing/receiving multiple NDEF Messages
> could break compatibility with Android during P2P session?
> 
> AFAIK, Android does support writing only one Ndef during P2P session.
> But when it still can receive multiple NDEFs from a device during a P2P
> session, right?
> 
> So even FirefoxOS phones could write multiple NDEFs, Android phone still can
> receive those.
> 
> Or do we miss something?
> 
> Thanks

Well, that would be worth an experiment. Android does support the reading of multiple NDEF messages that are contained on a passive tag. This might also work if you push multiple NDEF messages. The only problem I see is the timing. Lets say you push the first NDEF message. The receiver does the read and will get that first NDEF message. Then the sender sends a second NDEF message. How does the receiver even know that there is a second NDEF message in the pipe? (keep in mind that the second NDEF message will not go through the regular tag dispatch but will be delivered to the same app that received the first NDEF message). For a passive that this is not a problem because all NDEF messages contained on the tag will be read in one atomic operation, so there is no timing problem.

Should we be conservative and disallow the writing of a second NDEF message or just assume that Android will 'do the right thing' (whatever that may be)? Since Android only allows the sending of one NDEF message, I'm inclined to impose the same restriction for us.

    
    

    
  
(In reply to arno from comment #85)
> (In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #81)
> > > P15.
> > > <quote>
> > > The origin of the discovered NDEF Message can either be a passive tag or on
> > > the receiving side of P2P push.
> > > </quote> 
> > > 
> > > Is it a typo for the 'receiving side'? I think it should be 'sending side'.
> 
> No typo. I do mean receiving side. There is a sender and a receiver of a
> NDEF message during a NDEF Push. The receiver will get a
> TechDiscoveredNotification with 'NDEF" in the tech list. 

My interpretation is 

There is a sender and a receiver of a NDEF message during a NDEF Push. The receiver will get a TechDiscoveredNotification with 'NDEF" in the tech list, and a NDEF message contained in the TechDiscoveredNotification.
The origin of the discovered NDEF Message is *from* the *sending* side of P2P push.

The word 'The origin' tells me where is the NDEF message from.

So the protocol should be written as
<quote>
The origin of the discovered NDEF Message can *from* either be a passive tag or on
the *sending* side of P2P push.
</quote> 

How do you think?
 
> 
> > > Does it mean that is it's a passive tag> then daemon has to read the
> > > NDEF beforehand?
> > > Like Android does in 
> > > http://developer.android.com/reference/android/nfc/tec/Ndef.html#getCachedNdefMessage
> 
> Yes, but you already do this! How else do you know that the tag contains an
> NDEF message so that you can trigger the TechDiscoveredNotification with
> ["NDEF"] as the tech list? In nfcd you already read the payload if it is a
> NDEF message. Wasn't the whole point of the changes in 1.7 that you didn't
> want to cache this NDEF message but wanted to send it directly to Gonk?
> 

From Android NFC API, a NDEF_DISCOVERED intent will be broadcasted whether a NfcTag is discovered or a NDEF message is received during P2P.

But from the view of nfcd, 
(A) discovering a NfcTag and reads the NDEF message from the tag
(B) receiving a NDEF message from P2P
are two different ways

So my first intent is have two different PDUs for each. 

For Tag,
techDiscovered with NDEF in the techList tells Gonk a NfcTag is discovered.
Gonk has to call READ_NDEF_REQUEST to get the NDEF message from that tag, and the NDEF message will be included in the READ_NDEF_RESPONSE.

For P2P
techDiscovered with P2P in the techList tells Gonk a Device is discovered.
Then if a NDEF message is received from the other end, we use another PDU to notify GONK, in which the received NDEF message is included. 

Because even from the JNI layer in the NfcApp on Android, they also go through different nofitications.

However it seems to me you'd like to reuse the techDiscovered.
After I discussed with Dimi, we're okay with this.

So for tag
TechDiscovered will have NDEF in the techList, with the NDEF Message is already retrieved from the tag.

For P2P
1st techDiscovered will have P2P in the techList, but ndefMsg is null.
When a NDEF message is received, 
2st techDiscovered will be fired, and have [P2P, NDEF] in the techList, with the ndefMsg is the NDEF message received.

    
  
blocking-b2g: --- → 1.3+

    
  
Whiteboard: [FT:RIL]

    
    

    
  
(In reply to arno from comment #85)
> > > P16
> > > TechLostNotification is sent not only when a NFC tag is removed, but also a
> > > NFC device.
> 
> Yes. Will fix this in 1.8

Also need to remove "JSON" keyword in 1.8

    
    

    
  
For the ConfigRequest,
There should be additional value for powerLevel.

0: POWER_OFF
1: LOW_POWER
2: FULL_POWER

If FULL_POWER means "exit low power mode", then there should be also a 
3: POWER_ON

Turn on a NFC chip is different from going to full power mode.
And daemon will need an additional value to distinguish it.

    
    

    
  
Also what's the difference between
NDEF_WRITABLE
and 
NDEF_FORMATABLE 
?

    
    

    
  
(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #90)
> Also what's the difference between
> NDEF_WRITABLE

A tag that currently contains some NDEF message, that is writable, and is not marked as read-only.

> and 
> NDEF_FORMATABLE 

A tag that is currently empty (does not contain a NDEF message) but could be written with a NDEF message.

    
    

    
  
(In reply to arno from comment #91)
> (In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #90)
> > Also what's the difference between
> > NDEF_WRITABLE
> 
> A tag that currently contains some NDEF message, that is writable, and is
> not marked as read-only.
> 
> > and 
> > NDEF_FORMATABLE 
> 
> A tag that is currently empty (does not contain a NDEF message) but could be
> written with a NDEF message.

As i know android check if there is NDEF in a tag and add NDEF technology when tag discovered, and also check
if tag is formatable and add NDEF_FORMATABLE technology.

Android do not define the NDEF_WRITABLE technology.
So are you suggesting when tag discover, nfcd should check if it is writable and add NDEF_WRITABLE technology ?

    
    

    
  
(In reply to dlee from comment #92)
> As i know android check if there is NDEF in a tag and add NDEF technology
> when tag discovered, and also check
> if tag is formatable and add NDEF_FORMATABLE technology.
> 
> Android do not define the NDEF_WRITABLE technology.
> So are you suggesting when tag discover, nfcd should check if it is writable
> and add NDEF_WRITABLE technology ?

You are right. Android does not have a NDEF_WRITABLE technology. You can find out via NDEFDetailsRequest whether the tag is writable, so you don't need that technology. At the same time it doesn't hurt to add it and it will save one roundtrip if you want to know if the tag is writable. I leave it up to you. Make a decision and I will update the specs accordingly.

    
    

    
  
removing dependencies on user stories.
No longer blocks: 894320, 894323, 894672, 894673, 894676, 894678, 894689, 894691, 904246

    
    

    
  
Hi, do we have a clear view on the target milestone on this bug now? Thanks.

    
    

    
  
This bug depends on bug 674741. Once 674741 is fixed, this bugs is fixed. Set target milestone as sprint 5.
Target Milestone: --- → 1.3 Sprint 5 - 11/22

    
    

    
  


  
- Change ConfigRequest PDU to use hardwareState instead of powerLevel
- Remove mentioning of JSON marshalling
- Clarify the origin of NDEF messages in TechDiscoveredNotification PDU

        Attachment #817486 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 793573 [details]
C++ classes for nfcd/Gonk PDUs

Remove obsolute code sniplets.

        Attachment #793573 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 793582 [details]
JS implementation of nfcd/Gonk PDUs

Remove obsolute code sniplets.

        Attachment #793582 -
        Attachment is obsolete: true

    
    

    
  
It seems better to finish this bug before sprint5. If you think it isn't reasonable, please update target milestone.

    
    

    
  


  
Add a fourth value for hardwareState in ConfigRequest.

        Attachment #830549 -
        Attachment is obsolete: true

    
  
blocking-b2g: 1.3+ → ---

    
    

    
  
This bug is for discussion, but not a 1.3+ bug.

    
  
Target Milestone: 1.3 Sprint 5 - 11/22 → ---
Whiteboard: [FT:RIL]

    
    

    
  
minus the bug for discussion only
blocking-b2g: --- → -
Depends on: 933588
No longer depends on: 907252

    
    

    
  
Bug 933588 is implemented according to v1.7.

However the differences between 1.7 and 1.9 are:
a) v1.9 adds another value for Config.
b) v1.9 renames powerLevel to hardwareState.

for a), this is requested by Dimi, at that time he met some nfcd crash when setting power level. However this was fixed inside nfcd later. So a) shouldn't be needed for now.

for b), at that time we used Settings to set the power on/off, but now we use API to do this.
We should consider using Request for each power level settings.

So I'll close this as WONTFIX.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: