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