Re: [clue] AD Review: draft-ietf-clue-protocol-13

[Simon Pietro Romano <[e-mail]>]

Dear Roni,

you’re actually right.

A <configuredContent> element is used in a configure message to specify the content of a requested MCC both at a <sceneViewIDREF> level and at a <mediaCaptureIDREF> level. This means we might encounter the issue also with the xs:IDREF type of the  <mediaCaptureIDREF> element.

The quickest solution is to change the type of both <sceneViewIDREF> and <mediaCaptureIDREF> into xs:string in the <configuredContent> type definition (i.e. in the definition of type “contentType”).
Otherwise (and perhaps more properly), a new content type for <configuredContent> can be introduced, having this time <sceneViewIDREF> and <mediaCaptureIDREF> as xs:string.

We’re ok with either of the above and ready to make the necessary modifications to the data model.

Thanks for the feedback!

Simon


                     				            _\\|//_
                           				   ( O-O )
      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department
	             Phone: [phone] -- Fax: [phone]
                                           e-mail: [e-mail]

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



> Il giorno 12 ago 2018, alle ore 09:05, Roni Even (A) <[e-mail]> ha scritto:
> 
> Hi Simon,
> Just to clarify the issue you pointed out in the configure message about
> 
>            <configuredContent>
>            <sceneViewIDREF>SE1</sceneViewIDREF>
>            </configuredContent>
> 
> Your suggestion is to  change the <sceneViewIDREF> from  type “IDREF” to type “xs:string”.
> 
> 
> In the data model  captureEncoding  which is part of the configure message includes
> 
> <xs:element name="configuredContent" type="contentType"   minOccurs="0"/>
> 
> And
> 
> <!-- CONTENT TYPE -->
> <xs:complexType name="contentType">
> <xs:sequence>
>   <xs:element name="mediaCaptureIDREF" type="xs:IDREF"
>   minOccurs="0" maxOccurs="unbounded"/>
>   <xs:element name="sceneViewIDREF" type="xs:IDREF"
>   minOccurs="0" maxOccurs="unbounded"/>
>   <xs:any namespace="##other" processContents="lax" minOccurs="0"
>   maxOccurs="unbounded"/>
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax"/>
> </xs:complexType>
> 
> 
> 
> So is the proposal to change it to
> 
> 
> <!-- CONTENT TYPE -->
> <xs:complexType name="contentType">
> <xs:sequence>
>   <xs:element name="mediaCaptureIDREF" type="xs:IDREF"
>   minOccurs="0" maxOccurs="unbounded"/>
>   <xs:element name="sceneViewIDREF" type="xs:string"
>   minOccurs="0" maxOccurs="unbounded"/>
>   <xs:any namespace="##other" processContents="lax" minOccurs="0"
>   maxOccurs="unbounded"/>
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax"/>
> </xs:complexType>
> 
> 
> Or since sceneViewIDREF appears in other places in the data model change to:
> 
> <!-- CONTENT TYPE -->
> <xs:complexType name="contentType">
> <xs:sequence>
>   <xs:element name="mediaCaptureIDREF" type="xs:IDREF"
>   minOccurs="0" maxOccurs="unbounded"/>
>   <xs:element name="sceneViewID" type="xs:string"
>   minOccurs="0" maxOccurs="unbounded"/>
>   <xs:any namespace="##other" processContents="lax" minOccurs="0"
>   maxOccurs="unbounded"/>
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax"/>
> </xs:complexType>
> 
> 
> The other question was about the other element in the contetType mediaCaptureIDREF defined as
> 
> <xs:element name="mediaCaptureIDREF" type="xs:IDREF"   minOccurs="0" maxOccurs="unbounded"/>
> 
> Is there a problem with it too?
> 
> Thanks
> Roni
> 
> 
> -----Original Message-----
> From: Simon Pietro Romano [mailto:[e-mail]]
> Sent: Friday, August 10, 2018 3:00 AM
> To: Roni Even (A)
> Cc: [e-mail]; Adam Roach
> Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13
> 
> Hello Roni,
> 
>> Are you suggesting a change in the CLUE data model draft the configuredContent?
> 
> 
> No, we would just like to change the <sceneViewIDREF> form type “IDREF” to type “xs:string”.
> 
> Cheers,
> 
> Simon
>                     				            _\\|//_
>                           				   ( O-O )
>      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                    				Simon Pietro Romano
>             				 Universita' di Napoli Federico II
>                		     Computer Engineering Department
> 	             Phone: [phone] -- Fax: [phone]
>                                           e-mail: [e-mail]
> 
> 		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli
> 		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>               			                     oooO
>       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> 					                 \ (            (   )
> 			                                  \_)          ) /
>                                                                       (_/
> 
> 
> 
>> Il giorno 09 ago 2018, alle ore 03:29, Roni Even (A) <[e-mail]> ha scritto:
>> 
>> Hi Simon,
>> Are you suggesting a change in the CLUE data model draft the configuredContent?
>> In this case I was wondering since the configuredContent is of type contentType which also has mediaCaptureIDREF which will not parse in configure message.
>> Can you please explain?
>> 
>> Roni Even as individual
>> 
>> 
>> 
>> 
>> From: clue [mailto:[e-mail]] On Behalf Of Simon Pietro
>> Romano
>> Sent: Monday, August 06, 2018 1:09 PM
>> To: Adam Roach
>> Cc: [e-mail]
>> Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13
>> 
>> Hello Adam!
>> 
>> version -16 of the draft had just been posted. You’ll find there a whole new section (section 10) about the requested call flow. We have added validated excerpts of all of the messages.
>> You’ll notice that we put the following note at the end of the introductory part of section 10:
>> 
>> [[NOTE TO IANA/RFC-EDITOR: For sections 10.1 through 10.9, please
>> replace the clue-protocol xsi:schemaLocation URL (which is currently
>> set to
>> http://wpage.unina.it/spromano/clue-protocol-15-schema-file..xsd) with
>> the right (and final) URL for this specification. The URL ib question
>> is a temporary one, which was published on-line in order to allow for
>> proper validation of the XML excerpts contained in the call flow
>> sections.]]
>> 
>> This was needed because we had to refer to the clue protocol schema file in order to validate the messages.
>> 
>> 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: [phone] -- Fax: [phone]
>>                                           e-mail: [e-mail]
>> 
>>                            <<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 <[e-mail]> 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
>