Subject: [clue] need review of propsed change by Simon to the data model

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 9 Aug 2018 10:21:18 +0000

Hi,
Please review Simon’s proposal bellow
Roni Even
CLUE WG co-chair

From: clue [mailto:[email-masked]] On Behalf Of Simon Pietro Romano
Sent: Monday, August 06, 2018 1:09 PM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13

Please read below for a further (minor) issue we encountered…

****************************************************************************************************************************************
NOTE TO THE GROUP, DATA MODEL RELATED:

While doing the call flow homework, we realized there’s a minor modification that would be desirable inside the data model schema. Namely, there is a “sceneViewIDREF” field that we defined ad IDREF (In terms of XML datatypes). This seemed OK at that time. Though, we now realized that it prevents correct validation of CONFIGURE messages, An example of the mentioned issue can be found in the (NOT currently valid) “Conf+Ack” excerpt I am attaching g below (where the culprit is in bold):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:configure xmlns="urn:ietf:params:xml:ns:clue-info"
 xmlns:ns2="urn:ietf:params:xml:ns:clue-protocol"
 xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:ietf:params:xml:ns:clue-protocol http://wpage.unina.it/spromano/clue-protocol-15-schema-file.xsd"
 protocol="CLUE" v="2.7">
    <ns2:clueId>CP2</ns2:clueId>
    <ns2:sequenceNr>22</ns2:sequenceNr>
    <ns2:advSequenceNr>11</ns2:advSequenceNr>
    <ns2:ack>200</ns2:ack>
    <ns2:captureEncodings>
        <captureEncoding ID="ce123">
           <captureID>AC0</captureID>
           <encodingID>ENC4</encodingID>
        </captureEncoding>
        <captureEncoding ID="ce223">
           <captureID>VC3</captureID>
           <encodingID>ENC1</encodingID>
           <configuredContent>
              <sceneViewIDREF>SE1</sceneViewIDREF>
           </configuredContent>
       </captureEncoding>
    </ns2:captureEncodings>
</ns2:configure>

In order to sort this issue out, it would be sufficient to modify the above mentioned IDREF type and let it become a simpler xs:string. With this modification, we might seamlessly reuse such a data model structure inside CLUE Configure messages (and not just inside Advertisements when describing MCC captures). Do you all agree on this proposal?

****************************************************************************************************************************************

Cheers,

Simon

                                                                        _\\|//_
                                                                           ( O-O )
      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                                                            Simon Pietro Romano
                                                             Universita' di Napoli Federico II
                                         Computer Engineering Department
                         Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]<mailto:[email-masked]>

                            <<Molti mi dicono che lo scoraggiamento è l'alibi degli
                            idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                                                                     oooO
       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                                                                             \ (            (   )
                                                                      \_)          ) /
                                                                       (_/

Il giorno 18 mag 2018, alle ore 04:54, Adam Roach <[email-masked]<mailto:[email-masked]>> ha scritto:

[re-sending due to an IETF mailing list server outage]

On 4/11/18 12:31 PM, Simon Pietro Romano wrote:

Hello Adam!

We finally managed to get our review done. Please find our answers in-line, [SPR]-prefixed, as usual.
...

[SPR] We have not yet added this consideration to the draft. I personally believe this makes sense. Do you think we should add this as a general consideration when introducing the overall state machines?

That would probably be an improvement, yes.

...

[SPR] We will keep this as an Action Point for us, to be fulfilled before submitting the very last version of the draft.

Just a heads up that I'm waiting for the document to incorporate these two open items before progressing it. Thanks!

/a