Subject: [Sip] Draft-ietf-sip-info-events-00: Other messages for Send-Info and Recv-Info

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 27 Oct 2008 13:14:10 +0100

I notice that the current document does define the validity of these
elements for REG, but leaves the section describing the use empty. If
the purpose of inclusion was to somehow register this things in the
registrar against the contact, surely this should be left to feature
tags, as I think has already been suggested on the list. Or was there
some other purpose? If not, I would suggest removal.

The other method that crossed my mind was OPTIONS. Should OPTIONS
provide a mechanism of identifying what the entity at the Request-URI
supports, in the same manner as it does for SDP and option tags, or
should be ignore this possibility on the grounds of simplicity.
Thoughts?

Regards

Keith
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 27 Oct 2008 22:00:30 +0100

Hi Keith, 

elements for REG, but leaves the section describing the use empty. If
the purpose of inclusion was to somehow register this things in 
>the registrar against the contact, surely this should be left to
feature tags, as I think has already been suggested on the list. Or was
there some other purpose? If not, I would suggest removal.

As indicated earlier, being able to register the supported packages, and
use them for forking, would be very useful, and I think that is the
intention of the text.

Yes, maybe we need to define a feature tag, or feature tags. The
question is whether we would need a single feature tag which can list
all supported info packages, or a feature tag for each package (in which
case each info package definition would have to specify a feature tag
value). The advantage of having separate feature tags is that it gives
you much more flexibility.

>should be ignore this possibility on the grounds of simplicity.

I see no reasons why the Info headers couldn't be included in OPTIONS,
so I think that should be fixed.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Oct 2008 17:26:59 -0400

> you much more flexibility.

The decision about that depends on what kinds of selection you want to 
be able to make using callerprefs. (If anybody uses callerprefs to make 
selections.)

If you make it a single feature with a list of values then it becomes 
impossible to select a particular Contact based on which packages it 
supports.

	Paul