Joanne, >Can we eliminate the "futures" discussion here for that "other track" and just deal with the immediate need please? This is new to me: IP networks (such as inside contact centers, enterprises) and the Internet are futures? :-) But I do not intend to press this any further. Henry On 11/20/08 1:17 PM, "Joanne McMillen" <joanne@xxxxxxxxx> wrote: I can tell you what one author thinks Henry. ;-) Like Laura and others have stated - we have an immediate need here. Where this may go in the future with enhanced definitions in SIP is future consideration. We all agree (I suspect) that SIP can be far more robust here for this "functionality". When and if someone wants to define what that new and robust "functionality" is in SIP it would beg the question as to whether or not this specific header for UUI is the right avenue for that. It could be and it couldn't be - I can see that debate going either way and for very good reasons for going either way. The bottom line is we have an immediate need right now that this draft addresses - I do not want to see this get bogged down by future concerns - and the definition allows for that if anyone chooses to extend it going forward in SIP... Can we eliminate the "futures" discussion here for that "other track" and just deal with the immediate need please? Thanks, Joanne ----- Original Message ----- From: Henry Sinnreich <mailto:hsinnrei@xxxxxxxxx> To: Laura Liess <mailto:Laura.Liess@xxxxxx> ; Cullen Jennings <mailto:fluffy@xxxxxxxxx> ; Paul Kyzivat <mailto:pkyzivat@xxxxxxxxx> Cc: sipping <mailto:sipping@xxxxxxxx> ; Joanne McMillen <mailto:joanne@xxxxxxxxx> ; DRAGE, Keith (Keith) <mailto:drage@xxxxxxxxxxxxxxxxxx> ; Huelsemann, Martin <mailto:Martin.Huelsemann@xxxxxxxxxx> Sent: Thursday, November 20, 2008 11:37 AM Subject: Re: draft-johnston-sipping-cc-uui-05 > 1) Get this syntax agreed as soon as possible because it is needed by > the industry in the today's PSTN/SIP mixed environment. Well, I have here to make the observation that SIP-PSTN is not the only mixed environment. SIP is also used on IP networks and on the Internet and the UUI may look there vastly more different - probably extensible and very powerful. And it may be just as urgent. So it appears the SIP UUI may end up with two tracks, one for compatibility with ISDN and the other for the IP networks and the Internet. What do the authors think? Henry On 11/20/08 9:03 AM, "Laura Liess" <Laura.Liess@xxxxxx> wrote: > This is precisely my concern. By doing this we are adopting this syntax > for carrying data for what will eventually be *SIP* services. Is this > *really* the way we want to support those services in a native sip > environment? Paul, I do not see why we should not do both and leave the decision to the market. IETF did this in the past. 1) Get this syntax agreed as soon as possible because it is needed by the industry in the today's PSTN/SIP mixed environment. If we do not come up very soon with a standard, people will use proprietary extenssions. I think we should avoid this. There are no technical reasons not to move on with the draft. 2) In the long term we could develop a "native sip" syntax which is more flexible, easier to implement, whatever.... It will have advantages in a "sip native" environment and it will be adopted when the "native sip" environement is in place. Laura > > Once its done it will not make sense to develop a different syntax for > native sip use. > > If we go this way, every sip entity that needs to deal with these will > need to have the needed ASN.1 encoding/decoding logic. I don't know if > that is trivial to special case because I don't know what all the various > formats are. But it would at least be annoying. > > Thanks, > Paul > >>> Until we solve this with an appropriate mechanism, SIP will not >>> make headway into areas such as contact centers. >>> >>> And, there is a limit on the size of data - please read the draft. >>> >> >> Hmm - you are right that when I read it, I had missed the key part of >> >> Note that ISDN limits UUI to 128 octets in length. While this header >> field has no such limitations, transporting UUI longer than 128 >> octets will result in interoperability failures when interworking >> with ISDN. >> >>> >>> >>> And the draft says nothing about proxy inspection and routing. I >>> mentioned it in my email because we know that clever implementors will >>> do clever things. >>> >>> The draft is not making the arguments you specify. >>> >>> So, if I remove the text in your comments about this being an ISDN >>> parameter mapping issue, the size being unlimited, and problematic proxy >>> behavior, I don't think there are any remaining issues. >>> >>> If you have issues with the requirements in the draft, let us know so we >>> can clarify them. >>> >> I can easily imagine cases where customer sensitize information was >> transfered over this and it was going to an remote agent phone that went >> through another trust domain to route the call to the agent. In these >> cases, I think an important requirement would be to protect the draft >> from authorized access by intermediaries. >> >>> >> >> Cullen in my individual contributor role >> >> _______________________________________________ >> 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
