Subject: Re: [Ecrit] Adding top-level service labels

From: Richard Barnes <[email-masked]>
Date: Tue, 14 Feb 2012 17:57:42 -0500

Dear WG,

There has been little response to this proposal from Andrea.  In discussions with the ADs, the chairs have concluded that if this document progresses, it will have to be through the working group.  So we would like to issue a consensus call for whether the WG should take this document on as a WG item.  

Please send comments to the list no later than 21 Feb 2012.

Thanks,
Richard and Marc

On Dec 19, 2011, at 4:16 PM, Andrea G. Forte wrote:

> Dear all,
> 
> Recently, the LoST Extensions draft has been ratified as RFC 6451. This
> means that people can start using LoST for non-emergency services.
> Furthermore, Telecom Italia (the first Italian mobile carrier) has
> contacted us for knowing the status of the service classification draft as
> they were interested in working in that area.
> 
> We think that times have matured enough to resume our discussion on
> non-emergency location-based services. However, given that this is the
> ECRIT working group, I wanted to bring to the group's attention the draft
> on service URN update policy
> [http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00].
> 
> As a reminder, this draft would update "Section 4.1 of [RFC5031] in that
> the policy for adding top-level service labels is "Expert Review".  The
> expert is designated by the RAI Area Director". Today standard action is
> required for this, which is a significant overkill to just add "food" or
> "lodging". I do not see any harm in introducing this change in policy but
> I would like to know the opinion of the WG.
> 
> Thanks,
> -- Andrea G. Forte
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Feb 2012 15:19:50 -0800

I have no problem with opening registration.

In the interests of democratization of the space, is there anything
prohibiting someone from using an http: URI to identify a service?
The only reason that you want some portion of the urn:service: space
is for interoperability.  The only other stricture is global
uniqueness.

--Martin

---

From: Richard Barnes <[email-masked]>
Date: Tue, 14 Feb 2012 18:28:42 -0500

<hat type="individual"/>

Well, RFC 5222 does frequently refer to "service URNs", e.g.:
"
   1.  If the requested service, identified by the service URN [9] in
       the <service> element of the request, exists for the location
       indicated, then the LoST server copies the service URN from the
       request into the <service> element.
"
(Reference [9] is RFC 5031.)

So while it wouldn't necessarily cause the schema validator to choke, I wouldn't be surprised if there were implementors that read the document to imply that only "urn:service:*" names would appear in the <service> field.  

But I like your idea for extensibility better, and would like the above to be proven wrong...

--Richard

---

From: Ted Hardie <[email-masked]>
Date: Tue, 14 Feb 2012 15:28:55 -0800

> is for interoperability.  The only other stricture is global

RFC 6451 says it is compatible with RFC 5222, which specifies service
URNs; I think if it were to relax from a managed namespace to any URI
(or even HTTP URIs), then I think you'd need to update at least 6451,
and maybe 5222.

If you don't want interoperablity, you could use a UUID, with a
mapping known only to the application.  But I suspect the value is in
some intersection of interoperablity, human readability, and
uniqueness.

regards,

Ted

---

From: Brian Rosen <[email-masked]>
Date: Tue, 14 Feb 2012 18:31:33 -0500

On this subject, let me note that NENA has a urn namespace (urn:nena), in which it has defined urn:nena:service, in which it has several urns defined which are intended to be used with LoST inside an Emergency Services IP Network.  We will, for example, route a call to the correct police department with one of them.  Since it's in private networks, and not in the urn:service namespace, there is no need to ask the IETF to do anything, and of course it is in the realm of emergency services.  However, it's illustrative of not needing standards track to get more services.

Brian

---

From: Ted Hardie <[email-masked]>
Date: Tue, 14 Feb 2012 15:31:56 -0800

> But I like your idea for extensibility better, and would like the above to be proven wrong...

I think there is a huge rat hole down the "are HTTP URIs which depend
on the domain name system stable enough or not".  The rats down there
are friendly enough, as people don't visit them that much any more,
but that means they'll want to discuss it ad naseum if not infinitum.
I'd say that creating a tree under the service tree that does not
require standards action is easy enough, even if you don't want to
change it for the whole tree:

Ted

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Feb 2012 16:59:32 -0800

Ted Hardie <[email-masked]> wrote:
> [...] RFC 5222, which specifies service URN [...]

It's tempting to suggest that "urn:" scheme URIs don't have a monopoly
on Unique Resource Names and risk an interoperability failure.

Anyone sufficiently motivated could update the requisite RFCs, but my
risk analysis suggests that that energy might be better saved against
the outside chance that a fire breaks out.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 15 Feb 2012 10:39:43 -0800

> on Unique Resource Names and risk an interoperability failure.

urn URIs are "Uniform Resource Names"; they do aim to have the property
that they are unique, but it is really the persistence aspect that is
the rathole:

  Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers and are designed to make
   it easy to map other namespaces (which share the properties of URNs)
   into URN-space. Therefore, the URN syntax provides a means to encode
   character data in a form that can be sent in existing protocols,
   transcribed on most keyboards, etc.
(RFC 2141)

Because domain owners can change the resource available at a
location-dependent URI, or the domain owner can change, http URIs
generally aren't seen to have that property. Something like Larry
Masinter's dated URI syntax would get that property, since it is "at
this location-dependent URI at a specific time".

Personally, I'm not sure services need to be named in a
location-independent way; I do hope that the names are persistent,
though, as that adds significantly to the chance they won't get
re-invented (and thus to interoperability).

regards,

Ted

---

From: "Andrea G. Forte" <[email-masked]>
Date: Wed, 15 Feb 2012 14:32:00 -0500

The main concern here is interoperability. Do we really want people to
start using LoST with whatever URI they like? Do we really want to have
100 different URIs for "school"?

In my opinion, the description should be location-independent because it
describes a service, not a service at a certain location. The location
information is a different layer put on top of the service description so
that I can identify the service in a location-independent way and then
specify the past, present or future location I want to use in querying for
that service.

Thanks,
-- Andrea