Subject: Re: [siprec] extensionData in XML

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sat, 4 Jun 2011 06:24:28 +0530

Hi all,

Based on the discussion in last interim meeting and mail thread
discussion on
http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and
below mail thread, I have not seen anybody looking for separate
extensiondata metadata XML tag. So, the authors of the draft plans to
revise the next revision with "Extensiondata as an extension within
metadata block" and example is as follows:

         <session id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
          group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" />
           <extensiondata> 
              <call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
                <supervisor>sip:[email-masked]</supervisor>
              </call-center>
           </extensiondata>
         </session>

In case anybody has difference of opinion, Please let us know by coming
Thursday which helps us to update the next revision.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Parthasarathi R (partr)
Sent: Tuesday, April 19, 2011 4:01 PM
To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor
(krehor)
Cc: [email-masked]
Subject: Re: [siprec] extensionData in XML

Dan & all,

Sorry for the late reply. Thanks for sharing your XML experience.
<extension-data> tag is provided as extensions to SIPREC metadata. The
current approach allows to ignore the extension-data in case SRS does
not understand. 

I have added few extensiondata as a note of this mail which were
discussed during earlier SIPREC interim meeting. The open question here
is whether the extension-data has to be passed every time (during
partial-update) within metadata XML tag (participant, session) update or
it is enough to send only when extension-data changes. Partial update of
any specific XML elements  needs unique id. RFC 5261 recommends to use
xml:id or type-id as unique attribute. 

The following example illustrate three different mechanism for
extensiondata:

Extensiondata as separate metadata block: (Current format in the draft -
works for partial update, URN UUID is used in all metadata block as of
now)
         <session id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
          group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" />
         </session>
         <extensiondata
id="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
          parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
          <call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
             <supervisor>sip:[email-masked]</supervisor>
           </call-center>
         </extensiondata>

Extensiondata as separate metadata block using xml:id:(Id reduction)
         <session id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
          group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" />
         </session>
         <extensiondata id="extension1"
          parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
          <call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
             <supervisor>sip:[email-masked]</supervisor>
           </call-center>
         </extensiondata>

Extensiondata as an extension within metadata block: (Ignore the
attribute but needs to be passed in each partial updated)
Example:
         <session id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
          group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" />
           <extensiondata> 
              <call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
                <supervisor>sip:[email-masked]</supervisor>
              </call-center>
           </extensiondata>
         </session>

Please let me know which best suites SIPREC metadata. Including Leon &
Ken explicitly because they provides lot of Extension data attributes
during the discussion of metadata model.

I'm fine with any of the above approach.

Thanks
Partha

Note:
End point information: ip/port, device id (MAC address), DN (used for
the call, in case of multiline). 
Device type: external, station, IVR, routing point, QUEUE, Gateway, MCU,
Operator, etc Participant Role: caller, called, added, last_redirecting,
redirecting, conferencing, queing, redirected AgentId, OSLogin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan Burnett
Sent: Monday, April 11, 2011 9:15 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] extensionData in XML

As someone who works quite a bit with XML, I'll point out that there is
an important distinction between data for extensibility and expected
application-specific data.  As an example of the latter, EMMA [1] is an
XML format for representing the input of a user (human being, commonly)
to an automated system, by speech, gesture, pen, etc.  Since the way an
input is interpreted is dependent upon its intended use, there was a
need for a designated application-specific section to represent the
semantics (meaning) of the input.
To make it easier for machine consumers of this format that may be
seeking the semantics, there is a designated element "interpretation"  
that holds this information.  The contents of this element are arbitrary
XML in an application-specific XML namespace.

On the other hand, every XML specification I've worked on in W3C has  
needed a way for implementers to innovate via extensions.   
Traditionally this is handled via custom elements and attributes in an
implementer-specific namespace to avoid name collision with the standard
elements and attributes.  Since these true innovation extensions can
occur anywhere, there is no specific XML element established in most
specifications for "extensions".  Instead, the specification defines the
expected behavior of a conformant processor upon encountering elements
and attributes outside of the specification's standard namespace.  The
nice thing about this approach is that allows for innovation in a way
that does not cause name collision but which could become part of the
standard in the future (and be moved into the standard's namespace).
For the specifications I worked on, we always required that a conformant
processor had to do the behavior defined in the specification when it
received a conformant document but that the behavior of the processor
when it encountered non-standard elements and attributes was at its own
discretion -- it could process the attributes, ignore them, or report an
error, as it deemed appropriate.

So the real question for us here is whether these extension elements are
*extensions* (which do not require a custom element/location) or
*expected application-specific information* (which can benefit from
custom elements and prescribed locations in the XML tree).

-- dan

[1] http://www.w3.org/TR/emma/

On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote:

>
>
> On 4/6/2011 8:57 AM, Elwell, John wrote:
>> Yes, I would be keen to hear Peter's or other opinions, but one other

>> point. One of the properties of XML is that it is human- readable. 
>> Having extension data as a child element of the element representing 
>> the object to which it applies seems, in my opinion, to make it more 
>> readable. Having extension data as a separate element, with a link to

>> the element to which it applies, seems hard for a human reader, 
>> particularly if the link is a long, random string.
>
> IMO human readability of the xml is a secondary/tertiary concern.
> (SIP is in theory readable, but real sip on the wire tends to be 
> difficult to read due to need to match up non-ergonomic numeric 
> addresses and tags from one message to another.)
>
> I'm inclined to agree it would be better to embed extensions into the 
> basic elements, but not primarily due to readability. IMO extensions 
> should function as much like the predefined parts as possible.
> (Today's extension may become common usage tomorrow.)
>
> I just don't know enough xml to define this "correctly".
>
> 	Thanks,
> 	Paul
>
>> John (as individual)
>>
>>
>>> -----Original Message-----
>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
>>> Sent: 06 April 2011 10:16
>>> To: Elwell, John; Hadriel Kaplan
>>> Cc: [email-masked]; Jain, Rajnish; Peter Saint-Andre (psaintan)
>>> Subject: RE: [siprec] extensionData in XML
>>>
>>> John,
>>>
>>> Please read inline
>>>
>>> Thanks
>>> Partha
>>>
>>> -----Original Message-----
>>> From: Elwell, John [mailto:[email-masked]]
>>> Sent: Wednesday, April 06, 2011 2:02 PM
>>> To: Parthasarathi R (partr); Hadriel Kaplan
>>> Cc: [email-masked]; Jain, Rajnish
>>> Subject: RE: [siprec] extensionData in XML
>>>
>>> I already posted on this topic on the other thread. Partha states 
>>> below an additional motivation for handling extension data in the 
>>> way specified in the current I-D. My counter argument is that anyone

>>> specifying particular extension data could specify the expected 
>>> behaviour when extension data is present in an object and then 
>>> absent when that object is updated. For some types of metadata it 
>>> could be that absence means it no longer applies, and for other 
>>> types of metadata it could be that absence means it has not changed.
>>>
>>> <partha>  Currently, metadata format draft XML element is written 
>>> with the basics that "it is no longer applies" in case specific 
>>> element is absent in the update. The question is how the information

>>> of extensiondata absence means "it is no longer applies" or "it has 
>>> not changed" has to be passed between SRC and SRS. Here, there is a 
>>> need of common understanding between SRC and SRS or else the 
>>> information will be misunderstand even though both parties 
>>> understand the specific extension.
>>>
>>> The current extensiondata is taken the route of all other metadata 
>>> block XML element definition. There may be better way to represent 
>>> in extensiondata XML element apart from creating new metadata block 
>>> with URN UUID. I'm including Peter for his advise on XML 
>>> front.</partha>
>>>
>>> The latter approach would avoid the need for repeating large 
>>> quantities of metadata each time there is a minor change to an 
>>> object.
>>>
>>> John (as individual)
>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Parthasarathi
>>> R (partr)
>>>> Sent: 03 April 2011 19:46
>>>> To: Hadriel Kaplan
>>>> Cc: [email-masked]; Jain, Rajnish
>>>> Subject: Re: [siprec] extensionData in XML
>>>>
>>>> Hadriel,
>>>>
>>>> I guess we have common understaning to the extend that the
>>> intention
>>>> is to send some extensiondata (Unknown) attribute by SRC
>>> which may or
>>>> may not understand by SRS and also for the usage of xs:any as the 
>>>> solution.  Few stuff are missing in yours proposal w.r.t
>>> partial data
>>>> passing of extensiondata:
>>>>
>>>> The question is whether there is a need to pass the extension data 
>>>> during every time the corresponding metadata block is passed or 
>>>> updated. For example, CS metadata block sends extension
>>> data specific
>>>> to call center data like Agent is remote or local, agent or
>>> customer
>>>> initiated call (direction) during the CS block creation
>>> (INVITE) and
>>>> these constant information in extensiondata is not required to be 
>>>> passed in each update of CS metadata like adding video
>>> stream in the
>>>> mid-session.
>>>>
>>>> The current model allows to pass extensiondata only during
>>> the initial
>>>
>>>> CS block creation and there is no need to update or resend while CS

>>>> block is getting updated with other CS information. IMO,
>>> The current
>>>> extensiondata mechanism is required as SIPREC puts lot of
>>> call centre
>>>> specific attributes proposed during metadata model draft review as 
>>>> outside the scope of SIPREC and most of the attributes
>>> mentioned are
>>>> constant within the scope of session.
>>>>
>>>> Also, it is possible to pass update only extension data within RS 
>>>> session without impacting parent element. Please let me
>>> know your and
>>>> others opinion whethter it is fine to continue with the current 
>>>> extension-data element or to move xs:any element to each of the 
>>>> metadata block.
>>>>
>>>> Thanks
>>>> Partha
>>>> ________________________________
>>>>
>>>> From: Hadriel Kaplan [mailto:[email-masked]]
>>>> Sent: Sat 4/2/2011 6:19 PM
>>>> To: Parthasarathi R (partr)
>>>> Cc: Jain, Rajnish; [email-masked]
>>>> Subject: Re: [siprec] extensionData in XML
>>>>
>>>>
>>>>
>>>> Hi Partha,
>>>> I think you're missing my point (or I'm missing yours) - you can do

>>>> all of that without specifying an "extensionData" XML element.
>>>> Unknown XML elements are simply ignored by the other side, so Cisco

>>>> can add a "ciscoPrivateData" XML element wherever it wants
>>> and send it
>>>
>>>> to an Acme; and that private element will be ignored by Acme while 
>>>> everything else will continue to work.  Which I think is
>>> the behavior
>>>> you want, right?
>>>>
>>>> -hadriel
>>>>
>>>>
>>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote:
>>>>
>>>>> Hadriel/Raj,
>>>>>
>>>>> Extensiondata XML is provided as per Metadata model
>>>> extensiondata block.
>>>>> During the initial discussion of metadata model draft, we
>>>> realized that
>>>>> lot of attributes specified for recording are call center
>>>> specific or
>>>>> specific domain related and it is outside the scope of IETF
>>>> SIPREC but
>>>>> it is required for those specific solution to work.
>>>> Extensiondata XML
>>>>> element helps to meet those requirement.
>>>>>
>>>>> Extensiondata is provided with URN UUID to pass or not pass 
>>>>> independently in partial data. But it is open item whether
>>>> extensiondata
>>>>> has to be within specific metadatablock or not.
>>>>>
>>>>> Please read inline for more comments.
>>>>>
>>>>> Thanks
>>>>> Partha
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf
>>>>> Of Jain, Rajnish
>>>>> Sent: Friday, April 01, 2011 6:41 PM
>>>>> To: Hadriel Kaplan; [email-masked]
>>>>> Subject: Re: [siprec] extensionData in XML
>>>>>
>>>>> There may be such motivation from how the CSTA standards
>>>> are specified.
>>>>> They have an element called privateData for each message. It is a 
>>>>> placeholder for any non-standardized extensions. This could
>>>> be legacy
>>>>> and may not mean much for the modern text based protocols.
>>>>>
>>>>> <partha>  I really didn't get the reason why is it not
>>>> require for modern
>>>>> text based protocols. This is more like generic param in
>>>> SIP or xs:any
>>>>> in XML. RFC 6120 is a new RFC which has the similar usage.
>>>>> </partha>
>>>>>
>>>>> That said, I think you're right (this generally applies
>>> to any text
>>>>> based protocols and is the fundamental basis for forward/backward 
>>>>> compatibility in such protocols).
>>>>>
>>>>> Raj
>>>>>
>>>>>
>>>>> -----------------------------------------------------
>>>>> Please consider the environment before printing this email.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked]
>>> [mailto:[email-masked]] On
>>>>>> Behalf Of Hadriel Kaplan
>>>>>> Sent: Thursday, March 31, 2011 8:43 PM
>>>>>> To: [email-masked]
>>>>>> Subject: [siprec] extensionData in XML
>>>>>>
>>>>>> Howdy,
>>>>>> With regards to the extensionData concept and XML, I have
>>>> a few basic
>>>>>> questions.  I am by no means an XML expert so it could
>>>> just be my lack
>>>>>
>>>>>> of knowledge which makes me confused.  If so, just tell
>>> me to RTFM.
>>>>>>
>>>>>> draft-ram-siprec-metadata-04 says in section 4.6:
>>>>>>   A recording metadata object contains additional data not
>>>> specified
>>>>>> as
>>>>>>   part of siprec.  This is intended to accommodate
>>> future standards
>>>>>>   track extensions, as well as vendor and user specific
>>> extensions.
>>>>>>   The mechanism MUST provide a means of unambiguously
>>>> distinguishing
>>>>>>   such extension data.
>>>>>>
>>>>>> What confuses me is I didn't think XML had to do such
>>>> machinations to
>>>>>> accommodate this need.  I thought we could just specify
>>> in our RFCs
>>>
>>>>>> that unknown XML elements and attributes MUST be
>>> ignored, so that
>>>>>> future RFCs could add them without having to leave
>>>> specific "blob" XML
>>>>>
>>>>>> elements to carry such data.  Or at least that's what
>>> we've done so
>>>
>>>>>> far in SIP RFCs with XML bodies, afaik.
>>>>>> namespace model that could be used to disambiguate proprietary 
>>>>>> elements from standard ones.  If both of those theories
>>>> are correct,
>>>>>> why do we need to define an extensionData element?
>>>>>>
>>>>>> -hadriel
>>>>>>
>>>>>> _______________________________________________
>>>>>> siprec mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>
>>>>> DISCLAIMER: This e-mail may contain information that is
>>>> confidential,
>>>>> privileged or otherwise protected from disclosure. If you
>>> are not an
>>>
>>>>> intended recipient of this e-mail, do not duplicate or
>>>> redistribute it
>>>>> by any means. Please delete it and any attachments and
>>>> notify the sender
>>>>> that you have received it in error. Unintended recipients
>>>> are prohibited
>>>>> from taking action on the basis of information in this
>>> e-mail.E-mail
>>>
>>>>> messages may contain computer viruses or other defects,
>>> may not be
>>>>> accurately replicated on other systems, or may be
>>>> intercepted, deleted
>>>>> or interfered with without the knowledge of the sender or
>>>> the intended
>>>>> recipient. If you are not comfortable with the risks
>>> associated with
>>>
>>>>> e-mail messages, you may decide not to use e-mail to
>>>> communicate with
>>>>> IPC. IPC reserves the right, to the extent and under
>>> circumstances
>>>>> permitted by applicable law, to retain, monitor and
>>> intercept e-mail
>>>
>>>>> messages to and from its systems.
>>>>> _______________________________________________
>>>>> siprec mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>
>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> siprec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/siprec
>>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Leon Portman <[email-masked]>
Date: Mon, 6 Jun 2011 11:19:24 +0300

I am ok with the proposal. Looking good

Leon

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]]
Sent: Saturday, June 04, 2011 3:54 AM
To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor (krehor); Rosen, Brian; [email-masked]
Cc: [email-masked]; Peter Saint-Andre (psaintan)
Subject: RE: [siprec] extensionData in XML

Hi all,

Based on the discussion in last interim meeting and mail thread discussion on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and below mail thread, I have not seen anybody looking for separate extensiondata metadata XML tag. So, the authors of the draft plans to revise the next revision with "Extensiondata as an extension within metadata block" and example is as follows:

In case anybody has difference of opinion, Please let us know by coming Thursday which helps us to update the next revision.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Tuesday, April 19, 2011 4:01 PM
To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor
(krehor)
Cc: [email-masked]

Dan & all,

Sorry for the late reply. Thanks for sharing your XML experience.
<extension-data> tag is provided as extensions to SIPREC metadata. The current approach allows to ignore the extension-data in case SRS does not understand.

I have added few extensiondata as a note of this mail which were discussed during earlier SIPREC interim meeting. The open question here is whether the extension-data has to be passed every time (during
partial-update) within metadata XML tag (participant, session) update or it is enough to send only when extension-data changes. Partial update of any specific XML elements  needs unique id. RFC 5261 recommends to use xml:id or type-id as unique attribute.

Extensiondata as separate metadata block: (Current format in the draft - works for partial update, URN UUID is used in all metadata block as of
now)

Extensiondata as an extension within metadata block: (Ignore the attribute but needs to be passed in each partial updated)
Example:

Please let me know which best suites SIPREC metadata. Including Leon & Ken explicitly because they provides lot of Extension data attributes during the discussion of metadata model.

Thanks
Partha

Note:
End point information: ip/port, device id (MAC address), DN (used for the call, in case of multiline).
Device type: external, station, IVR, routing point, QUEUE, Gateway, MCU, Operator, etc Participant Role: caller, called, added, last_redirecting, redirecting, conferencing, queing, redirected AgentId, OSLogin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Burnett
Sent: Monday, April 11, 2011 9:15 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] extensionData in XML

As someone who works quite a bit with XML, I'll point out that there is an important distinction between data for extensibility and expected application-specific data.  As an example of the latter, EMMA [1] is an XML format for representing the input of a user (human being, commonly) to an automated system, by speech, gesture, pen, etc.  Since the way an input is interpreted is dependent upon its intended use, there was a need for a designated application-specific section to represent the semantics (meaning) of the input.
To make it easier for machine consumers of this format that may be seeking the semantics, there is a designated element "interpretation"
that holds this information.  The contents of this element are arbitrary XML in an application-specific XML namespace.

On the other hand, every XML specification I've worked on in W3C has
needed a way for implementers to innovate via extensions.
Traditionally this is handled via custom elements and attributes in an implementer-specific namespace to avoid name collision with the standard elements and attributes.  Since these true innovation extensions can occur anywhere, there is no specific XML element established in most specifications for "extensions".  Instead, the specification defines the expected behavior of a conformant processor upon encountering elements and attributes outside of the specification's standard namespace.  The nice thing about this approach is that allows for innovation in a way that does not cause name collision but which could become part of the standard in the future (and be moved into the standard's namespace).
For the specifications I worked on, we always required that a conformant processor had to do the behavior defined in the specification when it received a conformant document but that the behavior of the processor when it encountered non-standard elements and attributes was at its own discretion -- it could process the attributes, ignore them, or report an error, as it deemed appropriate.

So the real question for us here is whether these extension elements are
*extensions* (which do not require a custom element/location) or *expected application-specific information* (which can benefit from custom elements and prescribed locations in the XML tree).

-- dan

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jun 2011 09:20:53 -0400

I'd like to point out an implication of this approach:

When you send an update to an entity (in the example its a session) and 
include extension data, that extension data applies to the session from 
that time forward until changed.

If you later send another update to the same entity, regardless of your 
reason for sending that update, if you fail to include the extension 
data again you are saying that the extension data no longer applies to 
the session. If you want it to continue to apply you must transmit it 
again. That of course means you must remember what extension data you 
previously sent, so that you *can* send it again.

That may be fine. I just don't want people saying they like this 
approach without having considered the implications.

	Thanks,
	Paul

On 6/6/2011 4:19 AM, Leon Portman wrote:
> Dan&  all,
> Please let me know which best suites SIPREC metadata. Including Leon&  Ken explicitly because they provides lot of Extension data attributes during the discussion of metadata model.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 6 Jun 2011 09:31:33 -0400

I don't understand this.

We can define it that way, but AFAIK, there isn't anything in XML standards that would force that to be true.

An extension point like this just allows you to add some new stuff, defined in a new namespace.  All it really does is allow a way for an older implementation to ignore what is in there if it doesn't understand it.

Brian

---

From: Leon Portman <[email-masked]>
Date: Mon, 6 Jun 2011 16:39:18 +0300

Paul Hi

The behavior that you have described below is consistent with any other partial updates. I do assume that in snapshot we will report the most update extension data, correct?

Regards

Leon

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, June 06, 2011 4:32 PM
To: Paul Kyzivat
Cc: Leon Portman; Parthasarathi R (partr); Dan Burnett; Ken Rehor (krehor); [email-masked]; [email-masked]; Peter Saint-Andre (psaintan)
Subject: Re: [siprec] extensionData in XML

I don't understand this.

Brian

On Jun 6, 2011, at 9:20 AM, Paul Kyzivat wrote:

> When you send an update to an entity (in the example its a session)
> and include extension data, that extension data applies to the session
> from that time forward until changed.
>
> If you later send another update to the same entity, regardless of
> your reason for sending that update, if you fail to include the
> extension data again you are saying that the extension data no longer
> applies to the session. If you want it to continue to apply you must
> transmit it again. That of course means you must remember what
> extension data you previously sent, so that you *can* send it again.
>
>> (krehor); Rosen, Brian; [email-masked]
>> discussed during earlier SIPREC interim meeting. The open question
>> here is whether the extension-data has to be passed every time
>> (during
>> Extensiondata as separate metadata block: (Current format in the
>> draft - works for partial update, URN UUID is used in all metadata
>> block as of
>> now)
>> Device type: external, station, IVR, routing point, QUEUE, Gateway,
>> MCU, Operator, etc Participant Role: caller, called, added,
>> last_redirecting, redirecting, conferencing, queing, redirected
>> AgentId, OSLogin
>>
>>
>>>> Having extension data as a child element of the element
>>>> representing the object to which it applies seems, in my opinion,
>>>> to make it more readable. Having extension data as a separate
>>>> element, with a link to
>>
>>> I'm inclined to agree it would be better to embed extensions into
>>> the basic elements, but not primarily due to readability. IMO
>>> extensions should function as much like the predefined parts as possible.
>>>>> of extensiondata absence means "it is no longer applies" or "it
>>>>> has not changed" has to be passed between SRC and SRS. Here, there
>>>>> is a need of common understanding between SRC and SRS or else the
>>>>> in extensiondata XML element apart from creating new metadata
>>>>> block with URN UUID. I'm including Peter for his advise on XML
>>>>> front.</partha>
>>>>>
>>>>>> The question is whether there is a need to pass the extension
>>>>>> data during every time the corresponding metadata block is passed
>>>>>> or updated. For example, CS metadata block sends extension
>>>>> data specific
>>>>>> specific attributes proposed during metadata model draft review
>>>>>> as outside the scope of SIPREC and most of the attributes
>>>>> mentioned are
>>>>>> to an Acme; and that private element will be ignored by Acme
>>>>>> while everything else will continue to work.  Which I think is
>>>>> the behavior
>>>>>> you want, right?
>>>>>>
>>>>>> -hadriel
>>>>>>
>>>>>>
>>>>>>> They have an element called privateData for each message. It is
>>>>>>> a placeholder for any non-standardized extensions. This could
>>>>>> be legacy
>>>>>>> based protocols and is the fundamental basis for
>>>>>>> forward/backward compatibility in such protocols).
>>>>>>>
>>>>>>> Raj
>>>>>>>
>>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jun 2011 09:52:16 -0400

Brian,

Yeah, this isn't about xml itself, its about how we are using it.
This is the approach taken for all the data in updates to elements.
I guess we could define this as a one-off, or else we could define it as 
a sub-element by sub-element property. But that would seem to be 
confusing. Also, if you did this, then it gets hard to do the converse 
if you do want to remove the extension data for the remainder of a session.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jun 2011 09:54:19 -0400

> The behavior that you have described below is consistent with any other partial updates. I do assume that in snapshot we will report the most update extension data, correct?

Presumably. This becomes part of the *state* that an SRC needs to maintain.

	Thanks,
	Paul

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 6 Jun 2011 09:57:26 -0400

If the rule is "no change if not mentioned" for partial updates, then that would be the same here, right? That's always how partial updates work.  Why can't we define extensions the same way, even if their are multiple of them?  If you need to remove something, then you have to define semantics for that (like assign a null value).

Brian
On Jun 6, 2011, at 9:52 AM, Paul Kyzivat wrote:

> I guess we could define this as a one-off, or else we could define it as a sub-element by sub-element property. But that would seem to be confusing. Also, if you did this, then it gets hard to do the converse if you do want to remove the extension data for the remainder of a session.
>
>       Thanks,
>       Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jun 2011 10:10:06 -0400

> If the rule is "no change if not mentioned" for partial updates, then that would be the same here, right? That's always how partial updates work.  Why can't we define extensions the same way, even…

Anything is possible - all it requires is the right definitions. :-)
Each approach has its own consequences. The consequences I mentioned are 
for the current approach as it has been conceived to date.

What you suggest is possible, but then it would require a syntax to 
distinguish between adding/replacing/removing a sub-element. (Or maybe 
just replacing/removing.) I'll let Partha/Ram comment on that, since 
they are defining the format.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 9 Jun 2011 19:13:29 +0530

Brian,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat (pkyzivat)
Sent: Monday, June 06, 2011 7:40 PM
To: Rosen, Brian
Cc: [email-masked]; Peter Saint-Andre (psaintan)
Subject: Re: [siprec] extensionData in XML

On 6/6/2011 9:57 AM, Rosen, Brian wrote:
> If the rule is "no change if not mentioned" for partial updates, then
that would be the same here, right? That's always how partial updates
work.  

<Partha> Even the current mechanism in metadata format draft is same as
you expect which uses URN UUID.  Here, extensiondata is considered as
separate element which has the property of "no change if not mentioned".
The minor optimization is possible to achieve by using xml:id as
mentioned in the below mail and the minor limitation in the optimization
is that xml:id scope MUST be span across single CSG in different CS in
the model. 

Also, any partial update mechanism of an XML element requires some sort
of unique id. Please look into RFC 5261 for x-path based partial update
which is more complex compare to the current mechanism in the draft.

But the issue raised is to optimize in a way that no unique id is
required to track this extension data element. So, we proposed
extensiondata without any unique-id which has Paul mentioned caveats.
 </Partha>

Why can't we define extensions the same way, even if their are multiple
of them? 
<Partha> The current proposal is inline with your expectation </Partha>

If you need to remove something, then you have to define semantics for
that (like assign a null value).
<Partha> Agreed, the authors will come up "null" value in case we get
the consensus for the current mechanism in the format draft.
 
Thanks
Partha
</Partha>  

	Thanks,
	Paul

>> I guess we could define this as a one-off, or else we could define it
as a sub-element by sub-element property. But that would seem to be
confusing. Also, if you did this, then it gets hard to do the converse
if you do want to remove the extension data for the remainder of a
session.
>>> We can define it that way, but AFAIK, there isn't anything in XML
standards that would force that to be true.
>>>
>>> An extension point like this just allows you to add some new stuff,
defined in a new namespace.  All it really does is allow a way for an
older implementation to ignore what is in there if it doesn't understand
it.

>>>> and include extension data, that extension data applies to the 
>>>> session from that time forward until changed.
>>>>
>>>> extension data again you are saying that the extension data no 
>>>> longer applies to the session. If you want it to continue to apply 
>>>> you must transmit it again. That of course means you must remember 
>>>> what extension data you previously sent, so that you *can* send it
again.
discussion on
metadata block" and example is as follows:
>>>>>           <session
id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
>>>>>                <call-center
xmlns='urn:ietf:params:xml:ns:callcenter'>
>>>>> In case anybody has difference of opinion, Please let us know by
coming Thursday which helps us to update the next revision.
>>>>> <extension-data>    tag is provided as extensions to SIPREC
metadata. The current approach allows to ignore the extension-data in
case SRS does not understand.

>>>>> partial-update) within metadata XML tag (participant, session)
update or it is enough to send only when extension-data changes. Partial
update of any specific XML elements  needs unique id. RFC 5261
recommends to use xml:id or type-id as unique attribute.

>>>>>           <session
id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
>>>>>           <session
id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
>>>>>           <session
id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
>>>>>                <call-center
xmlns='urn:ietf:params:xml:ns:callcenter'>
>>>>> Please let me know which best suites SIPREC metadata. Including
Leon&    Ken explicitly because they provides lot of Extension data
attributes during the discussion of metadata model.
>>>>> Device type: external, station, IVR, routing point, QUEUE, 
>>>>> Gateway, MCU, Operator, etc Participant Role: caller, called, 
>>>>> added, last_redirecting, redirecting, conferencing, queing, 
>>>>> redirected AgentId, OSLogin
>>>>>
>>>>>
>>>>> As someone who works quite a bit with XML, I'll point out that
there is an important distinction between data for extensibility and
expected application-specific data.  As an example of the latter, EMMA
[1] is an XML format for representing the input of a user (human being,
commonly) to an automated system, by speech, gesture, pen, etc.  Since
the way an input is interpreted is dependent upon its intended use,
there was a need for a designated application-specific section to
represent the semantics (meaning) of the input.
>>>>> that holds this information.  The contents of this element are
arbitrary XML in an application-specific XML namespace.
>>>>>
>>>>> On the other hand, every XML specification I've worked on in W3C 
>>>>> has needed a way for implementers to innovate via extensions.
>>>>> Traditionally this is handled via custom elements and attributes
in an implementer-specific namespace to avoid name collision with the
standard elements and attributes.  Since these true innovation
extensions can occur anywhere, there is no specific XML element
established in most specifications for "extensions".  Instead, the
specification defines the expected behavior of a conformant processor
upon encountering elements and attributes outside of the specification's
standard namespace.  The nice thing about this approach is that allows
for innovation in a way that does not cause name collision but which
could become part of the standard in the future (and be moved into the
standard's namespace).
>>>>> For the specifications I worked on, we always required that a
conformant processor had to do the behavior defined in the specification
when it received a conformant document but that the behavior of the
processor when it encountered non-standard elements and attributes was
at its own discretion -- it could process the attributes, ignore them,
or report an error, as it deemed appropriate.
>>>>>>> representing the object to which it applies seems, in my 
>>>>>>> opinion, to make it more readable. Having extension data as a 
>>>>>>> separate element, with a link to
>>>>>

>>>>>>>> I already posted on this topic on the other thread. Partha 
>>>>>>>> states below an additional motivation for handling extension 
>>>>>>>> data in the way specified in the current I-D. My counter 
>>>>>>>> argument is that anyone
>>>>>

>>>>>>>> absent when that object is updated. For some types of metadata 
>>>>>>>> it could be that absence means it no longer applies, and for 
>>>>>>>> other types of metadata it could be that absence means it has
not changed.

>>>>>>>> has not changed" has to be passed between SRC and SRS. Here, 
>>>>>>>> there is a need of common understanding between SRC and SRS or 
>>>>>>>> else the information will be misunderstand even though both 
>>>>>>>> parties understand the specific extension.
>>>>>>>>
>>>>>>>> The current extensiondata is taken the route of all other 
>>>>>>>> metadata block XML element definition. There may be better way 
>>>>>>>> to represent in extensiondata XML element apart from creating 
>>>>>>>> new metadata block with URN UUID. I'm including Peter for his 
>>>>>>>> advise on XML front.</partha>
>>>>>>>>
>>>>>>>>> may not understand by SRS and also for the usage of xs:any as 
>>>>>>>>> the solution.  Few stuff are missing in yours proposal w.r.t
>>>>>>>> partial data
>>>>>>>>> data during every time the corresponding metadata block is 
>>>>>>>>> passed or updated. For example, CS metadata block sends 
>>>>>>>>> extension
>>>>>>>> data specific
>>>>>>>>> these constant information in extensiondata is not required to

>>>>>>>>> be passed in each update of CS metadata like adding video
>>>>>>>> stream in the
>>>>>>>>> mid-session.
>>>>>>>>>
>>>>>>>>> specific attributes proposed during metadata model draft 
>>>>>>>>> review as outside the scope of SIPREC and most of the 
>>>>>>>>> attributes
>>>>>>>> mentioned are
>>>>>>>>> Also, it is possible to pass update only extension data within

>>>>>>>>> RS session without impacting parent element. Please let me
>>>>>>>> know your and
>>>>>>>>> others opinion whethter it is fine to continue with the 
>>>>>>>>> current extension-data element or to move xs:any element to 
>>>>>>>>> each of the metadata block.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Partha
>>>>>>>>>> They have an element called privateData for each message. It 
>>>>>>>>>> is a placeholder for any non-standardized extensions. This 
>>>>>>>>>> could
>>>>>>>>> be legacy
>>>>>>>>>>> namespace model that could be used to disambiguate 
>>>>>>>>>>> proprietary elements from standard ones.  If both of those 
>>>>>>>>>>> theories
>>>>>>>>> are correct,

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 15 Jun 2011 14:49:37 +0530

Hi all,

As there is no clear consensus on any approach, I'll continue to make
the next revision by keeping extensiondata as an open item with the
current text. Let us discuss during the coming interim meeting for the
closure of this open item.

Also, I'm updating extensiondata XML schema definition as per earlier
Peter comment.

<xs:element name='extension-data'>
  <xs:complexType>
      <xs:any     namespace='##other'
                  minOccurs='0'
                  maxOccurs='unbounded'
                  processContents='lax'/>
  </xs:complexType>
  <xs:attribute name="id" type="urnuuid" 
         use="required"/>
  <xs:attribute name="parent" type="urnuuid" 
    use="required"/>
</xs:element>

Thanks
Partha 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Parthasarathi R (partr)
Sent: Thursday, June 09, 2011 7:13 PM
To: Paul Kyzivat (pkyzivat); Rosen, Brian
Cc: [email-masked]; Peter Saint-Andre (psaintan)
Subject: Re: [siprec] extensionData in XML

Brian,

Please read inline.

Thanks
Partha 

-----Original Message-----

 
Thanks
Partha
</Partha>  

	Thanks,
	Paul

again.
discussion on

not changed.