Re: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03

["DRAGE, Keith \(Keith\)" <[e-mail]>]

Going to another organisation for a definition of profile (ETS 300 406
but I believe it is consistent with ISO 9646):

"A profile identifies a consistent set of chosen options from a base
specification or from a set of base
specifications, in order to provide a given function in a given
environment.
By restricting choices among the options available in the base
specifications, a profile increases the
probability that systems will interoperate, i.e. perform together the
given function to which the profile is
aimed at.
The base specifications upon which a profile is based are called
components of this profile."

What you have is a profile.

What needs to be clear is when that profile is useful to a reader, and
when it merely provides a chocolate teapot. Paul is saying that and I
agree with him. Noone is saying that the profile you have provided is
not useful. 

Regards

Keith

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alan Johnston
> Sent: Wednesday, October 22, 2008 6:44 PM
> To: Christer Holmberg
> Cc: [e-mail]; Paul Kyzivat
> Subject: Re: [Sipping] [RAI] Expert review of 
> draft-sinnreich-sip-tools-03
> 
> I've been holding off wading into this discussion to see 
> where it goes.  
> As it has really gone off track, I'll put in my views.
> 
> Firstly, this is *not* a profile of SIP - this document 
> doesn't say you don't have to support parts of RFC 3261.  
> However, it is, perhaps, a profile of the entire set of SIP 
> extensions.  As such, it is a valuable counterweight to the 
> Hitchhikers guide which is a frightening expose of the 
> kitchen sink of extensions we have developed over the years.
> 
> And as for the requirements being clear, I think they are, 
> but perhaps many people just can't get their heads around 
> them.  Only use servers for rendezvous functionality, and 
> that's it.  Period.  What part of this isn't clear?  I know 
> it doesn't fit with the current service provider/research 
> focus that is what drives us today in RAI.  And if this is 
> your focus, you can ignore the document and go back to your day job.
> 
> I think that many people will applaud and understand this 
> draft, but those people aren't the ones who post on the RAI 
> lists every day.  They are the poor implementors who are 
> trying to get by and interoperate given the mess we have created.
> 
> Thanks,
> Alan
> 
> Christer Holmberg wrote:
> > Hi,
> >  
> > I agree with Paul.
> >  
> > Normally, when you put together a list of RFCs etc that you 
> need to support/implement, you do that based on REQUIREMENTS.
> >  
> > The requirements may be specified for a typical network 
> architecture (IMS for example), and/or requirements specified 
> by a customer.
> >  
> > So, I think it should be clearly written what requirements 
> the spec is trying to solve (we do that with all SIP specs 
> nowadays, don't we?). If we're just trying to come up with a 
> good list of RFCs based on "taste", many people may have 
> different opinions on what it should contain...
> >  
> > In addition, in my opinon the draft defines a PROFILE.
> >  
> > Regards,
> >  
> > Christer
> >  
> >
> > ________________________________
> >
> > From: [e-mail] on behalf of Paul Kyzivat
> > Sent: Wed 22/10/2008 16:52
> > To: Adrian Georgescu
> > Cc: [e-mail]
> > Subject: Re: [Sipping] [RAI] Expert review of 
> > draft-sinnreich-sip-tools-03
> >
> >
> >
> >
> >
> > Adrian Georgescu wrote:
> >   
> >> Hi Paul,
> >>
> >> I believe Henry is heading into one direction only. The idea is to 
> >> help developers implement the minimum necessary features in their 
> >> User Agent and not biased towards a voice only 
> application. The SIP 
> >> end-points as describe by Henry would work with any 
> service provider 
> >> as long as they talk plain SIP. So 911 and voicemail and other 
> >> services can be performed in the network as well, they are 
> just another end-point.
> >>     
> >
> > There is a huge difference between services implemented in 
> the UA and 
> > services implemented in the network. Take for example emergency 
> > services. The typical implementation is simply for the UA to accept 
> > the dial string (e.g. 911) and put it into an INVITE. The UA most 
> > likely is treating this as any other call - not realizing 
> it is an emergency call.
> > Hence it doesn't apply special processing to it, that is 
> supposed to 
> > be supplied, like refusing to disconnect the call on 
> hangup. Also, it 
> > doesn't play any part in determining its location - 
> depending on the 
> > network to be able to figure that out. The network may or 
> may not be 
> > able to determine that.
> >
> > In any case, each SP has its own requirements for what a 
> device that 
> > connects to it must do to work with it. Perhaps it would be 
> a useful 
> > thing to create a common spec for a UA that can work with 
> "most" SPs. 
> > To do that it would probably be better to gather the specs from the 
> > SPs than to look at a few phone adapters. But I think a lot 
> of SPs are 
> > not open to connection from devices they don't supply, so there may 
> > not be a lot of value in such a spec.
> >
> >   
> >> If I were to develop a SIP UA today (which  I do actually) Henry's 
> >> draft would be the starting point. I would definitely add 
> MSRP to it, 
> >> without relays as a minimum but adding relay extension is not that 
> >> difficult, because any application that requires reliable or large 
> >> data transport need a TCP media plane that SIP signalling 
> or RTP does not provide.
> >> End-to-end encryption can also be realized on top of 
> established MSRP 
> >> session. File transfer and session based IM are 
> applications that an 
> >> end user would take for granted today and SIP lacks both.
> >>     
> >
> > If I were to develop a UA today, I think I would figure out who I 
> > intend it to connect to, and find out what their 
> requirements are. If 
> > somebody already has made a consolidated set of requirements that 
> > covers all those things I intend to talk to then that would 
> be helpful to me.
> >
> > That is what I am lacking in the present document. It 
> doesn't tell me 
> > what its field of applicability is.
> >
> >         Thanks,
> >         Paul
> >
> >   
> >> Also the rich presence conflicts with the basic presence PIDF, I 
> >> would go for rich presence even if the "richness" of the 
> information 
> >> is something that would be avoided due to its complexity in the 
> >> presentation to end-user interface.
> >>
> >> For the rest I would not do much changes to the draft.
> >>
> >> Regards,
> >> Adrian
> >>
> >>  >>>>>>>>
> >>
> >>
> >>
> >>
> >> Henry,
> >>
> >> Based on this discussion, it now sounds like you are 
> heading in *two*
> >> directions:
> >>
> >> - connecting to a SP that provides services (e.g. 911, 
> maybe others,
> >>    like voicemail, forwarding, ...)
> >>    The SP in this case is largely looking for a "dumb" device and
> >>    provides the services in the network. The "request for service"
> >>    is then "tunneled" via simple services like invite, with the
> >>    service request encoded in the AOR. (e.g. the "911", or 
> "star" codes).
> >>    In this case you are then competing with other profiles, such as
> >>    SIPConnect or PacketCable.
> >>
> >> - very low added value SP, that simple provides registration
> >>    and routing. All services are provided by the UAs.
> >>
> >> I'd like to see the goals spelled out better. Then we can 
> discuss if 
> >> they are met.
> >>
> >>     Thanks,
> >>     Paul
> >>
> >> _______________________________________________
> >> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP Use 
> >> [e-mail] for questions on current sip Use 
> >> [e-mail] for new developments of core SIP
> >>
> >>     
> > _______________________________________________
> > Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > [e-mail] for questions on current sip Use 
> > [e-mail] for new developments of core SIP
> >
> >
> > _______________________________________________
> > Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > [e-mail] for questions on current sip Use 
> > [e-mail] for new developments of core SIP
> >
> >
> >   
> 
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [e-mail] for questions on current 
> sip Use [e-mail] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP