I thought the inquiry was wrt the Expires header, not the expires header
parameter. The text in 8.3 seems to be talking about what to do if the
value of the expires parameter is malformed. And that only applies to
use in Contact, and perhaps only for use by redirect servers.
So for instance I would argue that this doesn't apply to an Expires
header in a REGISTER. Or even to an expires parameter in a Contact
header in a REGISTER.
(This section is not as clear as one might hope.)
Thanks,
Paul
So the
Brett Tate wrote:
> RFC3261 section 8.3:
>
> "The "expires" parameter of a Contact header field value indicates how long
> the URI is valid. The value of the parameter is a number indicating seconds.
> If this parameter is not provided, the value of the Expires header field
> determines how long the URI is valid. Malformed values SHOULD be treated as
> equivalent to 3600.
>
> This provides a modest level of backwards compatibility with RFC 2543,
> which allowed absolute times in this header field. If an absolute time is
> received, it will be treated as malformed, and then default to 3600."
>
>> -----Original Message-----
> <snip>
>>
>> Neel Balasubramanian wrote:
>>
>>> [Neel]
>>> Malformed values typically be treated as 3600 and not as 0.
>> First, we generally don't specify what is done for invalid cases.
>> (If we did, in effect we would be extending the spec to that case and so
>> it would be valid.)
>>
>> But IMO it makes sense in cases like this to treat it as if the header
>> had not been present. So you would get the *default* value.
>> In some cases that is 3600.
>>
>> Paul
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
