Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418

From: Dean Willis <[email-masked]>
Date: Tue, 31 Jul 2007 23:55:57 -0500

Hadriel Kaplan wrote:
> Yeah but a 480 implies the resource is not available, whereas in reality the
> resource *is* available using a different scheme.  I guess one question is
> if the sips scheme literally means the UAS is a different "resource".  If
> so, then registering a sips contact only should not implicitly make the UAS
> available for routing plain sip.  The draft currently says they represent
> the *same* resource.

I tried to make this argument earlier (I think one should have separate
registrations for sip and sips) but wasn't successful.

Perhaps you've just made it more convincingly.

> I'm not convinced by the downgrade argument.  The far-end can just as easily
> send a 3xx redirecting the UAC to the sip contact.  Per this new draft the
> proxies must not recurse on that, and the UAC should inform the user before
> doing so.  But I think a new 4xx response code would be much more likely to
> make that a reality, as any vendor implementing support for recursing on a
> 418 would have read the draft and seen where it says "inform the user".  If
> they didn't read the draft, they'd fail the request since they got an
> unknown 4xx response. (compare that to a 3xx, which is known/usable without
> reading this draft)  Am I missing the gist of the concern?

If they haven't read the draft, failing the request is the Right Thing
to Do.

What we are apparently attempting to do is make it where an unread
implementer is likely to Do the Wrong Thing, namely downgrade to sip:
and try again.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Jul 2007 23:58:55 -0500

> implementer is likely to Do the Wrong Thing, namely downgrade to sip:

Darn it! I mean "UNLIKELY to Do the Wrong Thing".

I gotta stop reading email while running regression tests in another window.

--
Dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 1 Aug 2007 01:18:21 -0400

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2007 12:56 AM
> 

Yup, that was my point.  

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 1 Aug 2007 01:22:37 -0400

Ahh - no what I missed was that you were giving a specific warning code for
the 480 such that a machine can automatically warn the user and retry,
disambiguating it from a generic 480.  That's cool for me.  I thought the
options were either an ambiguous 480 or explicit 418, but it's now an
explicit 480.  Sounds good.

-hadriel

> From: Francois Audet [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2007 5:51 PM
> To: Hadriel Kaplan
> Cc: IETF SIP List
> Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
> 
> 480 means that the user identified by the Request-URI is recognized, but
> there is currently no valid forwarding location for that user. In this
> case,
> no SIPS contacts.
> 
> What many people are missing in the 480 vs. 418 argument is the
> following:
> 
> - Existing implementations will treat new 4XX error codes as 400,
>   which basically means "the protocol message is broken".
> 
> - Existing implements will treat 480 with new Warning just like
>   480 witn no warning, i.e., as "Temporarily unavailable".
> 
> There is a huge difference between the 2. 400 will lead you to believe
> that there is something wrong with the equipment (i.e., you may file a
> complaint with the manufacturer). Very bad.
> 
> 480 just means the other end is not available at that address. Good.
> Everybody is happy.
> 
> > From: Hadriel Kaplan [mailto:[email-masked]]
> > Sent: Tuesday, July 31, 2007 14:25
> > To: 'Rohan Mahy'; 'Michael Thomas'
> > Cc: 'IETF SIP List'; Audet, Francois (SC100:3055);
> > [email-masked]; 'Paul Kyzivat'
> > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
> >
> > Yeah but a 480 implies the resource is not available, whereas
> > in reality the resource *is* available using a different
> > scheme.  I guess one question is if the sips scheme literally
> > means the UAS is a different "resource".  If so, then
> > registering a sips contact only should not implicitly make
> > the UAS available for routing plain sip.  The draft currently
> > says they represent the *same* resource.
> >
> > I'm not convinced by the downgrade argument.  The far-end can
> > just as easily send a 3xx redirecting the UAC to the sip
> > contact.  Per this new draft the proxies must not recurse on
> > that, and the UAC should inform the user before doing so.
> > But I think a new 4xx response code would be much more likely
> > to make that a reality, as any vendor implementing support
> > for recursing on a
> > 418 would have read the draft and seen where it says "inform
> > the user".  If they didn't read the draft, they'd fail the
> > request since they got an unknown 4xx response. (compare that
> > to a 3xx, which is known/usable without reading this draft)
> > Am I missing the gist of the concern?
> >
> > -hadriel
> >
> >
> > > From: Rohan Mahy [mailto:[email-masked]]
> > > Sent: Tuesday, July 31, 2007 12:04 PM
> > > To: Michael Thomas
> > > Cc: Rohan Mahy; IETF SIP List; Francois Audet;
> > > [email-masked]; Paul Kyzivat
> > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
> > >
> > > Michael,
> > >
> > > The semantics of a request to a sip: resource are different from a
> > > request to a sips: resource.  If there are no Contacts registered
> > > against a sips: resource, then the correct thing for the
> > proxy to do
> > > is to send a 480.  This is the same thing the proxy would
> > do if there
> > > were no Contacts registered against a sip: resource.
> > >
> > > We are not talking about a ciphersuite downgrade here. Providing an
> > > error response code that encourages a client to downgrade is just
> > > plain irresponsible.
> > >
> > > thanks,
> > > -rohan
> > >
> > >
> > > On Jul 27, 2007, at 9:39 AM, Michael Thomas wrote:
> > > > Rohan Mahy wrote:
> > > >> Michael,
> > > >>
> > > >> At issue here is what the default implementor is likely to do.
> > > >> With a new 4xx, the misguided but well-meaning implementor is
> > > >> likely to try to "helpfully" "repair" the error without thinking
> > > >> about or understanding the security context.
> > > >>
> > > >> Using a Warning code raises the bar significantly, but
> > still allows
> > > >> automata to at least log what happened.
> > > > As I said, a receiver is completely at liberty to prevent the
> > > > downgrade by not accepting the downgraded request.
> > Problem solved
> > > > by those who care. On the other hand I think it's pretty
> > > > presumptuous that we "know" in all cases whether it's wrong to
> > > > "repair" the error. Paul brought up several examples.
> > > > Also: if the receiver allows non-SIPS requests why shouldn't you
> > > > infer that they want you to "repair" the request? It sure
> > seems like
> > > > this is a misguided attempt at forcing ineffectual
> > nannyware which
> > > > is a pointless enterprise for IETF protocols.
> > > >
> > > >       Mike
> > >
> > >
> > >
> > > This list is for NEW development of the core SIP Protocol Use
> > > [email-masked] for questions on current sip Use
> > > [email-masked] for new developments on the application of sip
> >
> >

---

From: Michael Thomas <[email-masked]>
Date: Wed, 01 Aug 2007 04:25:22 -0700

Rohan Mahy wrote:
> The resource that was requested (sips:[email-masked]) is NOT 
> available.  There may be a related but different resource available, 
> so it is nice as a courtesy to provide this information, but the basic 
> semantics should still be a 480.

The proposal out which had the two different warning codes alleviates
my concern which is that the implementor who doesn't much care about
IETF nanny proclamations has incentive to pay attention to them so that
it doesn't make _useless_ re-requests for SIP:.

Question: as currently defined can these two new warnings be reused by
any future method that is hopefully more secure than SIPS so that we don't
have to rehash this argument again?

       Mike
>
> thanks,
> -rohan
>
>
> On Jul 31, 2007, at 2:25 PM, Hadriel Kaplan wrote:
>
>>> against a sips: resource, then the correct thing for the proxy to do
>>> is to send a 480.  This is the same thing the proxy would do if there
>>>>> Using a Warning code raises the bar significantly, but still
>>>>> allows automata to at least log what happened.
>>>> downgrade by not
>>>> accepting the downgraded request.  Problem solved by those who
>>>> care. On
>>>> the other hand I think it's pretty presumptuous that we "know" in
>>>> all cases
>>>> whether it's wrong to "repair" the error. Paul brought up several
>>>> examples.
>>>> infer that
>>>> they want you to "repair" the request? It sure seems like this is a
>>>> misguided
>>>> attempt at forcing ineffectual nannyware which is a pointless
>>>> enterprise for
>>>> IETF protocols.
>>>>
>>>>       Mike
>>>
>>>
>>>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 1 Aug 2007 10:43:38 -0500

Ok, cool. 

> Sent: Tuesday, July 31, 2007 22:23
> To: Audet, Francois (SC100:3055)
> Cc: 'IETF SIP List'
> Ahh - no what I missed was that you were giving a specific 
> warning code for the 480 such that a machine can 
> automatically warn the user and retry, disambiguating it from 
> a generic 480.  That's cool for me.  I thought the options 
> were either an ambiguous 480 or explicit 418, but it's now an

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 1 Aug 2007 10:55:48 -0500

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 04:25
> To: Rohan Mahy
> Cc: Hadriel Kaplan; 'IETF SIP List'; Audet, Francois 
> (SC100:3055); [email-masked]; 'Paul Kyzivat'
> Question: as currently defined can these two new warnings be 
> reused by any future method that is hopefully more secure 
> than SIPS so that we don't have to rehash this argument again?

The draft uses the Warn-codes in 480. But it could be used
by other response (e.g., 424 for location conveyance, if we
decide it makes sense). Or any other response.

I'm assuming you mean "other URI schemes" instead of "other
methods".

I currently have it as follows:

   380  SIPS Not Allowed

   381  SIPS Required

So, obviously, they are tied to SIPS. 

If we defined another URI scheme (e.g., sipsec or whatever), then it
would probably need new Warning Codes.

The alternative, which I presented in Chicago, based on Attila's
proposal
(i.e., defining a new header that specifically list the Allowed or
Required 
URI schemes) was NOT viewed favorably by the group.

---

From: "Attila Sipos" <[email-masked]>
Date: Wed, 1 Aug 2007 22:04:56 +0100

by the way what were the objections?
just curious.
 
Regards,
 
Attila

________________________________

From: Francois Audet [mailto:[email-masked]]
Sent: Wed 01/08/2007 16:55
To: Michael Thomas
Cc: IETF SIP List
Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418

   380  SIPS Not Allowed

   381  SIPS Required

---

From: "Attila Sipos" <[email-masked]>
Date: Thu, 2 Aug 2007 08:38:04 +0100

>>Basically, a large number of people wanted the error to NOT be explicit, and allow "downgrades". 
 
I still don't get it.
In a similar scenario, if you're using a web browser then the user will know
what sites are secure because of the padlock icon.  When diverted away
from a secure site (automatically) the user can see the padlock disappears.
And in some cases, the browser will display a message to tell the user
that the connection is no longer secure.
 
I don't see why the equivalent thing can't be done in SIP/SIPS.
The security (or lack of) doesn't matter provided the user is informed.
It should be up to the user to decide if they want to allow a downgrade,
not the protocol specification.   I agree that a bad implementor could do
the downgrade secretly but, for me, this is no different to a bad web browser
which doesn't tell you about the security level - you simply wouldn't choose
to use such a browser.
 
I know SIP and HTTP are different but I can't see the difference
in this case.
 
Regards,
Attila

From: Francois Audet [mailto:[email-masked]]
Sent: Wed 01/08/2007 22:19
To: Attila Sipos
Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418

Basically, a large number of people wanted the error to NOT be explicit, and allow "downgrades". 
 
The use of the Warning is a compromise for them. The idea being that most people will ignore the warning and just fail the call, unless they really know what they are doing.

	From: Attila Sipos [mailto:[email-masked]] 
	Sent: Wednesday, August 01, 2007 14:05
	To: Audet, Francois (SC100:3055); Michael Thomas
	Cc: IETF SIP List
	Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418

	Regards,
	 
	Attila

	

	

	   380  SIPS Not Allowed
	
	   381  SIPS Required

---

From: Alan Hawrylyshen <[email-masked]>
Date: Fri, 27 Jul 2007 10:26:40 -0500

On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote:

> I understand that if the user entered a sips URI then it should be  
> the user that must decide to downgrade. But if the user didn't know  
> whether to use sip or sips in the first place, and the UA decides  
> to try sips first then I see no problem in the UA having a policy  
> that causes it to downgrade.

I was under the impression (based on meeting discussion) that :
1 - the downgrade was undesirable because it reveals (possibly)  
information about the targeted party in the clear, and;
2 - The 480 with a Warning header was an option to provide automata- 
friendly indication of the failure reason.

Alan Hawrylyshen

a l a n a t p o l y p h a s e d o t c a

---

From: Alan Hawrylyshen <[email-masked]>
Date: Fri, 27 Jul 2007 10:26:40 -0500

I was under the impression (based on meeting discussion) that :
1 - the downgrade walicies are policies that are created
>    independent of a session and generally apply to all sessions a user
>    agent is setting up.  They typically remain stable for a longer
>    period of time and apply to any session set up while they are valid.
>    However, session-independent policies may also change over time. For
>    example, a policy that defines a bandwidth limit for a user may
>    change during the day, defining a lower limit during peak hours and
>    allow more bandwidth off-peak.
> 
> Change "may" --> "can" twice.
> 
> 8)	Section 3.1
> 
>    A SIP UA may receive session-independent policies from one or more
>    policy servers.  In a typical configuration, a UA receives session-
>    independent policies from a policy server in the access or local
>    network domain (i.e. the domain from which the UA receives IP
>    service) and possibly the home network domain (i.e. the domain the UA
>    registers at).  The local network may have policies that support the
>    access network infrastructure.  For example, in a wireless network
>    where bandwidth is scarce, a provider may restrict the bandwidth
>    available to an individual user.  The home network may have policies
>    that are needed to support services or policies that reflect the
>    service level agreement with the user.  Thus, in most cases, a UA
>    will receive session-independent policies from one or two policy
>    servers.
> 
> Change "may" --> "can" three times.
> 
>    2.  The policy server selects the policies that apply to this user
>        agent.  The policy server may have general policies that apply to
>        all users or maintain separate policies for each individual user.
>        The selected policies are returned to the user agent.
>    3.  The policy server may update the policies, for example, when
>        network conditions change.
> 
> Change "may" --> "can" twice.
> 
> 9)	Section 3.2:
> 
>    A change in the policy may be triggered, for
>    example, by a change in the network status, by the change in the time
>    of day or by an update of the service level agreement with the
>    customer.
> 
> Change "may" --> "can"
> 
> 10)	Section 4:
> 
>    Session-specific policies are policies that are created specifically
>    for one particular session of a UA.  Thus, session-specific policies
>    will typically be different for different sessions.  The session-
>    specific policies for a session may change during the course of the
>    session.  For example, a user may run out of credit during a session,
>    which will cause the network to disallow the transmission all media
>    streams from this point on.
> 
> Change "may" --> "can" twice.
> 
> 11)	Section 4.1:
> 
>    The policy server is a separate logical entity that may be physically
>    co-located with the proxy.  The role of the policy server is to
>    deliver session policies to UAs.  The policy server receives session
>    information from the UA, uses this information to determine the
>    policies that apply to the session and returns these policies to the
>    UA.  The mechanism for generating policies (i.e. making policy
>    decisions) is outside of the scope of this specification.  A policy
>    server may, for example, query an external entity to get policies or
>    it may directly incorporate a policy decision point and generate
>    policies locally.
> 
> Change "may" --> "can" three times.
> 
> And in the same section:
> 
>    A UA receives the URI of a policy server from a proxy.  It uses this
>    URI to contact the policy server.  It provides information about the
>    current session to the policy server and receives session policies in
>    response.  The UA may also receive policy updates from the policy
>    server during the course of a session.
> 
> Change "may" --> "can"
> 
>    A network may have a policy enforcement infrastructure in place.
>    However, this specification does not make any assumptions about the
>    enforcement of session policies and the mechanisms defined here are
>    orthogonal a policy enforcement infrastrucs undesirable because it reveals (possibly)  

Alan Hawrylyshen

ture.  Their goal is to
>    provide a mechanism to convey session information to a policy server
>    and to return the policies that apply to a session to the UA.
> 
> Change "may" --> "can"
> 
> 12)	Section 4.2:
> 
>    In many cases, the mechanism for session-specific policies will be
>    used to disclose session information and return session policies.
>    However, some scenarios may only involve the disclosure of session
>    information to a network intermediary.  If an intermediary does not
>    intend to return a policy, it can simply accept the session as it was
>    proposed.  Similarly, some session-specific policies only apply to
>    the offer (and therefore only require the disclosure of the offer)
>    whereas others apply to offer and answer.  Both types of policies are
>    supported by session-specific policy mechanism.
> 
> Change "may" --> "can"
> 
> 13)	Section 4.4.1:
> 
>    A UAC may receive a 488 response that contains a Policy-Contact
>    header field.
> 
> Change "may" --> "can"
> 
>    The token is an opaque
>    string the UAC may have received from the policy server after
>    contacting it.
> 
> Change "may" --> "can"
> 
>       Note: it has been proposed to use the Policy-Id header to provide
>       a hint for a proxy that the UAC has actually contacted the policy
>       server.  This usage also requires the policy server to return a
>       token to the UA.  In addition, the policy server needs to share
>       valid tokens with the proxy.  After receiving a request with a
>       Policy-Id header, the proxy can determine if the token in the
>       Policy-Id header is valid.  If it is valid, the proxy knows that
>       the UA has contacted the policy server for this session.  However,
>       it is important to note that this token does not provide any proof
>       that the UA has actually used the policies it has received from
>       the policy server.  A malicious UA may simply contact the policy
>       server, discard all policies it receives but still use the token
>       in the Policy-Id header.
> 
> Change "may" --> "can"
> Delete: "it is important to note that".
> 
>    In some cases, a request may traverse multiple domains with session-
>    policies in place.  Each of these domains may return a 488 response
>    containing a policy server URI.
> 
> Change "may" --> "can" twice.
> 
>    A UA may decide to change the session description of a session and to
>    initiate subsequent offer/answer exchanges (e.g. using INVITE, UPDATE
>    or PRACK requests) to re-negotiate the session description. 
> 
> Change "may" --> "can"
> 
> 14)	Section 4.4.2:
> 
>    If the local policy server URI is present in a Policy-Id header value
>    of a request, then the proxy MUST NOT reject the request as described
>    above (it may still reject the request for other reasons).
> 
> Change "may" --> "can"
> 
> 15)	Section 4.4.3:
> 
>    A UAS may receive an INVITE, UPDATE or PRACK request (or another
>    request that can initiate offer/answer exchanges), which contains a
>    Policy-Contact header filed with a list of policy server URIs.
> 
> Change "may" --> "can"
> 
>    A UAS may receive a token from a policy server via the policy
>    channel.  Since the UAS does not create a Policy-ID header, it can
>    simply ignore this token.
> 
> Change "may" --> "can"
> 
> 16)	Section 4.4.4:
> 
>    A UAC may frequently need to contact the policy server in the local
>    domain before sending a request.  To avoid the retransmission of the
>    local policy server URI for each new request, a UA SHOULD maintain a
>    cache that contains the URI of the local policy server.  A UA may
>    receive this URI in a Policy-Contact header of a request or a 488
>    response.  The UA may also receive the local policy server URI
>    through configuration, for example, via the configuration framework
>    [4].  If a UA has received a local policy server URI through
>    configuration and receives another local policy server URI in a
>    Policy-Contact header, it SHOULD overwrite the configured URI with
>    the most recent one received in a Policy-Contact header.
> 
> Change "may" --> "can" three times.
> 
>    The UA SHOULD NOT cache policy server URIs it has received from
>    proxies outside of the local domain.  These policy servers may not be
>    relevant for subsequent sessions, which may go to a different
>    destination, traversing different domains.
> 
> Change "may not" to "need not"
> Change "may" --> "can"
> 
>    The UA MUST NOT cache tokens it may receive from a policy server.  A
>    token is only valid for one request.
> 
> Change "may" --> "can"
> 
> 17)	Section 4.4.6:
> 
>       Note: this assumes that the policy server can always respond
>       immediately to a policy request and does not require manual
>       intervention to create a policy.  This will be the case for most
>       policy servers.  If, however, a policy server cannot respond with
>       a policy right away, it may return a policy that temporarily
>       denies the session and update this policy as the actual policy
>       decision becomes available.  A delay in the response from the
>       policy server to the UA would delay the transmission of the ACK
>       and could trigger retransmissions of the INVITE response (also see
>       the recommendations for Flow I in [9]).
> 
> Change "may" --> "can"
> 
>    A UA MUST inform the policy server when a session is terminated via
>    the policy channel.  This enables a policy server to free all
>    resources it may have allocated for this session.  A policy server
>    can indicate via the policy channel that it does not need to be
>    contacted at the end of a session.  In this case, the UA SHOULD NOT
>    inform the policy server about the termination of the session.
> 
> Change "may have" --> "has"
> 
> 18)	Section 4.4.7.1:
> 
>    The value of a Policy-Id header consists of a policy server URI.  A
>    Policy-Id header value may have an optional token parameter.  The
>    token parameter contains a token the UA may receive from the policy
>    server.  
> 
> Change "may have" --> "can have"
> Change "may receive" --> "received" 
> 
> 19)	Section 4.5:
> 
>    If the policy update causes a change in the session
>    description of a session, the UA may need to re-negotiate the
>    modified session description with its peer UA, for example, using a
>    re-INVITE or UPDATE request.
> 
> Change "may need" to "needs".
> 
> 20	Section 5:
> 
>    Session policies can significantly change the behavior of a user
>    agent and can be used by an attacker to compromise a user agent.  For
>    example, session policies can be used to prevent a user agent from
>    successfully establishing a session (e.g. by setting the available
>    bandwidth to zero).  Such a policy can be submitted to the user agent
>    during a session, which may cause the UA to terminate the session.
> 
> Change "may cause" to "causes".
> 
>    A user agent transmits session information to a policy server for
>    session-specific policies.  This session information may contain
>    sensitive data the user may not want an eavesdropper or an
>    unauthorized policy server to see.  For example, the session
>    information may contain the encryption keys for media streams.  Vice
>    versa, session policies may also contain sensitive information about
>    the network or service level agreements the service provider may not
>    want to disclose to an eavesdropper or an unauthorized user agent.
> 
> Change "may contain" to "can contain" twice
> Change "may not" to "does not" twice
> Change "may also" to "can also"
> 
>    This would impede the rendezvous between UA and policy server and,
>    since the UA would not contact the policy server, may prevent a UA
>    from setting up a session.
> 
> Change "may" to "can"
> 
>    Policy servers SHOULD authenticate UAs to protect the information
>    that is contained in a session policy.  However, a policy server may
>    also frequently encounter UAs it cannot authenticate. 
> 
> Change "may" to "can"

---

From: Alan Hawrylyshen <[email-masked]>
Date: Fri, 27 Jul 2007 10:26:40 -0500

Alan Hawrylyshen

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 2 Aug 2007 10:14:08 -0500

Again, you are correct.

It seems that we have been in a circular argument on this list for a
while. The same old
arguments keep coming back.

Basically we have 3 groups of people:

1 - People who prefer the response to be very explicit (e.g., separate
error codes), and
    tell "what URI Scheme is acceptable".

2 - People who prefer the response to be a "hard failure" with no
explicit indication
    of the acceptable URI scheme provided, in order to not encourage
automatic 
    downgrades

3 - People who don't really care either way

The compromise that emerged from this is to use a single error code,
480, which is the
error used when the network cannot locate a contact for a particular
recognized AOR.
But, in addition, a Warning header field with one of 2 warn-codes is
provided, to indicate
the reason for the failure: SIPS Not Allowed or SIPS Required. This is
meant to provide
an indication to an Automata or an end user on the cause for the
failure. 

It has the benefit that existing implementations or "simple
implementations" will behave 
as desired, i.e, if they will treat it as a normal 480, and not harmful
downgrades occur.
So we achieve the goals of group 2 who want to avoid people shooting
themselves in the 
foot.

Implementations that want to provide further indications of what went
wrong will be able
to use the Warn-Code to provide an indication of the problem (for
end-user, network
administrator, etc.). So we achieve the goals of group 1.

It seems to me that this is a good solution. I'd really like to put an
end to this 
discussion and move on to something else. 

> From: Alan Hawrylyshen [mailto:[email-masked]] 
> Sent: Friday, July 27, 2007 08:27
> To: Kyzivat Paul; Mahy Rohan
> Cc: IETF SIP List; Audet, Francois (SC100:3055); 
> [email-masked]
> > I understand that if the user entered a sips URI then it 
> should be the 
> > user that must decide to downgrade. But if the user didn't know 
> > whether to use sip or sips in the first place, and the UA 
> decides to 
> > try sips first then I see no problem in the UA having a policy that 
> > causes it to downgrade.
> 
> 1 - the downgrade was undesirable because it reveals 
> (possibly) information about the targeted party in the clear, and;
> 2 - The 480 with a Warning header was an option to provide 
> automata- friendly indication of the failure reason.
> 
> Alan Hawrylyshen
> 
> [email-masked] for questions on current sip

---

From: Alan Hawrylyshen <[email-masked]>
Date: Thu, 2 Aug 2007 17:09:15 -0600

> discussion and move on to something else.

I find this proposal very acceptable for the reasons you already  
stated. Thanks François.
Perhaps this was something of a bike shed painting exercise[1] , I'm  
glad we are converging on a colour selection.

Alan

[1] http://ln-s.net/mva