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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sun, 4 Jan 2004 00:57:35 -0000

I would maybe suggest a small amount of additional informative text to presence-10 in auth48 just to add clarity. I accept there is no problem with the normative material, but as you say, it is subtle.

regards

Keith

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 31 December 2003 18:48
> To: Drage, Keith (Keith)
> Cc: [email-masked]'
> Subject: Re: Question on draft-ietf-simple-presence-10
> 
> 
<snipped>
> > 
> > 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.
> 
> Actually, I dont think there is a conflict, but the reason is subtle. 
> If you look at the first sentence in the text from callee caps above, 
> you will note that it is explicitly talking about *target refresh 
> requests*. The presence spec is talking about registrations. The 
> difference is that registrations can contain information about 
> multiple UAs, and therefore the capability information needs to be 
> contact-specific; thus, it is appropriate to use the callee caps 
> parameters.
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

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