Subject: RE: [Sipping] draft-elwell-sipping-service-retargeting-00.txt, RFC 387, and netann draft

From: "Francois Audet" <[email-masked]>
Date: Fri, 14 Oct 2005 17:56:54 -0500

Glad you point it out...

It is pretty much exactly the same mechanism. We want a formal
syntax for something that is a problem that many of us are
faced with in an heterogenous environment.

Section 6 of Netann in particular explains the rationale.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Friday, October 14, 2005 14:51
> To: sipping
> Subject: [Sipping] 
> draft-elwell-sipping-service-retargeting-00.txt, RFC 387,and 
> netann draft
> 
> 
> 
> On Oct 13, 2005, at 9:22 PM, Francois Audet wrote:
> 
> > draft-elwell-sipping-service-retargeting provides EXPLICIT service 
> > invocation, in exactly the same way RFC 3087 does. The only 
> difference 
> > with RFC 3087 is that the URI parameters in RFC 3087 are abstract 
> > "examples", while we would like the parameters to be 
> well-known so we 
> > could do interoperable products.
> >
> 
> So how does this relate to draft-burger-sipping-netann-11, which  
> provides mechanisms for forward-encoding of standard 
> imperatives into  
> the request URI in accordance with RFC 3087?
> 
> 
> --
> Dean
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2005 19:27:34 -0400

> Section 6 of Netann in particular explains the rationale.

Francois,

IMO both netann and 3087 expect that the creator of the URI *knows* that 
the target of the URI *expects* these particular parameters to be there.

(Namely, I only put a "play" parameter on the URI for a media server 
that is documented as accepting that, never on some stranger's AOR or on 
a registered contact address.)

If that is an acceptable constraint on your proposal then I have less 
trouble with it. These are then just some very perverse media servers 
that like strangely spelled parameters.

OR, you could then go the other way and adopt some more intuitive names 
for these services, and just teach PSTN gateways to translate those into 
pstn-isms.

	Paul