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

[Paul Kyzivat <[e-mail]>]

I must say, I believe Christer, Keith, and I are all on exactly the same 
page. Amazing! (I can't remember any other time for that.)

Alan says:

> 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?  

Actually I thought it was reasonably clear when I did my initial review. 
(Aside from the issue of PSTN interconnect, which also seemed to be in 
scope, using some other sort of server.) Its become less clear to me in 
the subsequent discussion, especially based on some of the comments from 
Eunsoo.

But what *wasn't* clear is what it is expected that these UAs will be 
able to *do* when they have rendezvoused, using this set of specifications.

I might actually understand this better if it were billed as a "primer" 
to the hitchhikers guide: a suggestion of what to learn first if you are 
trying to get started as a sip implementor.

But rather it seems to be billed as "this should be all you need to 
know", and it that case I really want to know "all I need to know to do 
XYZ".

	Thanks,
	Paul

DRAGE, Keith (Keith) wrote:
> 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