> -----Original Message-----
> From: Fleischman, Eric W [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 27, 2001 11:26 AM
> To: 'Shail Bhatnagar'; Jonathan Rosenberg
> Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] the meaning of "copy"
>
>
> For whatever its worth, URLs can and do have white spaces.
Err, then they are in violation of rfc2396. Section 2.4.3 is quite clear:
2.4.3. Excluded US-ASCII Characters
Although they are disallowed within the URI syntax, we include here a
description of those US-ASCII characters that have been excluded and
the reasons for their exclusion.
The control characters in the US-ASCII coded character set are not
used within a URI, both because they are non-printable and because
they are likely to be misinterpreted by some control mechanisms.
control = <US-ASCII coded characters 00-1F and 7F hexadecimal>
The space character is excluded because significant spaces may
disappear and insignificant spaces may be introduced when URI are
transcribed or typeset or subjected to the treatment of word-
processing programs. Whitespace is also used to delimit URI in many
contexts.
space = <US-ASCII coded character 20 hexadecimal>
-Jonathan R.
>
> -----Original Message-----
> From: Shail Bhatnagar [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 27, 2001 6:04 AM
> To: Jonathan Rosenberg
> Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] the meaning of "copy"
>
>
> > >
> > > It seems to me that byte-by-byte is more robust and easier to
> > > compare in
> > > terms of "From" and "To" headers. What are the potential
> reasons that
> > > somebody wants to modify these two headers in addition to the
> > > "Tag" param?
> >
> > The problem has to do with storing whitespace on other
> formatting > >characters
> > when parsing. I'd like to be able to parse a header,
> discard any LWS, and
> > reconstruct the header. This should be "equivalent" based
> on concrete
>
> I thought URLs cannot have whitespace, so I am not convinced
> about a proxy/ua messing around with From/To except appending
> a tag.
> While we are here, I posted some questions several times on
> the sip-implementors about transaction identification, but
> nobody responded.
> If To header tag is included in the hash computation, then
> ACK for a INVITE will identify a transaction different from
> the original INVITE. This is acceptable for an ACK for a 200,
> but not for non-200 ACK ( proxy has to stop response retx timer).
> If To header tag is not included then 2 different PRACKs will
> hash to the same transaction.
>
>
> > matching rules, to the initial version.
> >
> > -Jonathan R.
> >
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
---
Jonathan D. Rosenberg 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
