Brett,
Consider the following:
From: PaulKyzivat <sip:[EMAIL PROTECTED]>
From: "PaulKyzivat" <sip:[EMAIL PROTECTED]>
I can certainly imagine that a stack might receive either of these, and
convert into some internal form that is identical for both. Then when
generating a new request it might re-encode it using a different form
than it received. For instance it might always use the quoted form. Or
it might always use the token form if it could be represented that way,
and only use the quoted form if it had to.
Its not clear if that would be valid behavior or not.
Paul
Brett Tate wrote:
>> I don't see anything in the material you quote
>> that says whether or not the quoted diversion
>> and the unquoted diversion mean the same thing.
>> They are both reasons, but are they the same reason?
>> In this context it seems probable that they
>> ought to mean the same thing, but its not entirely clear.
>>
>> I *presume* the point here is to allow values
>> with the form of tokens to be supplied without
>> quotes, but also to allow values that require
>> quotes to be entered with quotes. But it would
>> have been better if the text was clearer about this.
>
> I agree. I just wasn't sure if there was some default behavior defined
> somewhere causing quote removal when the contents is being used.
>
> Consider the display-name of the From which allows tokens and
> quoted-string. Since nothing (that I'm aware of) overrides the default
> behavior, the quotes of a quoted string are actually part of the name to
> be displayed. Thus it is currently impossible for a user desiring comma
> within display name to be communicated without is also causing the
> quotes to be rendered (unless receiver assumes quotes extraneous).
>
> Thanks,
> Brett
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
