Subject: [Sipping] "Small issues" [was: Comments on draft-ietf-sipping-conference-package-10.txt]

From: "Orit Levin" <[email-masked]>
Date: Mon, 18 Apr 2005 15:43:06 -0700

The answers are inline.

Thanks,
Orit.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: Wednesday, April 13, 2005 7:03 PM
> To: Orit Levin; [email-masked]
> Subject: [Sipping] Comments on 
> draft-ietf-sipping-conference-package-10.txt
> 
> I have reviewed this draft and have the following comments:
> 
> First a large issue, and then a bunch of small ones.  The big 
> one is: I wonder if it is appropriate for a specific package, 
> like this one, to define a partial notification scheme.  Is 
> that not a generalized problem?  Do we want every package to 
> define its own?  Is this particular model peculiar to 
> conference information?
> This something all of sipping, not just those interested in 
> conferencing should consider.
> 
> 1. Section 3.2, filters
>    A SUBSCRIBE for a conference package MAY contain a body.  This body
>    defines a filter to apply to the subscription.  Filter 
> documents are
>    not specified in this document, and at the time of writing, are
>    expected to be the subject of future standardization activity.
> 
> I think this is inappropriate language.  You are using 
> normative statements to apply to an as-yet-unspecified 
> feature.  I would suggest that "Filters to subscriptions are 
> a desirable feature which may be considered in a future 
> revision" somewhere later in the document
> 

Agree. Will do the suggested editorial change.

> The following paragraph introduction would have to be 
> reworded if this change was made
> 
> 2. Section 3.4, ACCEPT header
> The text:
>    As described in RFC 3265 [9], the NOTIFY message will 
> contain bodies
>    that describe the state of the subscribed resource.  This 
> body is in
>    a format listed in the Accept header field of the SUBSCRIBE, or a
>    package-specific default if the Accept header field was 
> omitted from
>    the SUBSCRIBE.
> 
>    The subscribe request MAY contain an Accept header field.  
> If no such
>    header field is present, it has a default value of
>    "application/conference-info+xml".
> 
> is confusing.  If you have no header, there is no default 
> value for the header.  I think what you mean is, if there is 
> no ACCEPT header, the subscription assumes 
> "application/conference-info+xml" as the default NOTIFY body. 
>  Perhaps:
> 
>    As described in RFC 3265 [9], the NOTIFY message will 
> contain bodies
>    that describe the state of the subscribed resource.  The subscribe
>    request to this package MYA contain an Accept header field with the
>    value "application/conference-info+xml".  If no Accept header is
>    specified, the NOTIFY will contain a body of 
> "application/conference
>    -info+xml".
> 

Agree. Will do the suggested editorial change.

> The text:
>    Of course, the notifications generated by the server MUST be in one
>    of the formats specified in the Accept header field in the 
> SUBSCRIBE
>    request.
> 
> is gratuitous and could be deleted.  I would like it to be 
> deleted, because the package only defines one format.

Agree. Will do the editorial change.

> 
> 3. Section 3.5, one recommendation
> The text says "However, a few recommendations can be made" 
> and then only offers one recommendation.  I'd recommend just 
> deleting the sentence.

Agree. Will do the editorial change.

> 
> 4. Section 3.10 State Agents
> Could we have a reference to 3265 for a state agent?  Also, I 
> think the wording here is less than crystal clear.  It's the 
> focus that is always the NOTIFIER, not any "conference 
> element".  I do wonder if a cascaded focus is an instance of 
> a state agent.  I think it is.

Agree completely.
I will rephrase the statement saying that state agents MAY be used such
as in the case of cascaded foci.

> 
> 5. Section 4.2 namespace
> Is it not a bit presumptuous on our part to claim the 
> "conference-info" part of the IETF namespace for sip 
> conferencing package?  Would it not be more appropriate to 
> use "sip-conference-info" or even "sip-conference-package".

Disagree.
The notification mechanism is clearly SIP-specific, but the XML schema
definition is not. I would prefer keeping it as is, unless a clear
majority of the folks on the list think differently.

> 
> 6. Section 4.4 State
> Is the word "adhere" the right one in "A 'state' attribute of 
> a child element in the document MUST adhere to its parent 
> 'state'"?  How about "conform" or maybe better "be consistent with".
 
Agree. Will do the editorial change.

> 
> For completeness, you might add something about state 
> 'deleted' of the parent. Is it actually the case that if the 
> state of the parent is 'deleted', you can't specify any child 
> elements?

Yes, that is correct.
Will add this clarification.

> 
> 7. Section 4.5/4.6 Table abstraction
> If you are going to use a table as an abstraction for 
> multiple elements in a container, then you need to introduce 
> the table abstraction in 4.5.  I don't care if you use the 
> table abstraction or not, but in either case, the wording 
> should be consistent.

I don't see the need for introducing the "table abstraction" to 4.5
because the abstraction exists only to describe the algorithm in 4.6. To
improve the document flow, I will replace the first paragraph in 4.6
with:

"This section describes the algorithm for constructing a coherent
conference state by a subscriber to the conference package. Using
software programming abstraction, the subscriber maintains a single
local version number for the whole conference document and a local
element instance for element in the schema. Also, for each element with
keys (as defined above), the subscriber maintains a virtual table with a
row for each existing key value."

> 
> 8. Section 4.6, "deleted" state in subelement The algorithm 
> does not handle the case of a row deletion.  Complete element 
> deletion is handled in step 2, but step 3 only covers the 
> cases of add or modify.

You are right. I will add this case to 3.2 .

> 
> 9. Section 5.1 "entity" definition
> The entity attribute of <conference-info> refers to a conference uri.
> Within <conference-info> we have <conf-uris> elements that 
> list, tada, conference uris.  So, what is the relationship 
> between the entity and the conf-uri?  Need some text.  I 
> suppose that the entity may be repeated as a conf-uri.  If it 
> is not, can you still send an INVITE to the entity attribute 
> value?  Presumably, the entity attribute is the URI that the 
> subscription was sent to.  You have to at least state that.

As per the conference package itself, I will clarify that the <entity>
value is the URI to SUBSCRIBE to. Also, that it can be repeated in the
<conf-uris>.

As per general architecture for SIP conferencing, the sipping framework
defines the conference URI properties. I don't think that the conference
package needs to repeat or define more.

> 
> 10. Section 5.2, Subject and display text I'm concerned about 
> the plethora of things that are free text used to describe 
> the conference.  We have the Subject in the Invite message, 
> the Subject in <conference-description> and <display-text>.  
> We need guidance on how you use these values, and which 
> should be the same.  I cab just see a client deciding to use 
> the Subject in the INVITE and a focus deciding that since 
> there is a Subject in the package, it doesn't need to use the 
> subject in the INVITE.

These fields, by definition, are for user display - not for automata.
Therefore, I don't see the need for standardizing this behavior. A
reasonable focus implementation needs to provide available for display
information in INVITE (especially for the benefit of potentially
conference-unaware clients).

If needed, this clarification needs to be added to the conference
framework rather than the conference package.

> 
> 11. Section 5.2.1 "Purpose"
> I think purpose is misguided.  If you have an RTSP uri, you 
> know what it's for.  I really don't see anyone making use of 
> an H.323 or SIP uri for a streaming service that would in any 
> way be different from the "normal" case.
> If you want streaming, send SDP with 
> "receive-only"/"send-only".  Can we get rid of this "feature"?

A long discussion on this topic took place on this list a couple of
months ago during the original WGLC. People argued different opinions
based on different requirements. The resultant XML reflects the agreed
compromise. I really hope that we don't reopen this discussion just
because you don't see the need for this "feature": others felt that it
is important to make this definition open and specific.

> 
> 12. Section 5.2.2 "web page"
> There are two kinds of web pages.  One is a page that has 
> lots of pre-arrival conference info.  The other is a web page 
> used with the conference in session.  Should we not differentiate?

I don't see the need for two different kinds. A web page can be pretty
self-guiding by itself. That being said, if additional parties see the
need - please, speak up.

> 
> 13. Section 5.2.3 "maximum-user-count"
> <rant>We have never defined what this means.  We have never 
> come up with a reason to have it.  We are blindly copying a 
> mechanism that TDM systems use without any reflection on 
> whether that works in this domain.  For example, does the 
> number of clients of the streaming service count?</rant>

We resolved this issue in a separate thread. The XML definition will not
change. I will do a better job describing what it means:

The value of this element provides a hint to the recipient of the
conference document about the number of users that can be invited to the
conference. Typically this value represents the overall number of users
allowed to join the conference by different means as published through
the conference document in <conf-uris>. Note that this value is set by
the conferencing system reflecting any combination of existing local
policies such as network consumption, CPU processing power, and
licensing rules.

> 
> 14. Section 5.2.4 "status"
> This is confusing because often this value is user specific.  
> At least need some text that says this attribute is only used 
> when all instances of the stream have the same status value.

Agree that the current text is vague.
The meaning, in my mind, is that this is the maximally available to the
participants status of the stream. A participant can obviously INVITE
himself/herself to less (i.e. one direction only) - if both directions
are available. (In other words, it is not necessarily a physical "state"
of some particular stream being generated by the system.)

> 
> 15. Section 5.4.1 "user-count"
> At least needs a discussion of what this includes.  Does the 
> recorder count?
> Any other robo-participants?  Streaming participants?  
> Anonymous participants? WRT the latter, there is information 
> leak on how many anonymous participants, but OTOH others want 
> to know they are there.  Need some words on the subject.

We resolved this issue in a separate thread.
The XML definition will remain unchanged. I will do a better job
describing what it means:

The value of this element tells the recipient of the conference document
the overall number of users participating in the conference at a certain
moment. Typically this value represents the overall number of users who
joined the conference by different means as published through the
conference document in <conf-uris>. Note that this number does not
necessarily need to match to the number of the entries in the <users>
container because it is a subject to local conferencing policies what
participant subset to include in the <users> container. 

> 
> 16. Section 5.4.2 "active"
> I question the definition.  Most current bridges would let 
> you dial in, but would eventually send you away.  Is that active?

We discussed this definition several times on the list and just recently
agreed on the latest wording ...

Will it work for all saying that a conference is <active> if "dialing to
one of the conference URIs by an eligible participant results in a call
signalling session being established with the focus and subsequent
successful joining the conference" ?.
 
> 
> 17. Section 5.5. "entity" of "user"
> We MUST specify exactly how anonymous users are presented, so 
> that clients can reasonably create user interfaces.  A user 
> must be marked, in some unambiguous way, that s/he is anonymous.
>

The guidelines for anonymous user representation are well defined in RFC
3323. Automata can determine whether the user is anonymous by processing
user's 'entity' value. I will strengthen the language and say SHOULD
instead of "could".

I suspect that in general conferencing (and in other applications) there
can be different flavors of "anonymous" and also among "non-anonymous" -
different levels of user identifier exposure and trust. I really think
that at this point of time and place (for all well-known reasons) we are
not ready yet to introduce a new schema element capturing these TBD
concepts. Nothing prevents us from doing it later.

> 18. Section 5.5.1 "display text"
> We need to discuss how the display name in the uri and the 
> display text in the element relate to one another.  We need 
> to say explicitly what the difference is.  If both are 
> present, and they are different, what is a poor user 
> interface to do?  I would think we eliminate this and just 
> use display name, as well as importing whatever solution we 
> arrive at for nickname in text chat.  I also think we should 
> discuss what I think is a common case, where you get the real 
> participant name, but an anonymous URI.
> 
> 19. Section 5.5.2 "associated aors"
> I find this text confusing.  I'm not sure what this means.  
> An example, at least, would be helpful.  Is this supposed to 
> be a real AoR when entity is a GRUU or something?
>

Yes, this is the best example.

I don't have strong opinion about this element. If additional parties
would like to remove it from the schema or keep it in the schema -
please, speak up. Otherwise, I will add this clarification and an
example.

> 20. Section 5.5.3 roles
> I am very happy to see roles here, but I think we need some 
> kind of explanation or reference to other work.
> 

How about:
This element contains a set of human readable strings representing the
roles of the user in the conference. This document doesn't define a set
of possible conferencing roles neither does it define the associated
semantics. It is expected that additional conferencing specifications
will define these and specify how they are mapped to the conference
document.

> 21. Section 5.6.2 "reason"
> Needs a reference to some way of specifying this (Reason header?)

Tend to agree. Will add this and update the examples correspondingly.
Same will apply to 5.6.5 and 5.6.7.

Note that if we do this we may need to use "token" values beyond the
protocols specified in RFC 3326.

> 
> 22. Section 5.7 "id" and "label"
> I thought we agreed that label was all you needed; it's the 
> id.  Why do we need another index?
> If you don't have SDP labels, make something up, but if you 
> do have them, use them for id.

Disagree. We never convinced each other.

For example, a client over a single SIP dialog can include multiple SDP
m-lines and essentially invite itself to the same "available in the
conference media stream" multiple times. By definition, all the m-lines
in both SDP and the conference package will carry the same "label".

A simple client "stress test" application would be just an example for
such functionality, but it clearly demonstrates why using the "label"
value as the key for the "user view" of the media streams in the package
is wrong architecturally.

> 
> 23. Section 5.7.4 "CSRC"
> I have some confusion, and maybe I'm just lost in the weeds 
> and there is nothing wrong.
> The typical case is that each participant sends a stream into 
> the mixer that has one CSRC.
> The mixer sends a stream that has multiple SSRCs.  The 
> relationship between the input CSRC and the output SSRCs is 
> known by the mixer, but since each participant chooses his 
> own CSRC, the mixer can't, in general, use those for the 
> SSRCs.  So, what are we doing here?  For each participant, 
> will we show both streams (in and out)?  For the in stream 
> (WRT the mixer) we show the CSRC chosen by the participant.  
> Are you saying that we show the SSRC chosen by the mixer on 
> the output stream for every user?
> 
> If I have that right, the text does not sufficiently explain it.

I believe that the posting from Dave Oran resolved this issue.
As a result, no changes to the package.

> 
> 24. I suspect we need more text in security considerations.  
> Consider, for example, the reveal of the Referral URI.  I 
> think we want to discuss what reasonable defaults might be, 
> where policy is not specified.  I would think those would be 
> quite restrictive.

Agree. I will enhance the security considerations section.
Specific text suggestions from interested parties will be very helpful.

> 
> I did not wade into the schema, examples or IANA 
> considerations sections.
>

I would like to ask all new parties planning to review these sections to
do it ASAP without waiting till the last moment.
 
> Brian
> 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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