On 8/19/13 3:44 PM, Daniel-Constantin Mierla wrote:

On 8/19/13 10:23 PM, Peter Saint-Andre wrote:

On 8/19/13 2:02 PM, Paul Kyzivat wrote:

On 8/16/13 10:28 PM, Peter Saint-Andre wrote:

The SIP Parameters Registry has a list of SIP response codes:

http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-7

A number of those are not specified in RFC 3261. Thus the question
arises: for which codes do we need to define mappings? We could define
mappings for all of them, but I wonder if that's advisable. Some of the
additional codes are specified in RFCs that update RFC 3261 (e.g., code
440 from RFC 5393), whereas other codes are specified in "non-core"
RFCs
that don't update RFC 3261 (e.g., code 470 from RFC 5360). Would it
perhaps make sense to map the "core" codes and not the "non-core"
codes?

I know this is almost a non-answer, but...

The codes that are defined in other RFCs are there to support features
that are introduced in those RFCs. If there is a mapping of that feature
to XMPP, then there should be a mapping of the code.

That makes sense.

If there is no mapping of the feature, then mapping the code is less
important, but still perhaps useful in some cases. E.g., it could
conceivably show up in a Reason code based on signaling that was never
gatewayed to xmpp. But maybe a default mapping would be sufficient in
those cases.

I suspect that the default mapping would be fine.

And in general, there might be more art than science here.

I have written some proposed text for this section, but it's fairly long
so my inclination is to submit a revised I-D and then folks can review
what I've written and post to the list with feedback.

Looking at the latest draft, it seems to bring confusion on mapping from
xmpp-to-sip on 400 code. I read this thread and kind of understood that
any not-obvious-mapping similar-to-a-4xx case would be handled same as
400 in SIP, but typically the 400 response is given for a malformed sip
requests (like broken grammar).

So your suggestion is that we avoid mapping XMPP error conditions to SIP
400 unless the XMPP condition is caused by a malformed request?

After quick read, <conflict/> would map more suggestively to 403
Forbidden. 

As I said, it's perhaps more art than science. But mapping <conflict/>
to 403 seems reasonable if we accept your suggestion about not mapping
to 400 unless we have a good reason to do so.

Maybe <policy-violation> and <undefined-condition/> could get
other mappings as well.

Well, depending on the policy being violated, <policy-violation/> might
map to 413, 414, 513, or even 406/606.

Given that <undefined-condition/> is something of a catch-all, it's not
clear to me what we'd map it to in a consistent way. That would probably
depend on the application-specific element contained in the error stanza.

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

On 8/19/13 3:44 PM, Daniel-Constantin Mierla wrote:

On 8/19/13 10:23 PM, Peter Saint-Andre wrote:

On 8/19/13 2:02 PM, Paul Kyzivat wrote:

On 8/16/13 10:28 PM, Peter Saint-Andre wrote:

The SIP Parameters Registry has a list of SIP response codes:

http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-7

A number of those are not specified in RFC 3261. Thus the question
arises: for which codes do we need to define mappings? We could define
mappings for all of them, but I wonder if that's advisable. Some of the
additional codes are specified in RFCs that update RFC 3261 (e.g., code
440 from RFC 5393), whereas other codes are specified in "non-core"
RFCs
that don't update RFC 3261 (e.g., code 470 from RFC 5360). Would it
perhaps make sense to map the "core" codes and not the "non-core"
codes?

I know this is almost a non-answer, but...

The codes that are defined in other RFCs are there to support features
that are introduced in those RFCs. If there is a mapping of that feature
to XMPP, then there should be a mapping of the code.

That makes sense.

If there is no mapping of the feature, then mapping the code is less
important, but still perhaps useful in some cases. E.g., it could
conceivably show up in a Reason code based on signaling that was never
gatewayed to xmpp. But maybe a default mapping would be sufficient in
those cases.

I suspect that the default mapping would be fine.

And in general, there might be more art than science here.

I have written some proposed text for this section, but it's fairly long
so my inclination is to submit a revised I-D and then folks can review
what I've written and post to the list with feedback.

Looking at the latest draft, it seems to bring confusion on mapping from
xmpp-to-sip on 400 code. I read this thread and kind of understood that
any not-obvious-mapping similar-to-a-4xx case would be handled same as
400 in SIP, but typically the 400 response is given for a malformed sip
requests (like broken grammar).

So your suggestion is that we avoid mapping XMPP error conditions to SIP
400 unless the XMPP condition is caused by a malformed request?

After quick read, <conflict/> would map more suggestively to 403
Forbidden. 

As I said, it's perhaps more art than science. But mapping <conflict/>
to 403 seems reasonable if we accept your suggestion about not mapping
to 400 unless we have a good reason to do so.

Maybe <policy-violation> and <undefined-condition/> could get
other mappings as well.

Well, depending on the policy being violated, <policy-violation/> might
map to 413, 414, 513, or even 406/606.
Given that <undefined-condition/> is something of a catch-all, it's not
clear to me what we'd map it to in a consistent way. That would probably
depend on the application-specific element contained in the error stanza.

21.4 Request Failure 4xx

   4xx responses are definite failure responses from a particular
   server.  The client SHOULD NOT retry the same request without
   modification (for example, adding appropriate authorization).
   However, the same request to a different server might be successful.
21.5 Server Failure 5xx

   5xx responses are failure responses given when a server itself has
   erred.
8.1.3.2 Unrecognized Responses

   A UAC MUST treat any final response it does not recognize as being
   equivalent to the x00 response code of that class, and MUST be able
   to process the x00 response code for all classes.  For example, if a
   UAC receives an unrecognized response code of 431, it can safely
   assume that there was something wrong with its request and treat the
   response as if it had received a 400 (Bad Request) response code.  A
   UAC MUST treat any provisional response different than 100 that it
   does not recognize as 183 (Session Progress).  A UAC MUST be able to
   process 100 and 183 responses.

It doesn't mean we should use 400,500,600 as generic codes, but treat unknown
the same way as we treat the even ones. If we receive 679, we should act as if
we received 600. 

Does jabber separate "server errors" and "request errors"?

/O
On 8/19/13 3:44 PM, Daniel-Constantin Mierla wrote:

On 8/19/13 10:23 PM, Peter Saint-Andre wrote:

On 8/19/13 2:02 PM, Paul Kyzivat wrote:

On 8/16/13 10:28 PM, Peter Saint-Andre wrote:

The SIP Parameters Registry has a list of SIP response codes:

http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-7

A number of those are not specified in RFC 3261. Thus the question
arises: for which codes do we need to define mappings? We could define
mappings for all of them, but I wonder if that's advisable. Some of the
additional codes are specified in RFCs that update RFC 3261 (e.g., code
440 from RFC 5393), whereas other codes are specified in "non-core"
RFCs
that don't update RFC 3261 (e.g., code 470 from RFC 5360). Would it
perhaps make sense to map the "core" codes and not the "non-core"
codes?

I know this is almost a non-answer, but...

The codes that are defined in other RFCs are there to support features
that are introduced in those RFCs. If there is a mapping of that feature
to XMPP, then there should be a mapping of the code.

That makes sense.

If there is no mapping of the feature, then mapping the code is less
important, but still perhaps useful in some cases. E.g., it could
conceivably show up in a Reason code based on signaling that was never
gatewayed to xmpp. But maybe a default mapping would be sufficient in
those cases.

I suspect that the default mapping would be fine.

And in general, there might be more art than science here.

I have written some proposed text for this section, but it's fairly long
so my inclination is to submit a revised I-D and then folks can review
what I've written and post to the list with feedback.

Looking at the latest draft, it seems to bring confusion on mapping from
xmpp-to-sip on 400 code. I read this thread and kind of understood that
any not-obvious-mapping similar-to-a-4xx case would be handled same as
400 in SIP, but typically the 400 response is given for a malformed sip
requests (like broken grammar).

So your suggestion is that we avoid mapping XMPP error conditions to SIP
400 unless the XMPP condition is caused by a malformed request?
After quick read, <conflict/> would map more suggestively to 403
Forbidden. 

As I said, it's perhaps more art than science. But mapping <conflict/>
to 403 seems reasonable if we accept your suggestion about not mapping
to 400 unless we have a good reason to do so.

Maybe <policy-violation> and <undefined-condition/> could get
other mappings as well.

Well, depending on the policy being violated, <policy-violation/> might
map to 413, 414, 513, or even 406/606.
Given that <undefined-condition/> is something of a catch-all, it's not
clear to me what we'd map it to in a consistent way. That would probably
depend on the application-specific element contained in the error stanza.

21.4 Request Failure 4xx

   4xx responses are definite failure responses from a particular
   server.  The client SHOULD NOT retry the same request without
   modification (for example, adding appropriate authorization).
   However, the same request to a different server might be successful.
21.5 Server Failure 5xx

   5xx responses are failure responses given when a server itself has
   erred.
8.1.3.2 Unrecognized Responses

   A UAC MUST treat any final response it does not recognize as being
   equivalent to the x00 response code of that class, and MUST be able
   to process the x00 response code for all classes.  For example, if a
   UAC receives an unrecognized response code of 431, it can safely
   assume that there was something wrong with its request and treat the
   response as if it had received a 400 (Bad Request) response code.  A
   UAC MUST treat any provisional response different than 100 that it
   does not recognize as 183 (Session Progress).  A UAC MUST be able to
   process 100 and 183 responses.

It doesn't mean we should use 400,500,600 as generic codes, but treat unknown
the same way as we treat the even ones. If we receive 679, we should act as if
we received 600. 

Does jabber separate "server errors" and "request errors"?

/O
-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

quoted-string  =3D  SWS DQUOTE *(qdtext / =
quoted-pair ) DQUOTE
      qdtext         =3D  LWS / %x21 / %x23-5B / %x5D-7E
                        / UTF8-NONASCII
The text in the draft can be parsed =
to say this, but I would like it to be more clear and add the UTF-8 =
acronym, so it's clear that it's just transcoding - quoting - but not =
translating or stripping.
I would also like to mention that Contacts can =
include display names, like "Olles superduperphone" or "Conference Room =
Jupiter Phone". I don't know if this can be translated into =
XMPP.
Yes, this is an art form :-)
I notice that 407/401 is translated =
to different things. I would propose that we always translate to 401 or =
that we add both 401/407 to the entries <not-authorized>, =
<registration-required/> and <subscription-required/>. =
<
<policy-violation/> should be =
translated to 403 Forbidden
<redirect/> to 300 Multiple Choices may =
be correct, but I would prefer a 302 or 301. I haven't seen many =
implementations of 300 for redirects, but many using good old =
302.
<remote-server-not-found/> with a translation to 502 =
is maybe not fully wrong, but in real life if the DNS entry is there and =
we can't reach the server, a 408 is sent. If there's no DNS entry at =
all, a 404 will be sent. Depends a bit on the meaning of this XMPP error =
code.
Section 6.2. =
table 3
Section 8
I'm happy to =
see loop detection, but I think we need a way to transport the values =
across XMPP for the case we have SIP -> XMPP -> SIP
We don't want =
to loop around or fork in crazy ways in such a network. I can create =
such a loop easily with Asterisk today. People will end up building this =
kind of gateway constructs. I don't think we can say "that's not what we =
intend" since it will happen and possibly already is in use out there. =
It may be something for another draft, but it will have to be approached =
at some point.
/O