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

From: Miguel Garcia <[email-masked]>
Date: Mon, 01 Nov 2004 18:22:15 +0200

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.

- 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.

- 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 subelements), entity

My suggestion is to remove the "mandatory" or "optional" from the text, 
and make sure that things are right in the schema.

- 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.

- 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" />

- 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.

- 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>

- 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.

- 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.

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.

- 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.

- 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".

- 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. 
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.

- 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.

- 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.

- 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.

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.

- 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?

- 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.

- 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.

- 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.

- 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.

Nits:

- 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