Subject: RE: [Sip] Re: Question about caller preferences

From: [email-masked]
Date: Wed, 9 Oct 2002 15:27:17 +0300

Its for receiving. When a UA registers with contact that has methods-param, its indicating the methods it understands and capable of handling when receiving.

Regards,
Hisham

> -----Original Message-----
> From: ext Beckmann Mark ICM MP P PS 4 SAL 2
> [mailto:[email-masked]]
> Sent: Wednesday, October 09, 2002 3:00 PM
> To: [email-masked]
> Cc: 'Jonathan Rosenberg'; Miguel A. Garcia; Keith Drage; 
> Mayer Georg ICM
> N PG SP ST N 1
> Subject: RE: [Sip] Re: Question about caller preferences
> 
> 
> Hi,
> 
> I have another question about the caller preferences, 
> especially regarding
> the method tag of the contact parameter.
> 
> Perhaps, this was discussed before on the list. In the draft, 
> however, I
> couldn't find any hint whether it is possible to indicate the 
> "direction",
> in which a UA supports a specific method.
> 
> For example a UA that indicates support for the methods 
> SUBSCRIBE and NOTIFY
> would add a contact parameter as follows:
> 
> Contact: <sip:ua.example.com>;methods="SUBSCRIBE,NOTIFY"
> 
> Now, does this mean the UA has to accept and be able to send 
> both methods? I
> would guess that for some UAs it would make sense to support 
> the ability to
> subscribe to an event and receive NOTIFYs, but not to accept 
> SUBSCRIBEs and
> send NOTIFYs itself.
> 
> Regards,
> 
> Mark
> 
> Mark Beckmann			Siemens AG
> 
> ICM MP P PS 4S2
> P.O.Box 100702			phone: +49 (5341) 906 1814
> D-38228 Salzgitter   		fax:   +49 (5341) 906 2010
> 
> mailto: [email-masked]
> 
> 
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Thursday, September 26, 2002 7:21 PM
> > To: Miguel A. Garcia
> > Cc: [email-masked]; Keith Drage
> > Subject: [Sip] Re: Question about caller preferences
> > 
> > 
> > inline.
> > 
> > Miguel A. Garcia wrote:
> >  > Hi:
> >  >
> >  > I had a discussion with some folks about the caller preferences
> >  > draft, and we have some questions that we weren't able 
> to answer by
> >  > reading the document.
> >  >
> >  > We understand that by not publishing the support for a 
> feature set,
> >  > the UA is not providing any information. Therefore, the 
> feature set
> >  > may or may not be supported at the UA.
> > 
> > Actually, RFC 2533 (which we are using) does say something concrete 
> > about what it means to say nothing about a feature tag. It 
> means that 
> > you are supporting all values. This means you need to be 
> > careful about 
> > the semantics of the headers - the existing Reject-Contact 
> > semantic of 
> > "reject this contact if its feature set matches" is bad, 
> > because it will 
> > cause a UA to be rejected even if it has said nothing about a 
> > particular 
> > feature tag!
> > 
> >  >
> >  > But the question is, if the UA decides to provide 
> > information about a
> >  > supported feature set, shall that information be complete?
> > 
> > Yes.
> > 
> >  >
> >  > We are thinking of the methods parameter in the Contact 
> header for
> >  > registration. In case the methods parameter is included, 
> > shall it be
> >  > complete and list all the methods supported by the UA?
> > 
> > Yes.
> > 
> > There was a thread on the list (likely followed by no one) between 
> > myself, Juha, and Paul K. on this exact issue. Our conclusion 
> > was that 
> > it was reasonable to mandate that a UA include all values 
> it supports 
> > for a feature tag, when it includes that feature tag.
> > 
> >  >
> >  > Example:
> >  >
> >  > Contact:
> >  > 
> > 
> <sip:ua.example.com>;methods="INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER,-
> >  > UPDATE,SUBSCRIBE,NOTIFY,PRACK,MESSAGE"
> >  >
> >  > Some folks think that the complete list is not essential. In my
> >  > opinion, if a feature is present, it should be complete. In this
> >  > case, all the methods supported by the UA must be present.
> > 
> > That is correct.
> > 
> >  >
> >  > Other folks didn't see the need to publish the support 
> for methods
> >  > like ACK (implicitly supported if INVITE is supported), or NOTIFY
> >  > (implicitly supported if SUBSCRIBE is supported).
> >  >
> >  > In my opinion, that assumption is always wrong, because 
> the methods
> >  > parameter indicates support for SIP methods, not for SIP
> >  > capabilities.
> > 
> > I would agree. Without listing all methods, you put the 
> burden on the 
> > server to lean what other methods a UA will support based on 
> > the ones it 
> > listed. That won't always be a trivial exercise.
> > 
> >  >
> >  > I would like to hear the opinion of the WG to give us some 
> > guidance.
> >  >
> >  > Last, but not least, whatever is the correct thing to do, can you
> >  > please add a very clear sentence to the caller preferences 
> > draft, so
> >  > that there is no doubt as with respect the interpretation?
> > 
> > Yes. I have already done that in my working draft as a 
> result of the 
> > aforementioned thread with Paul K. and Juha.
> > 
> > -Jonathan R.
> > 
> > 
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.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
> > 
> _______________________________________________
> Sip mailing list  https://www1.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
> 
_______________________________________________
Sip mailing list  https://www1.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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Oct 2002 12:06:48 -0400

Yes, that is true. Its based on the fact that the spec says that the 
methods param and the Allow header convey the same information. Allow 
indicates methods you can receive.

I should probably explicitly say it, though.

-Jonathan R.

[email-masked] wrote:
 > Its for receiving. When a UA registers with contact that has
 > methods-param, its indicating the methods it understands and capable
 > of handling when receiving.
 >
 > Regards, Hisham
 >
 >
 >> -----Original Message----- From: ext Beckmann Mark ICM MP P PS 4
 >> SAL 2 [mailto:[email-masked]] Sent: Wednesday, October
 >> 09, 2002 3:00 PM To: [email-masked] Cc: 'Jonathan Rosenberg'; Miguel
 >> A. Garcia; Keith Drage; Mayer Georg ICM N PG SP ST N 1 Subject: RE:
 >> [Sip] Re: Question about caller preferences
 >>
 >>
 >> Hi,
 >>
 >> I have another question about the caller preferences, especially
 >> regarding the method tag of the contact parameter.
 >>
 >> however, I couldn't find any hint whether it is possible to
 >> indicate the "direction", in which a UA supports a specific method.
 >>
 >>
 >> For example a UA that indicates support for the methods SUBSCRIBE
 >> and NOTIFY would add a contact parameter as follows:
 >>
 >> Now, does this mean the UA has to accept and be able to send both
 >> methods? I would guess that for some UAs it would make sense to
 >> support the ability to subscribe to an event and receive NOTIFYs,
 >> but not to accept SUBSCRIBEs and send NOTIFYs itself.
 >>
 >> Regards,
 >>
 >> Mark
 >>
 >> Mark Beckmann			Siemens AG
 >>
 >> ICM MP P PS 4S2 P.O.Box 100702			phone: +49 (5341) 906 1814 D-38228
 >> Salzgitter   		fax:   +49 (5341) 906 2010
 >>
 >>> -----Original Message----- From: Jonathan Rosenberg
 >>> [mailto:[email-masked]] Sent: Thursday, September 26,
 >>> 2002 7:21 PM To: Miguel A. Garcia Cc: [email-masked]; Keith Drage
 >>> Actually, RFC 2533 (which we are using) does say something
 >>> concrete about what it means to say nothing about a feature tag.
 >>> It
 >>
 >> means that
 >>
 >>> you are supporting all values. This means you need to be careful
 >>> about the semantics of the headers - the existing Reject-Contact
 >>>  semantic of "reject this contact if its feature set matches" is
 >>> bad, because it will cause a UA to be rejected even if it has
 >>> said nothing about a particular feature tag!
 >>>
 >>>>
 >>> There was a thread on the list (likely followed by no one)
 >>> between myself, Juha, and Paul K. on this exact issue. Our
 >>> conclusion was that it was reasonable to mandate that a UA
 >>> include all values
 >>
 >> it supports
 >>
 >>>>  opinion, if a feature is present, it should be complete. In
 >>>> this case, all the methods supported by the UA must be present.
 >>>>
 >>>
 >>> That is correct.
 >>>
 >>>>
 >>>> like ACK (implicitly supported if INVITE is supported), or
 >>>> NOTIFY (implicitly supported if SUBSCRIBE is supported).
 >>>>
 >>> server to lean what other methods a UA will support based on the
 >>> ones it listed. That won't always be a trivial exercise.
 >>>
 >>>>
 >>>> Last, but not least, whatever is the correct thing to do, can
 >>>> you please add a very clear sentence to the caller preferences
 >>>>
 >>> draft, so
 >>> -- Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
 >>> dynamicsoft                                 East Hanover, NJ
 >>> 07936 [email-masked]                     FAX:   (973)
 >>> 952-5050 http://www.jdrosen.net                      PHONE: (973)
 >>> 952-5000 http://www.dynamicsoft.com
 >>>
 >>> _______________________________________________ Sip mailing list
 >>> https://www1.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
 >>>
 >>
 >> _______________________________________________ Sip mailing list
 >> https://www1.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
 >>
 >
 >