On Oct 12, 2007, at 2:06 AM, Salvatore Loreto wrote:
INFO, as written, lacks contextual negotiation. You're proposing to
replace the method name with NOTIFY and use the event-package
framework for content and context expression, using a header-field in
the INVITE request to engage context negotiation. It seems to me like
that would work. There's nothing "implicit" about it, and it is no
worse for overhead than using Supported or Allow. It also has the
advantage of letting us reuse an existing registration framework,
IANA process, and specification review process under RFC 3427. Very
tidy, I think I like it.
the proposal is interesting.
However there should be cases where you need to send whatever
information in both directions, or cases where when you send an
information via Notify you need to receive back some information (e.g.
the fact that you receive a 200Ok as answer to the Notify it is not
enough).
How do you think your proposal should work in those cases ? perhaps
with
2 subscription one in each direction?
Yes, although I prefer to think of it (in this example) as each end
having independently declared a willingness to receive events of the
given package within the current INVITE-bounded dialog.
It might also be reasonable to envision two different event packages,
designed to work together.
I would argue that it would be nice to have an extension mechanism
that allows a UA to be asked "Do you support this specific
extension?" without the UA having to encode every extension it
supports in every request it sends, but that's a different issue.
that is also something nice. Are you thinking a mechanism like an
OPTION
that instead to be general just asks for a specific extension?
Yes, I think that would do the trick.
Maybe it's just me, but I find the process of including fully-
populated Supported and Allow header fields in every request to be a
bit daunting. Not to mention repetitious, bandwidth and CPU
consumptive, and so on. Especially if we adopt the SIP-is-an-
application-protocol model that requires us to add a new method for
every payload type. Note that I have no idea how many UAs actually
comply with RFC 3261 on this particular point.
SUBSCRIBE gives us something that will do the job. Without preceding
contact, we can ask for a subscription to a package, and get an error
response if it isn't there.
This is a nice property: It keeps us from having to advertise every
event package to which we might possibly accept a subscription in
every message we send.
--
dean
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
