Subject: [Sipping] conference event package draft

From: "Sean Olson" <[email-masked]>
Date: Thu, 27 Jun 2002 18:41:02 -0700

A few quick comments on the draft.

- There are several features mixed in the event package that might
  need to be separated out. For example, I can imagine someone wanting
  to support the "conference" package but not the recurse parameter. 
  Another example is reporting "media-status"; some implementations may
not
  want to deal with this and there are many uses of the conference
package
  that don't require this information at all. For that matter, even the
dialog
  state is not really necessary if you have the
"active/departed/booted/failed" status
  for the user. (of course, there are also applications that can use
this info)

  Is there a way to make this functionality optional and perhaps specify
it through 
  some type of option tag or other mechanism? You could, of course, just
return a 
  document in the NOTIFY with this information omitted, but it would be
nice to
  know what the subscriber really cares about and what the event agent
is prepared to send.

- Should we add "text" to the mimetypes type in the schema?

- I'm assuming that if an endpoint leaves or is booted from a conference
(and it
  is subscribed to the conference event for this conference), that it
will receive a NOTIFY
  with a "Subscription-state: terminated" (I didn't see anything like
this in section 3.4)

- You might add "anyAttribute" to the c-info-type, media-stream-type,
and user-type 
  types in the schema

- I like the versioning mechanism that you've come up with. Is there a
way to 
  normalize this across event packages? It would be nice to have a
standard way to
  do this even for things like presence. (Not your problem, I know, but
can we push
  this into a sip-event extension?)

Sean Olson
Program Manager
Real Time Communications

_______________________________________________
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