Subject: [Sipping] conference-package-08 comments

From: Cullen Jennings <[email-masked]>
Date: Sat, 29 Jan 2005 08:04:30 -0800

I gave this a very quick read and I like it. I should read it carefully at
some point. Few concerns...

If bob is disconnecting on one instance but had dialed back in and
connecting, how can you use the
entity as the the index of the endpoint and have it be unique?

How can a device that had multiple audio of video streams use the proto as a
key and have it be unique?

When we get the above items sorted out, this looks like it is ready for last
call to me. 

The dialog identifiers are often the only thing that stops people from being
able to spoof midcall messages (like BYE) into SIP sessions. I think we need
some security considerations around when the conference package should
reveal this and when it should not. Actually, I'm sort of wondering if it
ever should. 

The way this is defined the conference certainly could protect users privacy
but there is not much in the draft that helps implementers know how they
might go about this.

After a user is disconnected, how long do they stay listed as entry that is
disconnected before they are just deleted.

More NIT like things ....

Why is the call into the media instead of inside the endpoint

I was surprised that the XML was only a SHOULD be valid instead of MUST but
don't care if you leave it this way

I was surprised that S/MIME was SHOULD - I guess I would have put SIPS

There are weird control characters in the draft. Some lines look too long

Defining active as after start-time just adds to the confusion of what
start-time is and makes active weird too. I think this is the the wrong
definition. I would use active to mean that if you use signaling to connect
to the provided URLs to join the conference, it might work.

The "when" field should require that the time in in  UTC

conference-medias-type should be restrict to the the MIME media types

sharepoint?

max-user-count: What do you put if the number of users is unlimited

I think all the things that are used as indexes should be attributes

The XML indentation is messed up

I did not really look at the schema but I assume the XML is appropriately
extensible...

_______________________________________________
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: "Orit Levin" <[email-masked]>
Date: Mon, 31 Jan 2005 16:12:40 -0800

Inline,

Orit.

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Saturday, January 29, 2005 8:05 AM
> To: sipping; Orit Levin
> Cc: Rohan Mahy; Dean Willis
> Subject: conference-package-08 comments
> 
> 
> I gave this a very quick read and I like it. I should read it 
> carefully at some point. Few concerns...
According to my records, the last call for this draft ended more than a
month ago... :-)
> 
> If bob is disconnecting on one instance but had dialed back 
> in and connecting, how can you use the entity as the the 
> index of the endpoint and have it be unique?
>
The design was that the schema will represent the "aggregated" abstract
call signaling status information per endpoint collectively for all
potentially existing dialogs. In other words, it will show to most
recent and the most important information. In this case it could be the
"connecting" status, for example. If the detailed call status is
absolutely needed (and permitted to be divulged to the conference state
subscriber) then the client can learn the dialog id (from the package)
and SUBSCRIBE to the dialog package in parallel to the conference
package and ahead of time.

Theoretically and generally to the package design, in the future IFF
absolutely necessary, any "entity URI" used as a key can contain a URI
parameter distinguishing between the keys.

> How can a device that had multiple audio of video streams use 
> the proto as a key and have it be unique?
>
"proto" is not the key for a media stream. The key is an "id" attribute
which MUST be unique among endpoint's streams and generated by the
conference state generator. It SHOULD have the same value as the "mid"
from the "Grouping media lines in SDP" RFC.

> When we get the above items sorted out, this looks like it is 
> ready for last call to me. 
>
I will address the formatting and the editorial comments in the 48
editor's hours. 
> 
> The dialog identifiers are often the only thing that stops 
> people from being able to spoof midcall messages (like BYE) 
> into SIP sessions. I think we need some security 
> considerations around when the conference package should 
> reveal this and when it should not. Actually, I'm sort of 
> wondering if it ever should. 
> 
> The way this is defined the conference certainly could 
> protect users privacy but there is not much in the draft that 
> helps implementers know how they might go about this.
> 
> After a user is disconnected, how long do they stay listed as 
> entry that is disconnected before they are just deleted.
> 
> 
> I was surprised that the XML was only a SHOULD be valid 
> instead of MUST but don't care if you leave it this way
> 
> Defining active as after start-time just adds to the 
> confusion of what start-time is and makes active weird too. I 
> think this is the the wrong definition. I would use active to 
> mean that if you use signaling to connect to the provided 
> URLs to join the conference, it might work.
> 
> I did not really look at the schema but I assume the XML is 
> appropriately extensible...
> 
>