Re: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04

[<[e-mail]>]

Hello,

Related to GENERAL points 2 and 3, to follow the change of parameter name and in order to ensure backward compatibility to early implementations based on earlier drafts (e.g. draft-johnston-sipping-cc-uui-08) on which several implementations are based, could you rename the value of "purpose" parameter from "isdn-uui" to "isdn-interwork" (see http://www.ietf.org/mail-archive/web/cuss/current/msg00355.html, comment C10)? Indeed, the meaning of both values is the same and the value is defined for ISDN interworking purpose ("for interworking with the ISDN user-to-user service" in Section 13), therefore "isdn-interwork" is a relevant value for "purpose" parameter and in addition it would allow backward compatibility. 

Please find also a minor comment in Section 13 ("This document adds the following row to the "UUI packages" sub-registry of the SIP parameter registry"), it seems that "UUI packages" should be replaced by "UUI purpose" as it gives the parameter value which is registered to IANA for ISDN interworking.

Regards,

Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de [e-mail]
Envoyé : lundi 21 mai 2012 13:34
À : [e-mail]; [e-mail]; [e-mail]
Objet : Re: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04


 Dear all,
I was asked to review the draft sip-uui-isdn-04. The draft itself is in a good shape and I propose to move forward in the process approval.


Here are my comments in detail:

GENERAL:
1. The draft is applicable for the intended scope of the document which covers the interworking with both public ISDN and private ISDN capabilities. The aspects of QSIG probably stated.

2. All points of discussion on email list and meetings are reflected probably. This includes one of the main discussion point, the name change "package" to "purpose".

3. Backward compatibility to early implementations based on earlier drafts are given. The appearance of the header fields "content" and "encoding" is optional.

4. I wonder if a sentence for ISUP User-to-User transport and interworking would help to understand that the ISUP interworking behavior is the same as for ISDN. (For me it is clear)
Text could look like: ISUP itself transports transparently the ISDN User-to-User Information element. The interworking of ISUP with SIP applies with the same rules as for ISDN due to the fact that ISUP itself transports transparently the ISDN User-to-User Information element.



DETAIL:
1.
Section "3.1.  The service"

For DSS1, this is
   specified in ITU-T Recommendation Q.931 section 3.3 and section 7
   [Q931].

I would propose to add an additional reference to  Q.931 Section  4.5.30 where the User-user information element is defined. This helps the interested reader of Q.931 to find also the related protocol element.

Proposed Text:

For DSS1, this is
   specified in ITU-T Recommendation Q.931 section 3.3, 4.5.30 and section 7
   [Q931].

2.
Section "9.  UUI contents"

I have some problems with the wording "...the sending SIP entity MAY, but need not, include ..." There is not a direct guidance for implementation.
I think we should use some more recommendatory  wording. Like "...it is "RECOMMENDED" that the sending SIP entity include a..."
or "...it is "OPTIONAL" that the sending SIP entity include a..."
To show that the element is not needed an additional sentence is added to show the behavior of the receiving entity: "A receiving SIP entity accepts a received User-to-User header field if the
   "xxx" header field parameter is set to "xxx" or is absent.

Proposals:
Replace:

   The default and only content defined for this package is "isdn-uui".
   When sending UUI, the sending SIP entity MAY, but need not, include a
   "content" header field with a value set to "isdn-uui".  A receiving
   SIP entity MUST ignore a received User-to-User header field if the
   "content" header field parameter is present and the value is some
   other value that "isdn-uui".
With:
   The default and only content defined for this package is "isdn-uui".
   When sending UUI, it is "RECOMMENDED" that the sending SIP entity include a
   "content" header field with a value set to "isdn-uui".  A receiving
   SIP entity MUST ignore a received User-to-User header field if the
   "content" header field parameter is present and the value is some
   other value that "isdn-uui".
A receiving SIP entity accepts a received User-to-User header field if the
   "content" header field parameter is set to "isdn-uui" or is absent.


Replace:
   The default and only encoding defined for this package is "hex".
   When sending UUI, the sending SIP entity MAY, but need not, include
   an "encoding" header field with a value set to "hex".  A receiving
   SIP entity MUST ignore a received User-to-User header field if the
   "encoding" header field parameter is present and the value is some
   other value that "hex".
With:
   The default and only encoding defined for this package is "hex".
   When sending UUI, it is "RECOMMENDED" that the sending SIP entity include
   an "encoding" header field with a value set to "hex".  A receiving
   SIP entity MUST ignore a received User-to-User header field if the
   "encoding" header field parameter is present and the value is some
   other value that "hex".
A receiving SIP entity accepts a received User-to-User header field if the
   "encoding" header field parameter set to "hex" or is absent.



EDITORIAL:

1.
Section "3.1.  The service"

...   The above come from the ISDN specifications defined for public
   networks.  There are a parallel set of ISDN specifications defined
   for private networks (QSIG}.  ...
Wrong bracket

2.
Page 5 2nd paragraph  2nd sentence: spelling --  descriminator  --> discriminator

3.
Section "7.  UAC requirements"


Replace should--> SHOULD
   While there is no harm in including the "uui" option tag, and
   strictly it should be included if the extension is supported, it
   performs no function.
Replace by:
   While there is no harm in including the "uui" option tag, and
   strictly it SHOULD be included if the extension is supported, it
   performs no function.

4.
Section "8.  UAS requirements" last paragraph last sentence.
I would add an originally. So that the sentence read:

There are no mechanisms for determining which was the originally intended data packet so all are discarded.

I hope this helps.

Thank you

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von Vijay K. Gurbani
Gesendet: Samstag, 5. Mai 2012 20:26
An: [e-mail]
Betreff: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04

All: Enrico and I will like to issue a WGLC for the two drafts that constitute the remaining of our chartered work.  These drafts have been revised post-Paris IETF based on the discussion in Paris and subsequent ratification on the mailing list.

The two drafts are:

draft-ietf-cuss-sip-uui-06
   (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-06)
draft-ietf-cuss-sip-uui-isdn-04
   (http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-04)

The WGLC expires on May 27, 2012.

We are looking for volunteers to perform WGLC on each of these documents.  Please let me and Enrico know as soon as you can if you are able to help out.

Thank you,

Vijay K. Gurbani and Enrico Marocco
_______________________________________________
cuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cuss
_______________________________________________
cuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cuss