Subject: Re: [Sipping] Conference policy URI

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 28 Feb 2004 01:35:40 -0500

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.

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.

-Jonathan R.

Rohan Mahy wrote:
> 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:
> 
>> 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.
>>
>> [email-masked] wrote:
>>
>>> 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
>>>>
>>>>
>>
>> -- 
>> 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
> 
> 

-- 
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