Subject: RE: [Sipping] Conference policy URI

From: [email-masked]
Date: Fri, 6 Feb 2004 09:51:37 +0200

Thanks Jonathan. A draft has been submitted to the SIP WG.

http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00.txt

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 24.January.2004 04:44
> To: Khartabil Hisham (Nokia-TP/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Sipping] Conference policy URI
> 
> 
> I think this is a reasonable usage of Call-Info. However, it can only 
> be done if a "purpose" tag value is registered with IANA, as 
> indicated 
> by section 20.9. However, it ocurred to me, when reading 
> this, that we 
> never set up an IANA registry for call-info purpose tokens! Oops! 
> Thats easily rectifiable; when the draft defining the 
> 'policy-uri' (or 
> whatever its called) purpose tag is written, it should also 
> create the 
> registry and register the other tokens defined in rfc3261.
> 
> -Jonathan R.
> 
> [email-masked] wrote:
> 
> > Hi,
> > 
> > There was consensus on the XCON mailing list that the conference
> > state event package needs to include in the notification the
> > conference policy URI.
> > 
> > There was also consensus that some participants may not want to
> > subscribe to the conference package but would still like to learn
> > the conference policy URI. In this case, it was suggested that the
> > Call-info header carries such information. Perhaps the
> > cc-conferencing draft can include examples of that.
> > 
> > Thanks, Hisham
> > 
> > _______________________________________________ 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
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Feb 2004 15:17:47 -0500

Thanks for doing this. Some comments.

Firstly, on the registry itself. You need to give clearer guidance to 
IANA on the registry. I would suggest including a table that shows how 
it should look like. You need to tell IANA what information needs to be 
provided in future RFCs that register additional values (value, RFC 
number, registrant, etc.). Please take a look at rfc2434 
(ftp://ftp.rfc-editor.org/in-notes/rfc2434.txt).

Secondly, on the "policy-uri" value - you need to specify, I think, what 
the URI type is, and what the content is at that URI (at least a 
mandatory to implement one) in order to get interoperability. Unlike the 
other stuff, which is just rendered for user information, this resource 
is processed by an automata, and I think you need to say more about it.

Thanks,
Jonathan R.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 18 Feb 2004 06:17:15 -0800

Hi,

I believe the SIPPING working group has come down with a bad case of  
Ianaus Registritus.  This rare, but preventable disease is caused by  
trying to register every possible field or parameter mentioned in a set  
of standards track documents.   It is highly contagious to other  
related working groups.  Treatment consists of deleting IANA  
Registration sections until the symptoms subside.  The patient should  
begin feeling better immediately.

Seriously, I like the new Call-Info purpose, but I think the IANA  
Registry goes way too far overboard.  Remember that there is an  
administrative and political cost to setting up new IANA Registries.

thansk,
-rohan

On Feb 10, 2004, at 12:17 PM, Jonathan Rosenberg wrote:

> it should look like. You need to tell IANA what information needs to  
> be provided in future RFCs that register additional values (value, RFC  
> Secondly, on the "policy-uri" value - you need to specify, I think,  
> what the URI type is, and what the content is at that URI (at least a  
> mandatory to implement one) in order to get interoperability. Unlike  
> the other stuff, which is just rendered for user information, this  
> resource is processed by an automata, and I think you need to say more  
> about it.
>
> Thanks,
> Jonathan R.
>
>>> I think this is a reasonable usage of Call-Info. However, it can  
>>> only be done if a "purpose" tag value is registered with IANA, as  
>>> indicated by section 20.9. However, it ocurred to me, when reading  
>>> this, that we never set up an IANA registry for call-info purpose  
>>> tokens! Oops! Thats easily rectifiable; when the draft defining the  
>>> 'policy-uri' (or whatever its called) purpose tag is written, it  
>>> should also create the registry and register the other tokens  
>>> defined in rfc3261.
>>>
>>> -Jonathan R.
>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Feb 2004 00:30:00 +0200

Hi,

Jonathan wrote:
> As for the expense of creating registries - I dont think we should let 
> current administrative difficulties preclude us from doing what we think 
> the right thing is.

This is my view as well.

Gonzalo

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 28 Feb 2004 23:50:14 -0800

To summarize my position:

- I'm fine adding a new Call-Info purpose

- I don't think a registry of these purposes was or ever will be 
needed/"the right thing to do"

- To that end, I would be happy to log an errata against 3261 to remove 
the statement about such a registry

- Creating an unnecessary registry causes lots of people to lots of 
unnecessary work, and causes resentment toward the SIP and SIPPING 
working groups

thanks,
-rohan

On Feb 27, 2004, at 10:35 PM, Jonathan Rosenberg wrote:

> Call-Info purpose is not new. In fact, the idea of a registry for it 
> is not new either. RFC 3261 explicitly calls it out:
>
> 20.9 Call-Info
>
>    The Call-Info header field provides additional information about the
>    caller or callee, depending on whether it is found in a request or
>    response.  The purpose of the URI is described by the "purpose"
>    parameter.  The "icon" parameter designates an image suitable as an
>    iconic representation of the caller or callee.  The "info" parameter
>    describes the caller or callee in general, for example, through a 
> web
>    page.  The "card" parameter provides a business card, for example, 
> in
>    vCard [36] or LDIF [37] formats.  Additional tokens can be 
> registered
>    using IANA and the procedures in Section 27.
>
>
> The problem is that we forgot (i.e. - a bug) to include the definition 
> of this registry in RFC 3261. The draft is merely correcting an error 
> in RFC3261.
>
> current administrative difficulties preclude us from doing what we 
> think the right thing is.
>
> -Jonathan R.
>
>
> Rohan Mahy wrote:
>> Hi,
>> trying to register every possible field or parameter mentioned in a 
>> set  of standards track documents.   It is highly contagious to other 
>>> Firstly, on the registry itself. You need to give clearer guidance 
>>> to  IANA on the registry. I would suggest including a table that 
>>> shows how  it should look like. You need to tell IANA what 
>>> information needs to  be provided in future RFCs that register 
>>> additional values (value, RFC  number, registrant, etc.). Please 
>>> take a look at rfc2434  
>>> what the URI type is, and what the content is at that URI (at least 
>>> a  mandatory to implement one) in order to get interoperability. 
>>> Unlike  the other stuff, which is just rendered for user 
>>> information, this  resource is processed by an automata, and I think 
>>> you need to say more  about it.
>>>
>>> Thanks,
>>> Jonathan R.
>>>
>>>>>  tokens! Oops! Thats easily rectifiable; when the draft defining 
>>>>> the  'policy-uri' (or whatever its called) purpose tag is written, 
>>>>> it  should also create the registry and register the other tokens  
>>>>> defined in rfc3261.
>>>>>
>>>>> -Jonathan R.
>>>>>