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

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Apr 2005 22:02:49 -0400

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

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

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.

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.

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.

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

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

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?

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.

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.

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.

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.

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

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?

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>

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.

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.

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?

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.

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?

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.

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

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.

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.

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.

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

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 14 Apr 2005 01:31:52 -0500

> This something all of sipping, not just those interested in 

Doesn't this use the same mechanism as the dialog package, modulo a 
"delete" operation?

But, that question raised, I am getting a lot of questions from OMA 
relating to the differences in the partial notification models for 
presence and xcap. It looks like  we can send a whole PIDF in presence 
NOTIFYs, and only a diff (or an indirect to a document that must be 
fetched via xcap) for xcap. There would be a benefit to a more 
consistent model here.

--
dean

---

From: David R Oran <[email-masked]>
Date: Thu, 14 Apr 2005 10:44:31 -0400

> by the mixer on the output stream for every user?
I think you've got this wrong. The output of the mixer is a stream with 
its own (single) SSRC and CSRCs for each of the original media sources 
in the input streams that are in the mix at this moment.  There are two 
kinds of input streams, ones from an original media source, and ones 
from an upstream mixer. The ones from an original media source will 
each have its unique SSRC but these RTP packets will *not* have a CSRC 
field in them. packets from an upstream mixer will have the SSRC of the 
mixer, and the CSRCs of the streams that were input to that mixer.

Therefore, the correct output of a mixer will have the SSRCs for all 
the original sources who contributed to the mix in the CSRC field of 
the output (mixed)  RTP stream. I would argue that the SSRC of any 
upstream mixer should not be included in the CSRCs of the downstream 
mixer.

This makes the job of the ultimate receiver easy since the CSRCs in the 
receiver RTP stream identify exactly the set of original inputs to the 
mix, no matter if the mix was constructed in one stage or multiple 
stages.