Re: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

[Christer Holmberg <[e-mail]>]

Hi,

>Rather than a new feature tag, why cannot something within the header field itself define the support, e.g. even a dummy value in the proposed additional header field parameter.
>
>Surely one the characteristics we would not want that goes with a media feature tag, is the possible selection of the recipient terminal based on the support of the extension - that certainly does not figure in our requirements.

A feature tag is what we normally use to indicate capabilities, so I see no reason why we would need to have additional requirements for using it.

Having said that, I am not religious about what mechanism is used, as long as there is *A* mechanism for the receiver to figure out whether the sender supports the feature or not.

Regards,

Christer


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Christer Holmberg
> Sent: 14 September 2013 15:33
> To: Hadriel Kaplan; James Polk
> Cc: Atle Monrad; [e-mail]; Gonzalo Camarillo
> Subject: Re: [Insipid] Timing for publishing 
> draft-kaplan-insipid-session- id
> 
> Hi,
> 
> Does anyone have issues with my suggestion below? I believe it could 
> be a rather straight forward solution. Paul, James & co get what they 
> want, and the backward compatibility folks get what they want :)
> 
> The only question is how a sender indicates that it support the 
> INSIPID mechanism. From a pure SIP protocol perspective, I believe a 
> media feature tag would be the most feasible mechanism. Now, Hadriel 
> have indicated that some intermediaires may remove feature tags. 
> However, in this case, maybe that would actually be a GOOD thing, 
> because it would automatically take care of the case where there are 
> intermediares that don't support the INSIPID mechanism in the path :)
> 
> What do people think? If needed, I am willing to provide text.
> 
> Regards,
> 
> Christer
> 
> ________________________________________
> From: [e-mail] [[e-mail]] on behalf of 
> Christer Holmberg [[e-mail]]
> Sent: Thursday, 12 September 2013 4:12 PM
> To: Hadriel Kaplan; James Polk
> Cc: Atle Monrad; [e-mail]; Gonzalo Camarillo
> Subject: Re: [Insipid] Timing for publishing 
> draft-kaplan-insipid-session- id
> 
> Hi,
> 
> >>> I've always stated we editors of the jones draft will make the
> solution as backwards compatible with the kaplan draft as
> >>> possible, but that a 2 value ID will run into problems with a 
> >>> single
> value implementation, and that should be obvious to
> >>> everyone who thinks about it for a second.
> >> That said, we have received ZERO comments to our latest proposal 
> >> that
> we think actually accomplishes this no matter
> >> the version of the endpoint that initiates or receives the SIP
> message... zero... and that's really disheartening.
> >
> > Ummm... what latest proposal?  I may have missed an email somewhere.
> 
> One of my early proposal was that, if either endpoint supports Kaplan, 
> we simply won't use the 2 value ID.
> 
> So, if the one sending the INVITE only supports Kaplan (we need to 
> define how that is determined), the receiver does not add the 2nd 
> part, copies the received value into the response, and uses that in 
> any subsequent request/response within the session.
> 
> And, if the receiver only supports Kaplan (the sender will figure this 
> out since the receiver won't add the 2nd part), then only one part 
> will be used in each request/response through the session.
> 
> Now, that takes care of backward compatibility as far as the endpoints 
> are concerned. However, there could of course be an intermediary that 
> doesn't support the INSIPID mechanism, but the question is whether that matters.
> 
> Regards,
> 
> Christer
> 
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid