[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03
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: sipping-bounces at ietf.org
> [mailto:sipping-bounces at ietf.org] On Behalf Of Alan Johnston
> Sent: Wednesday, October 22, 2008 6:44 PM
> To: Christer Holmberg
> Cc: sipping at ietf.org; 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: sipping-bounces at ietf.org on behalf of Paul Kyzivat
> > Sent: Wed 22/10/2008 16:52
> > To: Adrian Georgescu
> > Cc: sipping at ietf.org
> > 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
> >> sip-implementors at cs.columbia.edu for questions on current sip Use
> >> sip at ietf.org 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
> > sip-implementors at cs.columbia.edu for questions on current sip Use
> > sip at ietf.org 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
> > sip-implementors at cs.columbia.edu for questions on current sip Use
> > sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current
> sip Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP