Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER?

[Paul Kyzivat <[e-mail]>]

Gao,

Some of us have talked from time to time about issues with REFER.
(I think Dale wrote a draft about it once.)

Specifically, there is an element of "do what I mean" to it that 
requires the recipient to be psychic about what is intended.

E.g. I can send a REFER ... method=FOO to you. You may have no clue what 
method FOO is. Should you just construct a generic FOO method and send 
it? Or I could send an embedded header that says "Supported:BAR", when 
in fact you don't know about option BAR.

Hence the latitude for the referred UA to pick and choose what it wants 
to honor. At least that way it can have some assurance that it 
understands how to process the resulting request. But of course that 
means the referring party doesn't know if the request followed its 
intentions.

I don't have a good answer for that. Something that comes to mind is for 
a copy of the resulting request to be sent to the referring UA as part 
of the refer subscription. But it would be difficult to make good use of 
that.

	Thanks,
	Paul

On 10/13/2010 4:08 AM, [e-mail] wrote:
>
>
>  > As far as I know, there are no explicit restrictions.
>  >
>  > One could, however, ask whether it's allowed to include headers that
>  > are not to be used in the triggered INVITE, but in later associated
> requests.
>
> RFC3261 section 19.1.5
>
> An implementation MUST include any provided transport, maddr, ttl, or
> user parameter in the Request-URI of the formed request. If the URI
> contains a method parameter, its value MUST be used as the method of
> the request. The method parameter MUST NOT be placed in the
> Request-URI. Unknown URI parameters MUST be placed in the message's
> Request-URI.
>
> An implementation SHOULD treat the presence of any headers or body
> parts in the URI as a desire to include them in the message, and
> choose to honor the request on a per-component basis.
>
> An implementation SHOULD NOT honor these obviously dangerous header
> fields: From, Call-ID, CSeq, Via, and Record-Route.
>
>  From the above text, it seams that the rules for embedded headers is
> not as emphatic as transport, maddr, ttl and user parameter. So, I
> suggest that one specific embedded headers could have a specific usage
> guidelines, especially these headers with dangerous header fields.
>
> I'd like to point out that I am not going to say that people's
> understanding of embedded headers(for pure audio usage) is not correct.
>
>  > You CAN also embed SDP information.
>
> Are there any defined rules for such embedded SDP information? If there
> are, could you show me.
>
> Thanks,
>
> Gao
>
> --------------------------------------------------------
> ZTE  Information  Security  Notice:  The  information  contained  in  this  mail  is  solely  property  of  the  sender's  organization.  This  mail  communication  is  confidential.  Recipients  named  above  are  obligated  to  maintain  secrecy  and  are  not  permitted  to  disclose  the  contents  of  this  communication  to  others.
> This  email  and  any  files  transmitted  with  it  are  confidential  and  intended  solely  for  the  use  of  the  individual  or  entity  to  whom  they  are  addressed.  If  you  have  received  this  email  in  error  please  notify  the  originator  of  the  message.  Any  views  expressed  in  this  message  are  those  of  the  individual  sender.
> This  message  has  been  scanned  for  viruses  and  Spam  by  ZTE  Anti-Spam  system.
>
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore