<<in-line>>
>-----Original Message-----
>From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>Sent: 20 October 2003 16:45
>To: [EMAIL PROTECTED]
>Subject: [Sip-implementors] Question: Scope of Accept header & relation
to
>REFER
>
>[I think there was a discussion on scope of Accept wrt dialogs not too
>long ago, but I can't find it.]
>
>This question came up in looking at a REFER call flow. The question is
>whether an "Accept: message/sipfrag" is ever required in order to
>indicate ability to accept the notifications resulting from the refer.
>
>In 3261, the majority of the semantics of Accept are deferred to
>RFC2616. But that isn't much help for this, because the scope of an
>Accept in 2616 seems to be limited to the response to the message
>carrying it, and that doesn't seem appropriate for SIP.
>
>So, in the context of SIP it isn't clear to me if an Accept message
>should be exhaustive, like Allow is, or just a way of reporting some of
>the types accepted. The description of error 406 in 3261 certainly
>suggests that a server should treat the Accept header as a complete and
>exhaustive list, else it would never be appropriate to return a 406
error.
>
>Let me pose a specific scenario that I am curious about:
>
>1) INVITE ... (initiates new dialog)
> (no Accept header - default is Application/SDP)
>
>2) 200 OK
>
>3) ACK
>
>5) REFER ... (same dialog)
> (no Accept header)
>
>6) 202 OK
>7) NOTIFY ...
> Cotent-Type: message/sipfrag
>
>According to 3261, the default for Accept is application/sdp. Should
>the server conclude it can't send the notify? If so, what should it do?
>Should it refuse the REFER with a 406? Should it just not send the
NOTIFY?
>
>Or should the server assume an implied Accept: message/sipfrag in
>message #5?
[Chris Boulton] This is a good question Paul - I personally see REFER
being explicitly tied to 'message/sipfrag' (Maybe incorrectly ;-) - Even
if an alternative is advertised in the initial REFER message.
>
>Would anything change if there was an explict Accept header in message
>#1 that doesn't mention sipfrag, such as "Accept:
>application/sdp,text/plain"?
>
> Thanks,
> Paul
>
>_______________________________________________
>Sip-implementors mailing list
>[EMAIL PROTECTED]
>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
