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@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Alan Johnston > Sent: Wednesday, October 22, 2008 6:44 PM > To: Christer Holmberg > Cc: sipping@xxxxxxxx; Paul Kyzivat > Subject: Re: [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@xxxxxxxx on behalf of Paul Kyzivat > > Sent: Wed 22/10/2008 16:52 > > To: Adrian Georgescu > > Cc: sipping@xxxxxxxx > > Subject: Re: [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@xxxxxxxxxxxxxxx for questions on current sip Use > >> sip@xxxxxxxx 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@xxxxxxxxxxxxxxx for questions on current sip Use > > sip@xxxxxxxx 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@xxxxxxxxxxxxxxx for questions on current sip Use > > sip@xxxxxxxx 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@xxxxxxxxxxxxxxx for questions on current > sip Use sip@xxxxxxxx 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@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
