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

[<[e-mail]>]

Hello,

Yes you're right the draft "sip-uui-isdn-04" does reflect what the mechanism "sip-uui-06" is defining since "sip-uui-isdn-04" has been updated with "purpose" parameter name instead of "package" as defined in the generic draft (the value of the parameter for ISDN interworking is not defined in the generic draft but in the ISDN one).
Now "sip-uui-isdn-04" is modified with the parameter name, the next step would be the change of the parameter value (actually this comment C10 makes sense once the parameter name is "purpose", it has no sense when the parameter name was "package", that's why I didn't raise it again before.). 

Regards,

Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] 
Envoyé : mardi 22 mai 2012 09:08
À : SERRUT-VALETTE Celine RD-CORE; [e-mail]
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : AW: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04

Hi,
When I went through the discussion. I found the last comment on issue C10 that with the following statement:

> > **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)").
> >
>
> This is driven directly from the mechanism draft, so I will follow
> whatever it states there.

So my conclusion was that the draft itself "sip-uui-isdn-04" does reflect what the mechanism sip-uui-06 is defining. No more comments were made which were following up that issue.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]]
Gesendet: Montag, 21. Mai 2012 16:22
An: [e-mail]
Cc: Jesske, Roland; [e-mail]; [e-mail]; [e-mail]
Betreff: RE: [cuss] WGLC for sip-uui-06 and sip-uui-isdn-04

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.