Hi,
If we remove E and F (which I think nobody has really
objected to) there
is no reason why the draft should be delayed.
The escape issue will be dealt with elsewhere
("3261bis").
Regards,
Christer
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat cisco.com]
> Sent: 13. maaliskuuta 2007 15:08
> To: Alexeitsev, D
> Cc: iptelietf.org; Liess, Laura; Beck01,Wolfgang
> Subject: Re: AW: AW: [Iptel] "*" and
"#" signs in the
> userinfo of SIP URI
>
>
>
> Alexeitsev, D wrote:
> > Comments inline
> >
> >> - Are you worried about people having to type
in
> dialstring URIs with
> >> the escape? (Who would want to do so?)#
> >
> > No
> >
> >> - Or are you worried about people being
confused when
> looking at them?
> >> (Who will see them?
> >
> > Yes, conformance testing would be much simpler if
you could
> understand
> > it clear text. At the end it was one of the main
arguments pro SIP
> > that it can be understood without expensive
protocol decoders.
>
> Then should we also eliminate the requirement to escape
> characters when headers are embedded in URIs? Escaping
is a
> fact of life. If implementors can't understand it they
should
> get a different job.
>
> >> - Or are you worried about the burden on the
recipient that has to
> >> process the escape? (Escapes must be processed
in any case.)
> >
> > No
> >
> > I am worried about the endless rounds of
discussions with the CPE
> > implementers about how to encode the "#"
sign and why should it be
> > escaped when the "*" is not escaped.
Especially the IAD
> vendors that
> > would normally have to encode only digits, would
have to implements
> > the escaped syntax just for one sign.
>
> My heart bleeds for them. 
>
> > I'm also worried about the terminals sending the
strings like
> > sip:12331E313example.com where there is no possibility
to
> understand
> > if it is a dial string or just a weird alias some
one
> picked up. You
> > can neither differentiate at the user interface
whether it
> is a dial
> > string, or alias to attach the user=dialstring
parameter,
> nor at the proxy.
>
> If E and F are only URI encodings for the dialing of
the
> characters * and #, then there should be no problem at
the
> user interface. Just don't allow the use of E and F for
this
> purpose in the user interface. And any UI that is
collecting
> a dialstring and passing it directly as a URI (without
> expansion to E.164) should always use user=dialstring
to
> distinguish it from a real sip username.
>
> If you are concerned with figuring this out after the
fact -
> after the dialstring has been encoded as a SIP URI with
no
> user=dialstring - then you should also be concerned
with the
> characters A-D. E.g.
>
> SIP:dadfoo.com
> vs SIP:dadfoo.com;user=dialstring
>
> Note: I think it would be *better* to remove E and F,
but
> only to prevent there from being two ways to encode the
same
> thing, not for the above reasons. And I don't think it
is
> important enough to delay this if there is no other
reason to
> delay it.
>
> Paul
>
> _______________________________________________
> Iptel mailing list
> Iptelietf.org
> https://
www1.ietf.org/mailman/listinfo/iptel
>
_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel
|
