From jamal.abidar at gmail.com  Wed Oct  3 16:00:55 2007
From: jamal.abidar at gmail.com (jamal ABIDAR)
Date: Wed Oct  3 16:00:59 2007
Subject: [Syncml] Message with only a status on SyncHdr
Message-ID: <11a4d16b0710030700g3fcabdc2ia368dd7c5d601f71@mail.gmail.com>

Hello,

I want to know how should behave a SyncML Client when it receives a message
from the SyncML Server with a NoResp tag in SyncHdr and no command in
SyncBody. Does it have to answer with a message that contains only a status
for the SyncHdr?

If the Client does answer with only a status OK for the SyncHdr then it
doesn't respect the SyncML Norm ("A Status MUST also be returned for the
SyncHdr. However, if a client creates a message containing only a successful
Status on a SyncHdr, the entire message MUST NOT be sent. A server MUST send
this message" - OMA-SyncML-RepPro-V1_1_2-20040711-A.pdf).

The Client can also to not respond to the message in order to respect the
Norm but in this case how is it expected to stop the synchronization by the
client?

What is the right behaviour of the Client regarding this issue?

Cordially,










Hello,

I want to confirm the right behaviour of a client receiving in the middle of
a synchronization from a server, a message with a NoResp tag in the message
header (SyncHdr) but no commands in the body.

Indeed, the SyncML Norm (OMA-TS-DS_DataSyncRep-V1_2-20060710-A.pdf) implies
that the reception of the NoResp tag in SyncHdr implies that the client MUST
NOT return any status for the commands in the body. BUT in our case the
server sends a message with no command in the body and thus the client
responds with a message containing only a status OK for the received SyncHdr
(the SyncHdr is not a command).

With that response we face another problem, the Norm forbids messages sent
by the client containing only a status OK for a SyncHdr ("A Status MUST also
be returned for the SyncHdr. However, if a client creates a message
containing only a successful Status on a SyncHdr, the entire message MUST
NOT be sent. A server MUST send this message" - OMA-SyncML-RepPro-V1_1_2-
20040711-A.pdf).

What is then the right behaviour the client should have? Should it stop the
synchronisation, is it possible for a client to stop the synchronization? or
should he continue and assume that this is an exception to the SyncML Norm
statement?

Note : The message with NoResp tag in SyncHdr is received by the client
before it has received the server objects (vCard, vTodo,vEvent). To my mind
the server should send its changes (commands and objects) at the same time
(same message) it sends the NoResp tag.

Remark : Doesn't the sending (from a server to a client) of a message with
the NoResp tag in SyncHdr automatically imply a client response with only a
status on a SyncHdr?

Thanks in advance for our help.

Cordially,

Jamal ABIDAR.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.axialys.net/pipermail/syncml/attachments/20071003/42cc0cf7/attachment.html
From jamal.abidar at gmail.com  Wed Oct  3 16:03:13 2007
From: jamal.abidar at gmail.com (jamal ABIDAR)
Date: Wed Oct  3 16:03:16 2007
Subject: [Syncml] Message with only a status on SyncHdr
Message-ID: <11a4d16b0710030703o3576dc48xc2edbad6f121616b@mail.gmail.com>

Hello,

I want to know how should behave a SyncML Client when it receives a message
from the SyncML Server with a NoResp tag in SyncHdr and no command in
SyncBody. Does it have to answer with a message that contains only a status
for the SyncHdr?

If the Client does answer with only a status OK for the SyncHdr then it
doesn't respect the SyncML Norm ("A Status MUST also be returned for the
SyncHdr. However, if a client creates a message containing only a successful
Status on a SyncHdr, the entire message MUST NOT be sent. A server MUST send
this message" - OMA-SyncML-RepPro-V1_1_2-20040711-A.pdf).

The Client can also to not respond to the message in order to respect the
Norm but in this case how is it expected to stop the synchronization by the
client?

What is the right behaviour of the Client regarding this issue?

Thanks in advance for your answers,

Cordially,

Jamal ABIDAR.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.axialys.net/pipermail/syncml/attachments/20071003/4fe85eab/attachment.htm