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

From: [email-masked]
Date: Wed, 20 Nov 2002 01:45:38 +0200

Hi,

Inline

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

ok, then it should be explained somewhere that contact element URIs can contain embedded headers and how those should be processed. I am not sure is this draft the place to do it but on the other hand I cannot figure out any better place either. 
 
> > 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.

As I said this may not be such a big problem but my view still is that if this can be avoided it should be avoided.

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

I probably wasn't clear enough. I was thinking to desing something like this:
<presence>
  ..
  ..
	<prescaps>
	  <feature name="media" required="true">
		audio
	  </feature>
	<prescaps>
	<contact>sip:[email-masked]</contact>
</presence>

The <feature> element could have an attribute called 'required' or something similar. When watcher would get this info it would take the contact as Request-URI and then generate Require-Contact based on 'required' attributes. This would solve the duplication problem and also embedded header problem (if it was a problem in the first place). This would put little more responsibility on watcher side as watcher would construct Require-Contact headers based on info found in XML. This was just to show that there might be some alternatives to do this. Hopefully it is now bit clearer.

> > > >  >> 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?
> ...
> > > > That seems to be the common answer here... someone needs to do a
> > > > 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.

This sounds like a good idea. Could you still elaborate the last sentence a bit. I am not sure I completely got it.

- Mikko

> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Nov 2002 19:21:32 -0500

> This sounds like a good idea. Could you still elaborate the last sentence a bit. I am not sure I completely got it.

In draft-kyzivat-simple-prescaps-reqts-00 I reference the need to represent any feature tag. The feature tags used in callerprefs are defined by reference in rfc 2506.

It defines the syntax of feature tags, a partitioning into different namespaces, and different registration procedures for the namespaces. 

Callerprefs also uses rfc 2533 to define the semantics of feature sets. But it doesn't support the full range of semantics defined by 2533 - it uses only a subset that can be mapped onto the parameter syntax in a simple way.

So, if some existing specification is used to represent combinations of features/capabilities in PIDF, then it needs to have the capability to use any of the feature tags legal according to 2506, and any of the feature sets that can also be represented by callerprefs. The obvious selection is rfc 2533 itself, mapped into xml. 

This of course assumes that callerprefs doesn't change again. But I think it is important to track callerprefs.

	Paul