Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt

["Milan Patel" <milanpa at nortel.com>]

Folks,

In response to Gonzalo's comment on backwards compatibility, I propose a
subclause "4.3 Backwards compatibility issues" as follows:

------------------------------------------------------------------------
----------------------------------
4.3	Backwards compatibility issues
The backwards compatibility scenario considered in this document is
where the registrar does not support the "sos" URI parameter. In this
case, if the registrar receives a REGISTER request that includes the
"sos" URI parameter in the Contact header, the registrar MUST proceed
with registration procedures and silently ignore the URI-parameter in
accordance with RFC 3261. This ensures the user is registered and thus
can successfully initiate an emergency call.

The drawback of proceeding with registration is if the address-of-record
is barred or has roaming restrictions applied, then these restrictions
will not be lifted and thus registration will be unsuccessful. This may
limit the UAC's ability to successfully place an emergency call.

If registration is successful, the registrar shall return a 200 (OK)
response to the UAC and does not include the "sos" URI parameter in the
Contact header. The UAC is aware of its registered contact address and
address-of-record, however, cannot distinguish between this registration
and a non-emergency registration.
------------------------------------------------------------------------
--------------------------------------

Comments/feedback/suggestions for improvement are appreciated. I will
address Gonzalo's other comments in version -04 of the draft as well. 

Best regards,
Milan

Milan Patel
Carrier Networks Core Standards
Nortel
milanpa at nortel.com
Telephone +44 162 843 2381 / ESN 560 2381
Mobile +44 774 053 9261 / ESN 748 9261

For the Companies listed below, The Institute of Chartered Accountants
in England and Wales authorises A R Bloom, S Harris and C Hill to act as
Insolvency Practitioners under section 390(2)(a) of the Insolvency Act
1986 and the Association of Chartered Certified Accountants authorises A
M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of
the Insolvency Act 1986.

The affairs, business and property of the Companies are being managed by
the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who
act as agents of the Companies only and without personal liability.

The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel
GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks
SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks
Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel
Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel
Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL;
Nortel Networks AB; Nortel Networks International Finance & Holding BV

-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
Of Gonzalo Camarillo
Sent: 19 February 2009 13:57
To: ecrit at ietf.org
Subject: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt

Folks,

I have been asked to perform an expert review of the following draft:

http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt

The approach taken by the draft seems OK in general. I have a few
comments though:

The requirement in Section 3 is too specific because it already assumes
that the solution will be an indication in the SIP header fields. The
requirement does not need to make that assumption. I would remove "by
providing an appropriate indication in the SIP header fields".

In Section 5, the reference to RFC 2234 should be replaced with one to
RFC 5234.

Also in Section 5, the formal syntax should be rewritten so that it is
compatible with the ABNF in RFC 3261. RFC 3261 already defines
uri-parameter as follows:

   uri-parameter   =  transport-param / user-param / method-param
                      / ttl-param / maddr-param / lr-param / other-param

   other-param       =  pname [ "=" pvalue ]
   pname             =  1*paramchar
   pvalue            =  1*paramchar

This document should simply define a new value for pname.

The document does not talk about backwards compatibility. What happens
if the registrar does not understand the 'sos' parameter? Will it do the
right thing? Will the UAC detect the failure? Is there a need to define
an option tag?... the document should address these points.

Cheers,

Gonzalo

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit