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