Re: Initial WG review: draft-johnston-sipping-cc-uui-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Title: Initial WG review: draft-johnston-sipping-cc-uui-06
Keith,
 
You raise an interesting point here. The immediate need of the industry so far as I know
is only for the implicit service.
 
Others can respond if they feel a need to have explicit functionality and the resulting response code/procedures
defined here for this first RFC. My guess is that we do not need it and should just
state that up front as beyond scope. I have not seen explicit support widely used in ISDN networks to date.
I could be wrong and live in a cave though. ;-)
 
What do others think? Should we account for that in this first RFC or just rule it out
and save "explicit" support for a future update as needed?
 
Joanne
 
 
----- Original Message -----
Sent: Thursday, December 04, 2008 5:30 PM
Subject: Re: Initial WG review: draft-johnston-sipping-cc-uui-06

I was generally OK with this document, but I would still like to see a response on my last comments on the use of the option tag, and the associated requirement clause that causes us to need it.
 
Essentially if the aim of the document is only to interwork with the ISDN user-to-user service 1 implicit, then we don't need the option tag.
 
If the aim of the document is to interwork with the ISDN user-to-user service 1 explicit, then we would need the option tag in a Require header, I think we need to make sure of a number of things:
 
-    as all ISDN user user services can be separately explicit, is this going to ultimately generate 3 option tags.
-    have we collected all the requirements for interworking with the explicit service, which requires interworking with explicit signalling in the ISDN. In particular are there any distinct response code requirements.
 
If the aim of the document is only to interwork with the ISDN user-to-user service 1 implicit, but there are other use cases that require the option-tag, then I think the document should be open about these so we can examine the requirements in the light of those other use cases.
 
regards
 
Keith


From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Mary Barnes
Sent: Tuesday, December 02, 2008 12:49 AM
To: sipping@xxxxxxxx
Cc: Gonzalo Camarillo
Subject: Initial WG review: draft-johnston-sipping-cc-uui-06

Hi folks,

This email is intended to announce an initial WG review for the following  document:
http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc-uui-06.txt

There was strong consensus to complete the problem statement and requirements in the SIPPING WG session (i.e., WGLC) and then propose that the solution be worked in SIP WG - with the obvious understanding that SIP WG must go through the process of taking on a new work item.   And, of course, the chairs will work with the AD to get the appropriate milestones added to SIPPING WG charter.

In order to progress this document in the SIPPING WG, we would like at least 3 (ideally 4) dedicated reviewers. So, please let us know ASAP if you would be willing to serve as a reviewer.  If we don't get volunteers, I will pick on people, but it would be great to get some new reviewers into the pool. 

In terms of feedback, as well as technical comments, we would like to hear views on whether this doc is ready for WGLC (note that this document has been in the WG as an individual draft for over two years).

Please send any and all comments on or before Dec. 22nd, 2008 (3 weeks time).

Regards,
Mary.
SIPPING WG co-chair


_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux