Subject: [Sipping] RE: WGLC: conference-package-06

From: "Orit Levin" <[email-masked]>
Date: Tue, 2 Nov 2004 16:35:10 -0800

Miguel,
Thanks you very much for the thorough review and all your comments!
I am replying inline and basically agreeing with almost all of the
comments but the first one about the "types" description.
I will update the text right after the IETF reflecting your inputs and
hopefully others' as well.

Thanks again,
Orit.

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: Monday, November 01, 2004 8:22 AM
> To: Jonathan Rosenberg; Henning Schulzrinne; Orit Levin
> Cc: SIPPING mailing list
> Subject: WGLC: conference-package-06
> 
> Hi:
> 
> I have some questions and comments to
> draft-ietf-sipping-conference-package-06.txt
> 
> 
> - General: I noticed that the I-D describes the elements of the 
> Conference Info XML document by describing the XML schema, not a real 
> XML document. For instance, the I-D describes in section 6.1.1 the 
> "Conference-Type", which is a type definition in XML schema, 
> not a real 
> element. This is a general comment that applies to the whole 
> document. 
> My comment is that the textual description should not 
> describe the bits 
> and bytes of the XML schema, but the actual contents of a real 
> Conference Info XML document. In short, there shouldn't be 
> any mention 
> to "types" in Section 6.
I disagree with this one :-(and only this one). My approach was to
consistently describe the elements starting from the top level. Each
element description provides the reasoning for the "element" and its
meaning, and points to its "type". The "type" description later in the
document provides the layout of the type in terms of its own attributes
and sub-elements and so on. Note also that many types are being used by
multiple elements and types.
> 
> - General: - The document speaks quite a bit about "element 
> with keys". 
> It is not clear to me, after trying to understand it a few 
> times, what a 
> key is, and how a key is identified. So I guess you should a bit more 
> effort in defining keys, and describing their identification.
> 
Agree. Will do.

> - General: There are quite a few inconsistencies between the text and 
> the XML schema definition (I actually predicted this will 
> happen sooner 
> or later). For instance, the following attributes are defined as 
> "mandatory" in the text, but they are "optional" in the XML schema:
> 
>      version, state (in various sub elements), entity
> 
> My suggestion is to remove the "mandatory" or "optional" from 
> the text, 
> and make sure that things are right in the schema.
> 
100% agree. Will do.

> - General: There are several instances of a <display-text> element 
> (e.g., Sections 6.1.2.1, 6.1.3.1, 6.1.5.1, 6.1.6.1, 6.1.7.1)
> 
> While I understand that it makes sense to have some display-text 
> information for the conference, the host, or the user, I 
> wonder how this 
> can be of benefit for the endpoint or the media type. Further 
> more, how 
> can someone set this display type for the endpoint or the 
> media type, or 
> how can the conference focus determine it.
>
I would rather leave them in the schema. They are optional and can be
set by any out-of-band/configuration/management means.
 
> - Section 4: After the first paragraph, the URN is missing. Add:
> 
>      urn:ietf:params:xml:ns:conference-info
> 
> - XML schema: since the 'state' attribute has a default value 
> of "full", 
> this should be indicated in the schema. You can do so by 
> replacing all 
> the 'state' attribute declarations with the following one, which 
> includes the default value:
> 
>         <xs:attribute name="state" type="state-type"
>                       use="optional" default="full" />
> 
100%. Will do.
> - Section 5, 4th paragraph says:
> 
>     If it contains "deleted" state,
>     indicated by the value of the "state" attribute in the
>     "conference-info" element, it means that the conference ceased to
>     exist and the subscriber SHOULD terminate the SUBSCRIBE dialog.
> 
> The sentence "the subscriber SHOULD terminate the SUBSCRIBE dialog", 
> does it mean the user SHOULD send a SUBSCRIBE with Expires=0 
> or does it 
> mean the user SHOULD consider implicitly the subscription dead? I 
> suggest the former, but I would like to explicitly say that the UA 
> SHOULD send a SUBSCRIBE with Expires=0 to avoid misunderstandings.
> I also think that the misunderstanding is due to "terminate the 
> SUBSCRIBE dialog", I guess it should refer to the subscription rather 
> than the dialog.
I agree. Will do.
> 
> - Section 6.1.1 reads:
> 
>     version: This mandatory attribute allows the recipient of 
> conference
>        information documents to properly order them.  
> Versions start at 0
>        and increment by one for each new document sent to a 
> subscriber.
>        Versions are scoped within a subscription.  Versions MUST be
>        represented using a 32 bit integer.
> 
> But the XML schema just indicates it is a string:
> 
>       <xs:attribute name="version" type="xs:string" use="optional"/>
> 
> My suggestion is indicate the valid range (0 to 2^32-1) through the 
> schema, something like:
> 
>       <xs:attribute name="version" type="version-type" 
> use="required"/>
> 
>       <!--
>       VERSION TYPE
>       -->
>       <xs:simpleType name="version-type">
>               <xs:restriction base="xs:nonNegativeInteger">
>               		<xs:maxInclusive value="4294967295" />
>             	</xs:restriction>
>       </xs:simpleType>
>
I don't mind. BTW how is the same attribute being defined in other
SIP/SIMPLE/... schemas?  
> 
> - Section 6.1.2.4 <keywords> says:
> 
>     This element contains a list of keywords which describe the
>     conference *topic*.
> 
> I disagree. The topic is indicated in the <subject> element. 
> I think you 
> want to say that the <keywords> element contains a set of 
> words that can 
> be used by automatic search engines to better index the conference.
> 
Will do.
> - Section 6.1.2.6 <conf-uris> says
> 
>     This element contains information about additional conference URIs
>     that this conference can be accessed by.
> 
> This is not correct, the <conf-uris> elements contains one or more 
> <entry> elements, each one describing additional info about the 
> conference. And that makes me think that the name <conf-uris> is not 
> right either, since the URI is hidden in the <entry><uri> element.
> 
Regarding this and the same comments below. I will rephrase the wording
but I really don't want to change the names in the schema. The structure
is not simple but the outer name conveys the semantics of these
elements.

> This comment is also applicable to <service-uris> (6.1.2.7)
> 
> - Section 6.1.2.8 <maximum-user-count> says:
> 
>     This element contains a count of the maximum number of users
>     permitted in the conference.
> 
> Well, the element actually contains one or more <entry> 
> elements, rather 
> than a maximum number of users permitted in the conference. The 
> definition in the schema is:
> 
>      <xs:element name="maximum-user-count"
>               type="user-count-type" minOccurs="0"/>
> 
> I guess this element should have a nonNegativeInteger type 
> rather than 
> user-count-type.
>
The current definition allows to count the participants per their roles.

> - Section 6.1.3.3 <uris> says
> 
>     The "entity" sub-element contains additional URIs relating to the
>     user hosting the conference.
> 
> Obviously this is not the <entity> subelements, but the <uris> 
> sub-element. Also, it can contain one or more <entry> 
> elements, each of 
> them contains additional URIs ...
> 
> - Section 6.1.4.2  <security-level> says:
> 
>     This element contains information about the conference security
>     level.  The values can be "none", "low", "medium", or "high".
> 
> I don't understand how to map each of these values to 
> something else. So 
> what is the "conference security level", where is it 
> described, and how 
> can my application determine if the security level is any of the 
> mentioned above. In short, I am missing some semantics for 
> this element, 
> and some guidance as for how can the focus determine the conference 
> security level.
> 
I copied the definition from the CPCP latest schema. I agree that we
need to add more semantics to it. I hope that we will do it as a part of
our more general effort to align between the two schemas during the
IETF.
> - Section 6.1.5.4 <language> says:
> 
>    This element contains the language used by the user.
> 
> Does this mean the conference is able to recognize the language I am 
> using? I guess not, so perhaps the text should read "This element 
> contains the preferred language used by the SIP application. 
> The focus 
> can determine its contents from the Accept-Contact header 
> field in SIP".
> 
Will do.

> - Section 6.1.6.7. The title of this section reads:
> 
>     disconnection-info of disconnection-type
> 
> Although there is not a disconnection-type, but an execution type.
Will change.
 
> Nevertheless, I hope this comment becomes not applicable, 
> after my other 
> comment indicating that there shouldn't be any "type" mentioned in 
> Section 6.
> 
> - Section 6.1.6.8 <whispering-to> says:
> 
>     If an endpoint is participating in a whisper session with other
>     entities, the URIs of these other entities MAY be 
> contained in this
>     element.
> 
> Absolutely a leak of privacy. If I am whispering to someone might be 
> because I don't want the rest of the conference be aware that I am 
> having a side-by conversation with someone else. This is the main 
> difference between whispering and sidebars.
> 
> If there were some mechanism where I could differentiate a "public 
> whisper" from an "invisible whisper", I wouldn't mind to have this 
> element indicating to who I am whispering. Unfortunately I am 
> not aware 
> of such mechanism, so I suggest to delete this element to 
> avoid leaking 
> privacy information.
> 
I would rather prefer leaving this one because it is a kind of "sidebar"
that is widely implemented and implemented differently from the usual
sidebar techniques. The main difference between this and the plain
sidebar is that it is one-to-many and unidirectional. In terms of
privacy - the package contains a lot of private information that needs
to be filtered by a smart Notification Server in addition to this
particular point anyway.

I will be happy to clarify what "whisper" means and add the privacy
considerations to it. 
> - Section 6.1.7 <media>, speaking about the 'entity' attribute says:
> 
>        The value of this element
>        SHOULD correspond to the "mid" value in the SDP document as
>        defined in Grouping of Media Lines in the SDP [9].
> 
> I don't agree with this. So does it mean I cannot join a 
> conference if 
> my SIP UA does not support the "mid" attribute? I guess there 
> should be 
> some guidelines as for what to do with this attribute if the 
> UA supports 
> basic SDP as per RFC 2327.
> 
Agree 100%. Will add this clarification and the guidelines.

> - Sections 6.1.7.5, 6.1.7.6, 6.1.7.7 and 6.1.7.8
> 
> I don't see the need for so many elements. I guess these 
> properties can 
> be expressed with just a single element, namely <direction>. This new 
> <direction> element can take the values "sendrecv", "sendonly", 
> "recvonly", "inactive", and can be mapped from the corresponding SDP 
> attributes. Note that I didn't forget the "muted" element, 
> since there 
> are no semantics for it, and I don't understand what it means, and I 
> believe it is not required.
> 
> So please take my consideration into account and arrange 
> these sections 
> into one element.
Makes sense. Will do.
> 
> - Section 6.1.7.8 <call>
> 
> I don't understand why <call> is of type call-type, and 
> call-type is of 
> type dialog-id. I guess <call> should be of type dialog-id. I 
> don't see 
> the benefit in so many type indirection.
>
The reason is because the schema is designed not for SIP calls only.
This allows plugging in additional "call identifiers".
> Also this describes the <call-id>, <to-tag> and <from-tag> 
> subelements. 
> You should be associating semantics to the Call-ID header in SIP, the 
> tag in the To and From header fields. Such semantics are not 
> assigned in 
> the current draft.
This was the intention. Will clarify.
> 
> - Section 7. XML extensibility. I noticed that you have 
> invented a new 
> mechanism to extend an XML schema. It seems that the extensibility is 
> provided by an undefined <extended> element. I said undefined 
> because I 
> didn't find its description in Section 6. This element may 
> include any 
> collection of elements from other namespaces. where the required 
> attribute 'namespace' seems to indicate the namespace.
> 
> However XML schema already contains a widely used mechanism to allow 
> extensibility. To define an extension for an element from other 
> namespace, you can add:
> 
> <xs:any namespace="##other" processContents="lax" minOccurs="0" 
> maxOccurs="unbounded"/>
> 
> To define an attribute from another namespace, you can add:
> 
> <xs:anyAttribute namespace="##other"/>
> 
> The result is the same you are trying to achieve, but the one I am 
> proposing is commonly used in XML schemas, and I think we should be 
> using the same instead of your invented mechanism.
> 
> So can you use the standard extensibility mechanism?
Yes, I can and will do unless there are no objections from others.
> 
> - Section 7, XML schema, <conference-info>
> 
> The XML schema indicates that all the child elements of 
> <conference-info> are optional. This means that the following 
> document 
> is valid:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <conference-info xmlns="urn:ietf:params:xml:ns:conference-info" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
> xsi:schemaLocation="urn:ietf:params:xml:ns:conference-info" 
> entity="http://www.altova.com" state="full" version="0"/>
> 
> And this is a bit weird. I guess there should be something more in 
> conference info. As a minimum, the conference has been 
> instantiated, so 
> I guess the conference-description and conference state 
> should always be 
> present.
>
I am not sure about this one... I would prefer to leave the schema as
is.
I am OK with adding text saying SHOULD be present.

> - Section 7, XML schema, 'entity' attribute
> 
> I noticed that the 'entity' attribute is used by quite a few 
> elements. 
> In some cases, the 'entity' attribute can accommodate a URI whereas 
> others can accommodate a string. While this is legal, it is 
> really ugly. 
> If you browse through the schema, you can see the following 
> two definitions:
> 
>      <xs:attribute name="entity" type="xs:anyURI" use="required"/>
> 
>      <xs:attribute name="entity" type="xs:string" use="required"/>
> 
> I would recommend that you rename the 'entity' that can take a string 
> with something else.
> 
Agree. Will do.

> - Section 7, XML schema, <label> attribute
> 
> The definition of <label> in the schema is:
> 
>   <xs:element name="label" type="xs:string" minOccurs="0"/>
> 
> However, it is the intention to use this label as a key to 
> discover the 
> URI of further services, such as the CPCP URI, and perhaps something 
> else. However, the <label> element does not contain a list of 
> possible 
> services one can think of, so it is not possible that a SIP 
> UA uses that 
> information to, e.g., upload a CPCP document. The problem is that the 
> string is not standardized.
> 
> I don't know what people think about this, but I believe we either 
> standardize a few enumerated values, and provide 
> extensibility, or then 
> this <label> attribute looks quite useless.
>
I would really like to keep this "label". OK with standardizing it,
though.
 
> - Section 13. I think references 12 (RFC 2327) and 19 
> (draft-ietf-mmusic-sdp-media-label) can't be informative, since there 
> are strong dependencies on those. Further more, RFC 2327 is under 
> (eternal) revision, draft-ietf-mmusic-sdp-new-12312.txt or something 
> similar. Since there is a dependency on the inactive attribute 
> introduced by this new SDP version, we should refer to it, 
> but it would 
> be good to find out the status of SDP new and learn if it is going to 
> proceed to RFC before the end of the century.
> 
I actually think that the dependency can be stated as "informative". We
are just borrowing few strings for clarity.
> Nits:
I agree with all the nits below and will incorporate them. Thanks a lot!
> 
> - General: I would appreciate if we can refer to elements by 
> enclosing 
> the element in brackets rather than quotes. So far, all the document 
> refers to elements such as "conference-info" rather than 
> <conference-info>. We should refer to attributes by inserting them in 
> single quotes, e.g., the 'entity' attribute. Enumerated 
> values should be 
> quoted, e.g., the value can be "active" and "inactive".
> 
> 
> - Section 4, first paragraph. Include references to "XML 
> document" and 
> UTF-8.
> 
>     Conference information is an XML document [x]that MUST be 
> well-formed
>     and SHOULD be valid.  Dialog information documents MUST 
> be based on
>     XML 1.0 and MUST be encoded using UTF-8 [y]. This 
> specification makes
> 
>     [x]   Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
>           "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
>           REC-xml-20001006, October 2000.
> 
>     [y]   Yergeau, F., "UTF-8, a transformation format of ISO 
> 10646", STD
>           63, RFC 3629, November 2003.
> 
> - Section 4, 5th paragraph. For better readability, I would 
> suggest to 
> replace the current paragraph:
> 
>     For elements with the optional "state" attribute, if the 
> attribute is
>     omitted from the notification for the element, it means that the
>     reported element's state is "full".
> 
> with this other one:
> 
>     Elements can be characterized with an optional 'state' attribute 
> that indicates whether a "full", "partial" or "deleted" state is 
> indicated. The absence of a 'state' attribute has the same 
> semantics as 
> "full".
> 
> - Section 5 reads in bullet point 3.1.1: "If a key does not 
> exist in the 
> local table, a row is added, and its content is set to the element 
> information from the update."
> I think it is weird that an element can safely be deleted 
> just because 
> it does not provide any content. Imagine an element that can 
> either be 
> present or not, hypothetical example, <is-focus/>. I don't 
> think it is 
> safe to locally remove those elements.
> 
> - Section 6: remove the urn:ietf:params:xml:ns:conference-info
> URN from this section.
> 
> - Section 6.1.7.3. The last sentence is, for some reason, quoted. 
> Action: remove the quotes.
> 
> - Section 6.1.7.4., <label>. Replace the sentence:
> 
>     The
>     value of this element corresponds to the "label" media 
> attribute in
>     SDP [12] and defined in [19].
> 
> with
> 
>     The
>     value of this element corresponds to the "label" media 
> attribute in
>     [19].
> 
> - Section 7. Title. s/Schema/XML Schema
> 
> - Section 13, reference 1 is now RFC 3688
> 
> 
> 
> Best regards,
> 
>      Miguel
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 03 Nov 2004 11:57:22 +0200

Orit:

Thanks for your reply. I am now cutting the e-mail to only those points 
that require further discussion. See inline.

> multiple elements and types.

This is not the approach that other document in SIMPLE has taken. For 
instance, take the prescaps or any other SIMPLE document, and you will 
find out that the descriptive text follows the structure of a the XML 
document, not the XML schema document.

I would like that the conference event package follows the same pattern, 
and you describe the elements that you find in an conference info 
document, not in the XML schema that represents the structure of the 
conference info document.

To be precise. Section 6 reads:

    A conference information document begins with the root element tag
    "conference-info".

And that is correct. But then you describe, in Section 6.1.1, a supposed 
  conference type, which is not a visible element in a conference-info 
document.

> set by any out-of-band/configuration/management means.

The argument that they are optional is not that strong. We can put a lot 
of optional things, but at the end of the day, we need to figure out how 
is this going to be used. I don't find any usage for a display-text in 
an endpoint or a media type. I don't know how this can be set, and how 
my user agent can take the advantage of those fields.

Therefore, I still suggest to delete them, and if there is a future need 
for them, we can always extend the schema.

> I don't mind. BTW how is the same attribute being defined in other

Good point. At least the partial PIDF has defined the same attribute. So 
I will post an e-mail to SIMPLE and the PIDF authors suggesting them to 
follow the same approach as in here.

> I will be happy to clarify what "whisper" means and add the privacy

I still disagree. If you can proof me that there is such thing as a 
"public whisper" and "private whisper", then I would agree that the 
conference info includes the public whisper. However, I am not aware of 
any mechanism that allows me, as a participant of a conference, 
differentiate the private from the public whispering. If we have this 
element here the focus will be leaking privacy information of the 
participants, and I am not ready to accept this leakage.

My proposal is still to delete the element. If in the future we have a 
clear mechanism that allows the user to differentiate public from 
private whispering, then we can extend the conference info XML schema. 
But since there is not such mechanism today, I will propose to delete 
the <whispering-to> element.

> I am OK with adding text saying SHOULD be present.

What I am suggesting is that there should be a minimum of conference 
information present in the document. I guess this should be 
<conference-description> and the <conference-state>. The former exists 
from the creation of a conference. The second as well, although it could 
potentially be empty.

What I am trying to avoid is that a conference server sends me a 
conference event package that just contains <conference-info />. This is 
legal according to the schema, but shouldn't be. Think that it is hard 
to create good interoperability if everything in the document except the 
top level element is optional.

> I would really like to keep this "label". OK with standardizing it,

But you didn't answer my question. What is the semantics of the <label> 
element. Because in the mmusic label draft clearly indicates the 
semantics of the label attribute, as a mechanism to correlate static SDP 
documents with an actual SDP document. So in this sense, it is just a 
pointer with not further semantics.

By reading the conference event package, I got the impression that the 
idea is to overload the label attribute to indicate something else, for 
instance, that a URI is a CPCP or floor control URI.

If we check Section 6.1.7.4, it reads:

    The element "label" carries a unique identifier for this stream among
    all streams in the conference and is assigned by the focus.  The
    value of this element corresponds to the "label" media attribute in
    SDP [12] and defined in [19].

But the definition is not correct, because <label> is not only used in 
media streams, but also in URIs and user roles. I don't quite understand 
the relation between the "label" attribute in SDP and a URI or a user role.

> are just borrowing few strings for clarity.

I disagree. The criteria I am using is the following: if there are 
normative statemens depending on another document, the reference to that 
is normative, otherwise the reference is informative.

Checking the conference info package, I found the following:

Section 6.1.2.9

    The "entry" sub-element MUST be a value registered for
    "proto" of SDP [12].

Similar text appears in 6.1.7.1

Further more, extensive sections of the conference info draft require 
the focus to understand SDP, so obviously SDP is a normative reference.

Regards,

           Miguel