Subject: Re: [cuss] Expert review of sip-uui-isdn draft underway

From: <[email-masked]>
Date: Thu, 5 Jan 2012 18:04:10 +0100

Hello and Happy New Year,

Please find our comments on draft-ietf-cuss-sip-uui-isdn-01:

**Section 3.1**
C1: "to control the request and granting of the service, as in USS2 and UUS3" => just an editorial comment, "USS2" should be replaced by "UUS2".

C2: "Only a single user information package can be transported in each message" => in order to avoid any misunderstanding, it would be clearer to indicate that this restriction concerns "isdn-uui" package, so it would be in-line with section 6 where this precision is given and with section 5 where another package could be used (enhanced package) in parallel with "isdn-uui". Otherwise, without this clarification, it could be understood as no other package is allowed.
Proposal: "Only a single user information package set to "isdn-uui" can be transported in each message".

**Section 5**
C3: "the endpoint can carry the UUI data both as ISDN and as some other package in parallel" => it would be suitable to explicitly indicate that ISDN UUI and other types of UUI using other packages are conveyed either in the same or in different messages.

Proposal: "the endpoint can carry the UUI data both as ISDN UUI and as other types of UUI defined in other packages, in parallel in the same or in different messages".

**Section 7**
C4: "The UAC MUST only use this package of the UUI mechanism extension in association with the initial INVITE method and the BYE method relating to an INVITE dialog. Usage on transactions associated with any other type of dialog, or on methods not associated with a dialog is precluded." => The first sentence indicates that User-to-User header can only be conveyed in initial INVITE request, its responses, BYE request and its responses (which is consistent with the definition of UUS1) whereas the scope of the second sentence is wider because it means that other methods within the INVITE-initiated dialog (e.g. UPDATE) can be used to convey UUI, although only initial INVITE and BYE methods are allowed.
Proposal: "The UAC MUST only use this package [...]. Usage on transactions associated with any other type of dialog, or on methods not associated with a dialog, or on methods related to an INVITE dialog but different from initial INVITE or BYE methods is precluded."

C5: "If the UAC wishes to user or permit the sending of UUI data at any point in the dialog, the UAC MUST include in the INVITE request for that dialog a User-to-User header field with an "package" header field parameter set to "isdn-uui". This initial header field constitutes the implicit request to use the UUI service, and is therefore included even when there is no data except the protocol discriminator octet to send at that point in time." => the use of User-to-User header even with no uui data in INVITE request for implicit request should be a possibility but not a requirement since the uui option tag has been created for that purpose and allows as well to declare and negotiate the uui capacity.
Proposal: replace "MUST" by "MAY" in the above sentences.

C6: "The UAC MUST NOT include the User-to-User header field with an "package" header field parameter set to "isdn-uui" in any message of an INVITE dialog if the original INVITE request did not include the User-to-User header field with an "package" header field parameter set to "isdn-uui".") => it should be allowed to include a User-to-User header even if no User-to-User header was present in INVITE request since the negotiation of the uui capacity can be done by uui option tag instead.
Proposal: replace "MUST" by "MAY" in the above sentence.

C7: "Because for the ISDN UUI service, the service is service 1 implicit, the inclusion of the "uui" option tag in a Supported header field conveys no additional information over and above the presence of the User-to-User header field with the "package" header field parameter to "isdn-uui" in the INVITE request. 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" => it should be possible, in order to declare/negotiate the uui capability, to use the uui option tag instead of the inclusion of User-to-User header even with no uui data, at least by indicating both possibilities.
Proposal: "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 when User-to-User header is included in INVITE request for implicit request. Otherwise, the uui option tag is used to indicate that a UA supports and understands the User-to-User header field."

C8: "When sending UUI for the ISDN package, the UAS MUST set the User-to-User "package" header field parameter to "isdn-uui" and "When receiving UUI, when a User-to-User header field is received in a request that is not from the originating user with the "package" header field parameter to "isdn-uui", the UAC MUST discard this header fields." => this requires the presence of package parameter (with value set to "isdn-uui"). In order to be consistent with draft-ietf-cuss-sip-uui-04 ("If the "package" parameter is not present, interworking with the ISDN UUI Service MUST be assumed"), it would be necessary to add that when package parameter is not present, its default value "isdn-uui" must be assumed.
Proposal (in reception): "When receiving UUI, when a User-to-User header field is received in a request that is not from the originating user with the "package" header field parameter to "isdn-uui", the UAC MUST discard this header fields. When receiving UUI, if no package header field parameter is present, the UAC must assume its default value "isdn-uui"".
Proposal (in emission): "When sending UUI for the ISDN package, if the UAS includes a User-to-User "package" header field parameter, it MUST set it to "isdn-uui".

C9: As done in Section 8 for UAS, it would be relevant to indicate the behavior of the UAC when a User-to-User header field is received in a response that is not with the "package" header field parameter to "isdn-uui" (discarded?).

**Section 8**
C4, C6 and C8 comments are also applicable in this section.

**Section 13**
C10: "This document adds the following row to the "UUI packages" sub-registry of the SIP parameter registry: Value: isdn-uui" => it would be suitable to rename the value of package parameter from "isdn-uui" into "isdn-interwork". The goal would to allow compatibility with already deployed implementations that are based on the draft-johnston individual draft (draft referenced since a long time in 3GPP documents). There would be no change regarding the meaning because the definitions of "isdn-interwork" and "isdn-uui" values are exactly the same, for ISDN interworking scenarios ("which is to interoperate with ISDN User to User Signaling (UUS)").

Regards,

Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Vijay K. Gurbani
Envoyé : jeudi 15 décembre 2011 17:15
À : [email-masked]
Objet : [cuss] Expert review of sip-uui-isdn draft underway

Folks: Celine Serrutvalette has agreed to perform an expert review of
the UUI ISDN draft (thanks, Celine).

The expert review is due Jan-10-2012.

The token for a second expert review of the SIP mechanism draft is
with Martin Dolly.

I suspect that once both these expert reviews are in, Enrico and I
will ask the editors to modify their respective drafts and proceed
to WGLC.

Until then, y'all have a nice holiday season.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
cuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss