Subject: [Simple] Question on draft-ietf-simple-presence-10

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 30 Dec 2003 11:19:56 -0000

Currently reference [9] of this specification is to:

   [9] H. Schulzrinne and J. Rosenberg, "Session initiation protocol
   (SIP) caller preferences and callee capabilities," internet draft,
   Internet Engineering Task Force, Nov. 2002.  Work in progress.

which by matching the title would equate to:

	draft-ietf-sip-callerprefs-10

As the usage of this reference in the text is UA to UA, rather than UA to proxy, am I right in thinking that the reference is really to the other half of the caller preferences work, which was split off into:

	draft-ietf-sip-callee-caps-01

Additionally, if the reference is to callee-caps, then clause 7 of this document contains the text:

   There is overlap in the callee capabilities mechanism with the Allow,
   Accept, Accept-Language, and Allow-Events [9] header fields, which
   can also be used in target refresh requests. Specifically, the Allow
   header field and "sip.methods" feature tag indicate the same
   information. The Accept header field and the "type" feature tag
   indicate the same information. The Accept-Language header field and
   the "language" feature tag indicate the same information. The
   Allow-Events header field and the "sip.events" feature tag indicate
   the same information. It is possible that other header fields and
   feature tags defined in the future may also overlap. When there
   exists a feature tag that describes a capability that can also be
   represented with a SIP header field, a UA MUST use the header field
   to describe the capability. A UA receiving a message that contains
   both the header field and the feature tag MUST use the header field,
   and not the feature tag.

I am not convinced this is consistent with clause 6.11.2 of the presence-10 specification which states:

   A PA MAY choose to migrate subscriptions at any time, through
   configuration, or through dynamic means. The REGISTER request
   provides one dynamic means for a presence server to discover that the
   function can migrate to a PUA. Specifically, if a PUA wishes to
   indicate support for the PA function, it SHOULD use the caller
   preferences specification [9] to indicate that it supports the
   SUBSCRIBE request method and the presence event package. The
   combination of these two define a PA.

as in some cases it is provisions of RFC 3261 and RFC 3265 through the use of the Allow and Allow events header that will define a PA. Maybe the text should be revised to reflect the precedence of those headers.

regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple