Subject: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00

From: "Andrew Allen" <[email-masked]>
Date: Fri, 15 Oct 2010 05:34:44 -0500

A new Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-00 has
been submitted. It can be found at:

http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-00.tx
t

The referenced URN definition draft can also be found at:

http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-05.txt

The draft defines how the IMEI (International Mobile Equipment
Identifier) encoded as a URN can be used as an Instance ID as defined in
Outbound (RFC 5626) and as used by GRUU (RFC 5627). 3GPP have a need to
use the IMEI as an Instance ID as explained in the draft.

Please provide comments and feedback.

Thanks

Andrew

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2010 12:33:14 -0400

Andrew,

I don't understand the point of this draft.

The sip.instance feature tag takes a urn as a value. Either the imei urn 
works with that or it doesn't. If it does, no draft is needed. If it 
doesn't, then I don't think a draft will help, unless it is an extension 
to 5626.

5626 is a little hazy on whether all URNs are ok or not. It implies that 
it only works for ones that can be compared as strings for equality. 
Operationally I think that must be the requirement.

It would be very bad if implementors of gruu and outbound had to 
understand each type of URN that might be used as the instance id.

I gather that the imei urn might not always work with simple string 
comparison as the identity test. Hence you have included registrar 
procedures to ignore parameters when comparing the imei urns.

ISTM that you should not be imposing *any* new requirements on 
registrars. I guess there could be a purpose for such a draft if it was 
to impose requirements on user agents, about how they format their imei 
URNs so that they will work with generic comparison procedures at the 
registrar.

	Thanks,
	Paul

On 10/15/2010 6:34 AM, Andrew Allen wrote:
> http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-00.txt
>
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 15 Oct 2010 16:45:43 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]

As I see it, the point of the draft is the definition/registration of the "gsma:" scheme for URNs.  In that regard, it is a proper step to enable use of "gsma:imea" URNs as instance identifiers.

In that regard, though, I don't see the function of section 4.  It seems to describe now IMEAs can be encoded via BCD, which seems to have nothing to do with the gsma:imea URNs within SIP.

Also, in the Abstract, the expansion of the acronym GSMA should have been done the first time it is used, rather than the last time.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2010 20:06:48 -0400

This draft doesn't define a new urn scheme. IIUC the one referenced has 
previously been defined.

However, I went and checked 5656 again, and I see that it does have a 
normative requirement on an RFC for use of something other than a UUID 
urn. So there is point to this draft.

But my other points hold. As I interpret things, registrars should not 
have to change to accommodate new URNs in this role.

IMO 5626 should simply have spelled out the required characteristics for 
a URN that can be used, rather than requiring an RFC. But that is water 
over the dam.

	Thanks,
	Paul

---

From: "Andrew Allen" <[email-masked]>
Date: Sat, 16 Oct 2010 14:08:18 -0500

Paul

The reason for the draft is that RFC 5626 requires an RFC for use of URNs other than UUID as instance IDs.

With regard to your comments about putting requirements on the registrar maybe any requirements for gr parameter generation can be left to 3GPP since that is domain specific policy in any case.

Andrew

----- Original Message -----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Friday, October 15, 2010 12:33 PM
To: [email-masked] <[email-masked]>
Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00

Andrew,

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Sun, 17 Oct 2010 20:25:44 -0400

_______________________________________
From: Paul Kyzivat [[email-masked]]

This draft doesn't define a new urn scheme. IIUC the one referenced has
previously been defined.
_______________________________________

I don't see "gsma" listed in the IANA registry (http://www.iana.org/assignments/uri-schemes.html).

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Oct 2010 09:06:44 -0400

> The reason for the draft is that RFC 5626 requires an RFC for use of URNs other than UUID as instance IDs.

Yes, my bad.

> With regard to your comments about putting requirements on the registrar maybe any requirements for gr parameter generation can be left to 3GPP since that is domain specific policy in any case.

My concern was mostly with imposing particular URN comparison 
requirements on the registrar. IMO the registrar must not be required to 
understand this particular URN or apply any new comparison rules when it 
is used. The registrar should apply the same procedures regardless of 
URN type.

	Thanks,
	Paul

> To: [email-masked]<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Oct 2010 09:08:04 -0400

Maybe its in progress or something. I didn't see anything in this draft 
that actually registers a new urn scheme.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 18 Oct 2010 11:14:43 -0400

OK, there it is:  https://datatracker.ietf.org/doc/draft-montemurro-gsma-imei-urn/
That draft has been kicking around for several years.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 18 Oct 2010 11:16:37 -0400

The sensible rules are spelled out in RFC 5626 section 4.1:

      Thus, equality comparisons are performed using the rules for
      URN equality that are specific to the scheme in the URN.  If the
      element performing the comparisons does not understand the URN
      scheme, it performs the comparisons using the lexical equality
      rules defined in [RFC2141].  Lexical equality could result in two
      URNs being considered unequal when they are actually equal.  In
      this specific usage of URNs, the only element that provides the
      URN is the SIP UA instance identified by that URN.  As a result,
      the UA instance has to provide lexically equivalent URNs in each
      registration it generates.  This is likely to be normal behavior
      in any case; clients are not likely to modify the value of the
      instance ID so that it remains functionally equivalent to (yet
      lexicographically different from) previous registrations.

The problem isn't that the URN scheme definition provides an elaborate definition of equality that is suitable to its application, but that UAs must always provide instance ids that are the same character string, even if the URN scheme allows them flexibility in how to represent the URN.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Oct 2010 12:00:35 -0400

IMO the problem is that this draft expects the registrar to use special 
comparison rules for this sort of URN.

If it removed that requirement, and instead put a requirement on the UA 
to construct its URN in such a way that the lexical equality rule of 
2141 is sufficient, then I think all would be well.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 18 Oct 2010 17:19:48 -0400

> 2141 is sufficient, then I think all would be well.

Yes, clearly, having the UAs depend on special behavior in the
registrar for this URN scheme would mean that only specialized
registrars could cope with UAs that used these URNs as their instance
id.  That would minimize compatibility.  The draft needs to be revised
to follow RFC 5626 section 4.1 (which is referenced from the GRUU
RFC).

Dale

---

From: "Andrew Allen" <[email-masked]>
Date: Tue, 19 Oct 2010 14:56:03 -0500

Dale, Paul

Thank you for your comments. I plan to make a revision based on them and hopefully resubmit before the 2nd deadline. Hopefully we can discuss in Beijing.

Andrew

----- Original Message -----
From: Worley, Dale R (Dale) [mailto:[email-masked]]
Sent: Monday, October 18, 2010 05:19 PM
To: Paul Kyzivat <[email-masked]>
Cc: Andrew Allen; [email-masked] <[email-masked]>
Subject: RE: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00

Dale