Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt

From: [email-masked]
Date: Tue, 19 Nov 2002 22:17:42 +0200

Hi

inline

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 18 November, 2002 19:37
> To: Jonathan Rosenberg
> Cc: Lonnfors Mikko (NRC/Helsinki); [email-masked]
> Subject: Re: [Simple] FW: I-D
> ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
> 
> Jonathan Rosenberg wrote:
> >
> >  >> 1. Assuming the watcher "picks" one of the contact 
> addresses, and
> >  >> decides to communicate with it by sending it an INVITE, 
> how should
> >  >> that INVITE look? If the URI in the contact element is 
> the AOR of
> >  >> the user, does the watcher need to add caller preferences
> >  >> (Require-Contact) in order to reach that specific UA instance?
> >  >
> >  > The publisher can identify separate tuples each with a 
> particular set
> >  > of capabilities, and yet provide a single AOR for all of them. In
> >  > that case it is in effect promising to provide a smart 
> proxy at the
> >  > AOR that can do the right thing.
> > 
> > Well, that won't work. How would the proxy know which tuple was
> > intended? The only way it can know is if the caller had 
> placed caller
> > preferences in the request. That was my point - how would the caller
> > know it needs to do that?
> > 
> > I suppose the right answer is to construct the tuple URI like this:
> > 
> > sip:aor@domain?Require-Contact=<escaped version of *;media="video">
> > 
> > that is, you don't rely on the subscriber to insert the 
> caller prefs.
> > The PA does that itself by embedding them in the URI.
> 
> I think this is a matter of semantics. If I, as publisher, 
> say there are two tuples with different attributes, but 
> associate them both with the same AOR, it might mean that I 
> have two devices registered at the same AOR with differing 
> attributes but don't choose to identify their addresses; or 
> it might mean that I have a single device with two different 
> and interesting sets of attributes I choose to advertise.
> 
> The subscriber doesn't know and shouldn't care, as long as it 
> reaches a device with the proper capabilities.
> 
> Having a proxy for the AOR simply fork the request may be 
> sufficient if there are two devices and the characteristics 
> that differentiate them can always be discerned from the 
> initial request. This isn't going to be the case very often, 
> but since the publisher is in the driver seat it should be 
> his problem to decide this.
> 
> Nevertheless, I agree that in general it would be best for 
> the presence publisher to do as you suggest and embed the 
> callerprefs headers in the contact address. Toward that end, 
> I think we had better specify somewhere that contact 
> addresses in presence may indeed contain embedded headers, 
> since they aren't universally accepted.

This may need bit more consideration. Embedding the caller preferences headers into contact address might make sense in a case where publisher has registered using caller preferences. I can also see use cases where presentity wants to embed feature tags into presence info but chooses not to register those to registrar (I want to show support for voice but I don't want my proxy to act differently). Other side of this problem is that this model seems to require callerprefs support from watcher side. How is the watcher expected to behave if it receives a contact URI with all different callerprefs headers it does not understand? This procedure seems also to duplicate the information in the presence document. It is first presented inside XML structures and then second time in contact URI. This may not be a huge problem but it isn't very nice either.

Well, in any case I think Jonathan is right that watcher should have a simple mechanism how to send request to presentity. One option could be that XML structure includes some kind of instructions to watcher how the Request based on presence info should be constructed. This would eliminate the duplication problem and if watcher does not understand callerprefs extension it can just ignore it and behave as callerprefs extension wasn't there in the first place.

> > I think the semantic needs to be simple. The caller invokes 
> the URI in
> > the presence document, period. The server guarnatees that 
> that results
> > in a request being routed to a UA described by the 
> information in the
> > presence document. Thats the contact.
> 
> Yes, this seems to be the best answer.
> 
> >  >> w3c has done a lot of work in describing capabilities 
> (CC/PP, RDF),
> >  >> all of which is XML-based. I wonder if there is a 
> better fit here
> >  >> to use that kind of syntax?
> >  >
> >  >
> >  > Could be.
> > 
> > That seems to be the common answer here... someone needs to do a
> > detailed study and see how it fits.
> 
> I already spoke with Mikko about this. Neither of us are 
> familiar with the W3C work. Will need to figure out who has 
> the time / contacts to do the digging.

If nobody else is going to volunteer for this I can spend some time to figure these things out.

- Mikko

> 	Paul
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Nov 2002 16:51:44 -0500

[email-masked] wrote:
> 
> This may need bit more consideration. Embedding the caller preferences headers into contact address might make sense in a case where publisher has registered using caller preferences. I can also see use cases where presentity wants to embed feature tags into presence info but chooses not to register those to registrar (I want to show support for voice but I don't want my proxy to act differently).

Certainly the publisher can do this if it wants to. May make sense in some cases.

> Other side of this problem is that this model seems to require callerprefs support from watcher side. How is the watcher expected to behave if it receives a contact URI with all different callerprefs headers it does not understand?

I don't see this as a problem. As long as watchers understand that the contacts may have embedded headers, and know generically what to do with them. (And 3261 says what to do with them.) The watcher doesn't have to understand or support the headers to insert them in a request.

> This procedure seems also to duplicate the information in the presence document. It is first presented inside XML structures and then second time in contact URI. This may not be a huge problem but it isn't very nice either.

Yes, it is less than desirable. But it seems to show up in many contexts, such as duplication of headers in sipfrags for security purposes. It may be the lesser of evils.

> Well, in any case I think Jonathan is right that watcher should have a simple mechanism how to send request to presentity. One option could be that XML structure includes some kind of instructions…

I don't understand this. What form would these "instructions" take? How would they affect the resulting request beyond using the contact address? I don't see what they could achieve that couldn't be achieved by attaching headers to the contact address.

> > >  >> to use that kind of syntax?
...
> > > detailed study and see how it fits.
...
> If nobody else is going to volunteer for this I can spend some time to figure these things out.

Thanks. I would like to look into this too, but I've got to figure out what is on my plate at home before I commit.

I want to suggest a requirement here: We must ensure that this remains semantically a superset of what is used to represent capabilities in registrations. (callerprefs) This could be an important constraint because many mechanisms are likely to have different namespaces and registration rules for capabilities/attributes.

	Paul