Subject: RE: [Sip] SIP instance identifiers

From: "Orit Levin" <[email-masked]>
Date: Fri, 20 Feb 2004 10:39:54 -0800

I tend to agree with Paul (if I read him correctly).

I think that GUID and the original GRID parameter are very different
things because of their properties (and obviously the resultant usage
cases).

Below is my view on the topic.

1. Global Unique ID: GUID IS a very well-known concept. It is used by
many applications outside SIP, but I don't see its direct relation to
SIP. I am not sure whether we need a dedicated SIP placeholder for it.
For PIDF applications, GRUU is enough, in my opinion (see below).

2. GRUU format: GRUU (not GRID or GUID) is a SIP URI and is very SIPish
concept with the properties as defined in the GRUU draft. It IS the "SIP
Instance Identifier". Being a SIP URI, it can be used in any Presence
(e.g. PIDF) applications without changing the defined XML schemas. It
may be beneficial to define a URI parameter that says: "This SIP URI has
GRUU properties". It will eliminate the need for Supported: gruu in
every message and for potential expanding the PIDF documents to include
this clarification. 

3. GRUU signaling and usage: GRUU can be allocated either by Registrar,
or by UA, or by different means. My point is GRUU identification (i.e.
placement and signaling) during session establishment and usage
(especially outside the Registrar domain) MUST be identical for all
cases. Moreover, it MUST be possible for the Registrar domain to conceal
the information about the allocation method being used.

4. Registration Procedure: We need to standardize the registration
procedure for both basic cases: GRUU allocated by Server (done) and GRUU
allocated by Client. In my opinion, both cases need to be under the
Registration/contact umbrella - which makes them SIP concepts! Whether
GRUU value is preserved during client's/server's reboots - it doesn't
change the concept. From usability point of view, it would be very nice
to keep the value as long as possible. From the outside user point of
view - it doesn't need to know (and doesn't want to know) what the
registration durability of its peers is.

5. Saving Registration Cycles and DB size: By using GRUU we have the
ability to contact a specific instance of SIP AOR. Once we point to a
specific entity, we MAY also need to point to specific sub-entities
inside this GRUU. This will save the registration burden from each of
these sub-entities, since they will be covered by GRUU's registration
and routing. The original GRID parameters allowed for exactly this
functionality. The usage example is a conference factory which generates
foci and doesn't need to dynamically REGISTER each of them in order to
achieve proper routing. BTW, the concept of "internal routing" to
specific logical module inside SIP entity can be generalized, decoupled
from GRUU and be defined as a dedicated SIP header.

Orit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Thursday, February 19, 2004 9:37 PM
To: Cullen Jennings
Cc: Jonathan Rosenberg; [email-masked]
Subject: Re: [Sip] SIP instance identifiers

Just to be clear, I am not *advocating* that we need these identifiers 

any other place. I'm just saying that if there are other uses for a 

device id, that it won't hurt to use the same id elsewhere.

For the purpose we are discussing, it is important that the id be 

associated with a registered contact, and since REGISTER permits 

multiple contacts, it really needs to be a parameter on each contact.

That is really an entirely different application from identifying which 

device originated a particular message. If there is a need for that, 

then it needs to be in some header that can be in any message. I don't 

recommend we do that until we have a need for it.

      Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Feb 2004 14:36:25 -0500

> I tend to agree with Paul (if I read him correctly).

I think maybe you don't read me as intended, because I don't entirely 
agree with you here. (At least if I understand you.)

> things because of their properties (and obviously the resultant usage 

If you are talking about the grid=xxx parameter that Jonathan has 
proposed be used with GRUUs, then I don't think it has any signficance 
to this discussion at all.

> 1. _Global Unique ID:_ GUID IS a very well-known concept. It is used by 

I don't know that anyone is talking about this. But we are talking about 
a slightly more restricted concept - a Device ID. Conceivably a device 
could use a guid as its device id, but that is largely irrelevant to 
this discussion.

> 2. _GRUU format:_ GRUU (not GRID or GUID) is a SIP URI and is very 
> SIPish concept with the properties as defined in the GRUU draft. It IS 
> the "SIP Instance Identifier".

The last sentence is debatable. It is *an* endpoint instance identifier 
that is sip routable. But it isn't necessarily defined for as long as 
the device(s) it references are. And it isn't necessarily bound to the 
same device at all times.

I think you may have missed the point that the device id is distinct 
from the GRUU, though dependent upon it. Many different GRUUs may share 
the same device id. I am proposing that the device id be represented as 
a URI, but not necessarily (generally not) a sip uri. Generally I expect 
a URN to be used.

> 3. _GRUU signaling and usage:_ GRUU can be allocated either by 
> Registrar, or by UA, or by different means. My point is GRUU 
> identification (i.e. placement and signaling) during session 
> establishment and usage (especially outside the Registrar domain) MUST 
> be identical for all cases. Moreover, it MUST be possible for the 
> Registrar domain to conceal the information about the allocation method 
> being used.
> 
> 4. _Registration Procedure:_ We need to standardize the registration 
> to keep the value as long as possible. >From the outside user point of 

Jonathan should probably chime in here. I believe he argues that 
typically a UA can't tell whether it can generate its own GRUU, so they 
should always be assigned by registrars.

> 5. _Saving Registration Cycles and DB size_: By using GRUU we have the 
> these sub-entities, since they will be covered by GRUU’s registration 
> foci and doesn’t need to dynamically REGISTER each of them in order to 
> achieve proper routing. BTW, the concept of “internal routing” to 

Maybe it can be decoupled from GRUU, but I think it must be coupled to a 
URL, not a message. So it must be a URL formatting convention and/or a 
url parameter. So maybe you could generalize the grid parameter to apply 
to all sip/sips urls, rather than coupling it to gruu. I haven't thought 
thru where that might be useful.

	Paul

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

---

From: Gokul Prabhakar <[email-masked]>
Date: Mon, 23 Feb 2004 12:22:30 -0500

Hi
  I am recent to the group and have been reading and getting interested 
about encodings in SIP (e.g
MIME encoding proposal postings by Cullen).

I also noted that Henning in one of his papers (Oct 2000, IEEE Comm 
magazine),
refers to a work where Java applets were proposed to be included in SIP 
requests for
service creation.

 I am interested if there is any progress made in this specific aspect? 
In fact, encoding
executable content on SIP requests can be powerful abstraction and can 
be usefully utized for
a lot of other things (not only service creation). But it can also 
create otentially serious security issues...
(This is also somewhat similar to binary MIME encodings in SIP, in which 
case the question arises how
such encodings are interpreted.)

 I am just wondering if any work is done on this..

Thanks & Regards, Gokul

Pl post reply to the MG and not to me. Thx.

---

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

inline.

> to this discussion at all.

I agree, I dont see the relationship.

> same device at all times.

Right. The GRUU is not a device identifier. Its a URI whose property is 
that it tends to route to a device with a particular device ID. The UML 
in the GRUU spec tries to explain the relationship between them.

>> Registrar domain to conceal the information about the allocation 
>> method being used.
>>
>> procedure for both basic cases: GRUU allocated by Server (done) and 
>> GRUU allocated by Client. In my opinion, both cases need to be under 
>> the Registration/contact umbrella - which makes them SIP concepts! 
>> Whether GRUU value is preserved during client's/server's reboots - it 
>> doesn't change the concept. From usability point of view, it would be 
>> very nice to keep the value as long as possible. >From the outside 
>> user point of view - it doesn't need to know (and doesn't want to 
>> know) what the registration durability of its peers is.
> 
> 

Correct. If a UA happens to be able to be able to generate a URI that it 
KNOWS has the properties of a GRUU, this is going to be because it is 
effectively co-located with a registrar responsible for a particular domain.

>> functionality. The usage example is a conference factory which 
>> generates foci and doesn’t need to dynamically REGISTER each of them 
>> in order to achieve proper routing. BTW, the concept of “internal 
>> routing” to specific logical module inside SIP entity can be 
>> generalized, decoupled from GRUU and be defined as a dedicated SIP 
>> header.
> 
> 

Sounds like ISDN subaddresssing.

I think that this is a fair analogy to grid. I'm not sure I see cases 
where it is useful to have the grid functionality separate from GRUUs. 
Orit, can you give a specific example?

-Jonathan R.
-- 
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