Subject: [Sipping] Status of draft-johnston-sipping-cc-uui-02.txt

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 7 Nov 2007 16:41:56 +0100

All, 

ETSI TISPAN is using the proposed mechanism in it's draft specification.
Accordingly the stability of the draft and any open issues are relevant
for the progress of the documents.

What is the current status of the draft? 

Greetings,
Denis Alexeitsev
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Thu, 8 Nov 2007 09:48:18 -0600

On Nov 7, 2007, at 9:41 AM, Alexeitsev, D wrote:

> All,
>
> ETSI TISPAN is using the proposed mechanism in it's draft  
> specification. Accordingly the stability of the draft and any open  
> issues are relevant for the progress of the documents.
>

My take is that the current draft suffers from all of the flaws that  
have made INFO such a point of debate.

Specifically, it lacks any mechanism for negotiation and discovery of  
content type or application context. The author is aware of this  
deficiency, and the issues are noted as FFS.

But we know what "future study" does here -- it says "Go back and  
figure out a discovery and negotiation mechanism".

As a standards-track SIP extension, a User-to-User header field would  
(under RFC 3427) would fall into the SIP working group, where it is  
not likely to advance with these issues unresolved.

Further, it looks to me like Service 3 would be a prime target for an  
"event within an INVITE-scoped dialog" such as has been proposed to  
replace current INFO usage. Service 2 looks somewhat similar, save  
that the SIP state machine doesn't allow INFO before the 200 OK on  
INVITE. Is this going to lead us to a requirement for event bodies on  
provisional responses, or using UPDATE?

--
Dean Willis

---

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 9 Nov 2007 11:24:22 +0100

HI,

>provisional responses, or using UPDATE?

Is there a real interest in the Service 2, or could we for the sake of
the simplicity first define the Service 3 only and thus avoid the INFO
discussion?

Greetings,
Denis Alexeitsev

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 Nov 2007 21:09:27 -0600

> the simplicity first define the Service 3 only and thus avoid the INFO

perhaps I wasn't clear. Service 3 looks like a usage of INFO, and  
that means we need to fix INFO so that we can have standardized  
usages of it. Fortunately, service 3 is a very straightforward usage  
of INFO (unlike changing the state machine), so it should be fairly  
easy IF we come to a consensus on fixing INFO.

--
Dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sat, 10 Nov 2007 14:11:45 +0100

As of last week this also became a 3GPP dependency.

The requirement from both TISPAN and 3GPP is to allow SIP terminals to
have access to specific usages of the ISDN (and therefore 3GPP) user to
user service 1 implicit data. This data is normally used for
coordinating applications between the end terminals.

There is no requirement identified for user to user service 1 explicit,
service 2 or service 3.

It doesn't have to be this solution, and I doubt anyone out there has
implemented this as a solution get, being as the agreements have only
just gone through, but the use case is real enough.

It should be noted that the various usages are discrimated in the
PSTN/ISDN by a single octet protocol discriminator, and ideally this
value needs to be reflected in some way (in addition to the data) at the
SIP terminal, in a manner that can also be mapped back on a one for one
basis (so that gateway to gateway communication can occur). The
interworking gateway between the PSTN/ISDN and the SIP environment
should ideally not have to understand this value.

These TISPAN / 3GPP usages also need to be discriminated from other
usages entirely within the SIP environment, which the author of the
original draft presumably was proposing.

Regards

Keith

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Thursday, November 08, 2007 3:48 PM
> To: Alexeitsev, D
> Cc: [email-masked]
> Subject: Re: [Sipping] Status of draft-johnston-sipping-cc-uui-02.txt
> 
> 
> My take is that the current draft suffers from all of the 
> flaws that have made INFO such a point of debate.
> 
> Specifically, it lacks any mechanism for negotiation and 
> discovery of content type or application context. The author 
> is aware of this deficiency, and the issues are noted as FFS.
> 
> But we know what "future study" does here -- it says "Go back 
> and figure out a discovery and negotiation mechanism".
> 
> As a standards-track SIP extension, a User-to-User header 
> field would (under RFC 3427) would fall into the SIP working 
> group, where it is not likely to advance with these issues unresolved.
> 
> Further, it looks to me like Service 3 would be a prime 
> target for an "event within an INVITE-scoped dialog" such as 
> has been proposed to replace current INFO usage. Service 2 
> looks somewhat similar, save that the SIP state machine 
> doesn't allow INFO before the 200 OK on INVITE. Is this going 
> to lead us to a requirement for event bodies on provisional 
> responses, or using UPDATE?
> 
> --
> Dean Willis
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 12 Nov 2007 15:00:42 +0100

Hi,

>easy IF we come to a consensus on fixing INFO.

Got that. 

My comment was, that it could be a reasonable way forward to progress
the UUI work without the in-session case (Service 3) that requires the
INFO fixing. The session-setup, teardown case requires only the header
definition and can be finalised before the resolution of the INFO issue.

There is no requirement from the TISPAN side to support the Service 3 in
the first phase.

Does anyone has a strong requirement to block the progress of the UUI
work until the Service 3 issues are resolved?

Greetings,
Denis Alexeitsev