Subject: [Sipping] New OMA suggested requirements for draft-ietf-sipping-uri-list-conferencing-04.txt

From: Dean Willis <[email-masked]>
Date: Mon, 6 Feb 2006 09:59:24 -0600

OM is looking at uri-list conferencing for their push-to-talk work. .

One of their needs is to inform POC recipients of the "cc" list --  
that is, the set of other URIs invited to the conference. They also  
have a need for "bcc" participants who get invited but not advertised.

This is allowed for in the message-list work (draft-ietf-sipping-uri- 
list-message-06.txt) by having the message exploder include a copy of  
the recipient list on outbound messages, and allows for tagging each  
target as a "to", "cc" or "bcc" using the usual email semantics.

Should we:

1) Address this in our uri-list draft before publishing it (it's past  
WGLC).

2) Request OMA author a draft that extends our draft.

I believe we could basically paste the recipient-notification text  
from uri-list-message into uri-list-conferencing. But this is a  
fairly late phase to be changing the requirements.

To meet the full set of conferencing requirements in current OMA  
discussions, we would also need to add the role 'anonymous' and add  
some discussion of how the roles interact with the conference-package  
notifications.

What do you think?

--
Dean

_______________________________________________
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: Miguel Garcia <[email-masked]>
Date: Wed, 08 Feb 2006 10:05:10 +0200

Actually, I spoke with Gonzalo about this potential usage of the 
'capacity' extension some time ago already.

I believe we should the following:

- Extract the 'capacity' extension to the resource-list from 
draft-ietf-sipping-uri-list-message-06.txt and place it in a separate 
document that just defines the XML schema and side-by effects (IANA 
registration, etc.).

- Modify draft-ietf-sipping-uri-list-message-06.txt to refer to the 
'capacity' extension draft.

- Modify draft-ietf-sipping-uri-list-conferencing-04.txt to refer to the 
'capacity' extension draft.

This is an editorial work, I can submit the 'capacity' draft in the next 
days. Is this acceptable?

/Miguel

Dean Willis wrote:
> One of their needs is to inform POC recipients of the "cc" list -- that 
> is, the set of other URIs invited to the conference. They also have a 
> need for "bcc" participants who get invited but not advertised.
> 
> This is allowed for in the message-list work 
> (draft-ietf-sipping-uri-list-message-06.txt) by having the message 
> exploder include a copy of the recipient list on outbound messages, and 
> allows for tagging each target as a "to", "cc" or "bcc" using the usual 
> email semantics.
> 
> 
> Should we:
> 
> I believe we could basically paste the recipient-notification text from 
> uri-list-message into uri-list-conferencing. But this is a fairly late 
> phase to be changing the requirements.
> 
> discussions, we would also need to add the role 'anonymous' and add some 
> discussion of how the roles interact with the conference-package 
> notifications.
> 
> What do you think?
> 
> -- 
> Dean
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: Dean Willis <[email-masked]>
Date: Wed, 8 Feb 2006 02:17:49 -0600

On Feb 8, 2006, at 2:05 AM, Miguel Garcia wrote:

> - Extract the 'capacity' extension to the resource-list from draft- 
> ietf-sipping-uri-list-message-06.txt and place it in a separate  
> - Modify draft-ietf-sipping-uri-list-conferencing-04.txt to refer  
> to the 'capacity' extension draft.
>
> This is an editorial work, I can submit the 'capacity' draft in the  
> next days. Is this acceptable?

That works for me.

To meet OMA's needs (which are really fairly obvious given the  
"capacity model")   we'll need to add a new capacity of "Anonymous"  
or something like that. Each anonymous target gets a copy of the  
message (just like a CC or BCC target), but we need to retain a  
placeholder entry in the recipient URI list for each anonymous  
recipient.

So, you might see that Alice, Bob, Charlie, and four anonymous  
recipients have been invited to the same conference as you.

--
Dean

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 08 Feb 2006 10:34:18 +0200

Dean Willis wrote:
> 
> 
> To meet OMA's needs (which are really fairly obvious given the "capacity 
> model")   we'll need to add a new capacity of "Anonymous" or something 
> like that. Each anonymous target gets a copy of the message (just like a 
> CC or BCC target), but we need to retain a placeholder entry in the 
> recipient URI list for each anonymous recipient.
> 

I think the anonymous requirement might be quite close to the 'bcc' 
capacity... probably the only difference is that, on the UAS side, the 
UAS gets a count of 'anonymous' recipients, whereas if the same 
recipients had been targeted as 'bcc' the UAS wouldn't have got anything.

So, is it acceptable to add another 'anonymous' capacity that lists 
those URIs that the UAC want to be listed as anonymous?

In the other side (URI-list server to UAS) we can list the provide 
"meaningless" URIs, such as sip:[email-masked], 
sip:[email-masked], etc... On this side we wouldn't have the count 
of anonymous URIs, but one anonymized URI per original URI tagged as 
anonymous.

/Miguel

---

From: Dean Willis <[email-masked]>
Date: Wed, 8 Feb 2006 06:24:28 -0600

On Feb 8, 2006, at 2:34 AM, Miguel Garcia wrote:

>> "capacity model")   we'll need to add a new capacity of  
>> "Anonymous" or something like that. Each anonymous target gets a  
>> copy of the message (just like a CC or BCC target), but we need to  
>> retain a placeholder entry in the recipient URI list for each  
>> anonymous recipient.
> capacity... probably the only difference is that, on the UAS side,  
> the UAS gets a count of 'anonymous' recipients, whereas if the same  

> those URIs that the UAC want to be listed as anonymous?

I believe so.

> "meaningless" URIs, such as sip:[email-masked], sip: 
> [email-masked], etc... On this side we wouldn't have the count  
> of anonymous URIs, but one anonymized URI per original URI tagged  
> as anonymous.

Do we need to provide an "anonymous" URI in the list service that  
maps to the anonymized URI constructed by the conference bridge?  I  
think not -- so I'm not sure we even need the "1" and "2" user parts  
above. Perhaps we need more of a URN for generic anonymous users. If  
we did need return-routability that would map to the anonymization  
provided by a conference server, then we'd need a much more  
sophisticated function with a localized UUID.

--
Dean

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 08 Feb 2006 16:58:24 +0200

Dean Willis wrote:
> 
> Do we need to provide an "anonymous" URI in the list service that maps 
> to the anonymized URI constructed by the conference bridge?  I think not 
> -- so I'm not sure we even need the "1" and "2" user parts above. 
> Perhaps we need more of a URN for generic anonymous users. If we did 
> need return-routability that would map to the anonymization provided by 
> a conference server, then we'd need a much more sophisticated function 
> with a localized UUID.

Right, it wasn't the intention to provide return-routability or 
something like that.

To be more precise, let's think of the following proposal through some 
examples:

The UAC sends the following list to the URI-list server:

<list>
  <entry uri="sip:[email-masked]" cp:capacity="to" cp:anonymize="yes"/>
  <entry uri="sip:[email-masked]" cp:capacity="to"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc" cp:anonymize="yes"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc" cp:anonymize="yes"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc">
  <entry uri="sip:[email-masked]" cp:capacity="bcc" />
</list>

The URI-list server anonymizes all those URIs categorized with the 
anonymize="yes" attribute, deletes those URIs listed with the 
capacity="bcc" (as usual), and produces the following list:

<list>
  <entry uri="sip:[email-masked]" cp:capacity="to"/>
  <entry uri="sip:[email-masked]" cp:capacity="to"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc"/>
</list>

Notice that every anonymized URI becomes "sip:[email-masked]", 
but if you have a better suggestion, like an anonymous URN, I am fine (I 
just took this because of the recommendations in RFC 3261).

Is this OK?

/Miguel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 08 Feb 2006 18:42:04 +0200

Hi,

the presence of the anonymize flag in a bcc entry would have not effect 
then, right? The server would not copy that entry into outgoing messages 
anyway.

Thanks,

Gonzalo

Miguel Garcia wrote:
>> to the anonymized URI constructed by the conference bridge?  I think 
>> not -- so I'm not sure we even need the "1" and "2" user parts above. 
>> need return-routability that would map to the anonymization provided 
>> by a conference server, then we'd need a much more sophisticated 
>> function with a localized UUID.
> 
>

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 09 Feb 2006 09:11:24 +0200

correct, the anonymize flag does not make sense in a bcc entry.

/Miguel

Gonzalo Camarillo wrote:
>> but if you have a better suggestion, like an anonymous URN, I am fine 
>> (I just took this because of the recommendations in RFC 3261).
>>
>> Is this OK?
>>
>> /Miguel

---

From: Dean Willis <[email-masked]>
Date: Thu, 9 Feb 2006 02:55:09 -0600

On Feb 8, 2006, at 8:58 AM, Miguel Garcia wrote:

> Notice that every anonymized URI becomes  
> "sip:[email-masked]", but if you have a better suggestion,  
> like an anonymous URN, I am fine (I just took this because of the  
> recommendations in RFC 3261).
>

I think this is OK. It was also suggested in OMA that we could reduce  
the redundancy message by adding a counter to the schema and  
converting the above to something like (my XML is probably broken):

<list>
  <entry uri="sip:[email-masked]" cp:capacity="to"/>
  <entry uri="sip:[email-masked]" cp:capacity="to"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc" count="2"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc"/>
</list>

--
Dean

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 09 Feb 2006 10:58:48 +0200

Dean Willis wrote:
> the redundancy message by adding a counter to the schema and converting 
> the above to something like (my XML is probably broken):
> 
> <list>

It's fine too. I'll use this one as the base for the new XML Schema.

/Miguel

---

From: Atsushi SATO <[email-masked]>
Date: Thu, 09 Feb 2006 23:00:26 +0900

Hi Dean, Miguel, Gonzalo, and all,

I am from NTT DoCoMo, and attending OMA-PoC.

> correct, the anonymize flag does not make sense in a bcc entry.

I think so. 
In my thinking making a new attribute for indicating anonymity has
a redundancy against for its purpose.
In my thinking, it is enough that we make a new  element for 'capacity'
attribute instead of make a new attribute for this purpose.

That is, put a new element as 'hidden'(= meaning anonymous) in 'capacity'
attribute on XML schema like;

<xs:attribute name="capacity">
     <xs:simpleType>
        <xs:restriction base="xs:string">
           <xs:enumeration value="to"/>
           <xs:enumeration value="cc"/>
           <xs:enumeration value="bcc"/>
           <xs:enumeration value="hidden"/>
        </xs:restriction>
     </xs:simpleType>
</xs:attribute>

And examples:

The UAC sends the following list to the URI-list server:
<list>
  <entry uri="sip:[email-masked]" cp:capacity="to"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc"/>
  <entry uri="sip:[email-masked]" cp:capacity="bcc"/>
  <entry uri="sip:[email-masked]" cp:capacity="hidden"/>
  <entry uri="sip:[email-masked]" cp:capacity="hidden"/>
</list>

The URI-list server anonimizes all those URIs categorized with
the capacity="hidden" element, deletes those URIs listed with the
capacity="bcc" (as usual), and produces the following list in two way:

1st way:
<list>
  <entry uri="sip:[email-masked]" cp:capacity="to"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc"/>
  <entry uri="sip:[email-masked]" cp:capacity="hidden"/>
 <entry uri="sip:[email-masked]" cp:capacity="hidden"/>
</list>

Or, for the purpose of the reduction of the size of request message, 
specifying a new attribute indicating the number, URI-list server can
produce it as:(This has been already suggested by Dean on this ML.)

2nd way:
<list>
  <entry uri="sip:[email-masked]" cp:capacity="to"/>
  <entry uri="sip:[email-masked]" cp:capacity="cc"/>
  <entry uri="sip:[email-masked]" cp:capacity="hidden" cp:num="2"/>
</list>

1st one has a merit for distinguish the anonymized users in UAC. This might
be useful for UAC to distinguish the anonymized users when SUBSCRIBE/
NOTIFY events are occurred. UAC can distinguish them but can not 
understand who they are.
On the other hand, 2nd one has a merit to reduce a message size.
In my thinking, both 1st and 2nd solution does not conflict each other.
UAS shall be able to choose from them.

How do you think about this?

Best Regards,
Atsushi

Atsushi SATO
NTT DoCoMo,Inc.
E-mail :[email-masked]

On Thu, 09 Feb 2006 10:58:48 +0200