Subject: Re: [salud] draft-ietf-salud-alert-info-urns / high level concerns

From: Laura Liess <[email-masked]>
Date: Tue, 5 Jun 2012 18:40:39 +0200

Alfred,

I am sorry for the quite late response to your concern, but we had to
discuss the issue in detail. As you recommended, we went through the
entries of the IANA URN Namespaces table and we
think that no already existing URN namespace would matches the
requirements. (I upgraded the  "Namespace Considerations" Section text
accordingly.)
Also there are already existing implementations, in life networks with
thousands of SIP users.

Please find below the proposal for the upgraded "Namespace
Considerations" Section text and let me know what you think of it.

Thanks a lot
Laura

Namespace Considerations:

This specification proposes URN namespace “alert” for global and
persistent names for the semantic of signals or renderings. The
particular rendering of an “alert” URN depends then of context in
which the rendering is done. Also the primary scope is the usage in
the SIP Alert-Info header, the new “alert” URN identifiers can be used
not only in IETF-protocols, but also for any telecommunication devices
or protocols (standardised by different organizations or proprietary)
and for use cases which are not connected to telecommunications. E.g.
when an intelligent video device at the house door recognises a family
member, it passes urn:alert:source:family to the doorbell which
renders a special tone, text, video, vibration or some rendering.

There do not appear to be other URN namespaces that serve the same
need of uniquely identifying the meaning of a rendering.
Unlike most other currently registered URN namespaces, the “alert” URN
does not identify documents and protocol objects (e.g., [RFC3044],
[RFC3120], [RFC3187], [RFC3188], [RFC4179], [RFC4195], [RFC4198], ),
types of telecommunications equipment [RFC4152], people or
organizations [RFC3043], objects [RFC3061], NewsML News Items
[RFC3085], public identifiers [RFC3151], Universally Unique
Identifiers for devices [RFC4122]. Also the “alert” URN is not
specific for an organization (e.g. IETF [RFC2648], OASIS  [RFC3121],
WEB3D [RFC3541], MPEG [RFC3614], MACE [RFC3613], FIPA [RFC3616], SWIFT
[RFC3615], Liberty Alliance [RFC3622], IPTC [RFC3937], ISAN [RFC4246],
NZL [RFC4350], OMA [RFC4358], IVIS [RFC4617], Aerospace and Defence
Industries Association of Europe [RFC4688], NFC-Forum [RFC4729],
ISO-documents [RFC5141], GEANT [RFC4926], SMTPE [RFC5119], CGI
[RFC5138], OGC [RFC5165],    EBU [RFC5174],  3GPP [RFC5279], DVB
Project [RFC5328], NENA [RFC6061], CableLabs [RFC6289], DGIWG
[RFC6288], SCHAC [RFC6338], Open Grid Forum [RFC6453]), specific
protocols (e.g. XMPP [RFC4854]), services [RFC5031], Electronic
Product Codes [RFC5134], objects and places (ucode [RFC6588]).

<<<<<<<

2012/5/3 Alfred HÎnes <[email-masked]>:
> Dale,
> at 26 April 2010, you wrote ...
>>> From: [email-masked]
>>>
>>> ...
>>  ...
>>
>>> a)  As soon as time avails, I'll take a closer look at the
>>>     (URN-specific parts of the) current I-D and provide feedback.
>>
>> That would be good.  We are in WGLC ending 8 May.
>
> I'm a bit late, but eventually I've been able now to start studying
> draft-ietf-salud-alert-info-urns-06.
>
> I copy Leslie Daigle (urn-nid IANA Expert).
>
> Before proceding and going into details, I'd like to raise my primary
> high-level concern and ask you to provide additional information.
> (As you know, folks say that someone doing so could be an indication
> that something's missing in the draft ...)
> Please beware that I don't have the time to follow your WG discussions
> and the primary focus of my review is the URN namespace registration
> that the I-D intends to perform.
>
> As it stands, the draft would most likely _not_ pass the urn-nid
> Expert Review process (which the PROTO writeup template makes clear
> needs to be undergone before the draft can be forwarded to the IESG),
> because mandatory sections (per RFC 3406) are missing.
> In particular, there are no Community Considerations and Namespace
> Considerations sections in the I-D.  The draft only contains short
> topical paragraphs with such headlines in the registration template;
> but RFC 3406 does not specify that -- it calls for solid Sections
> in the registration document.  The present paragraph for Community
> Considerations might do the job, but the Namespace Considerations
> are simply much too terse.
>
> Among the questions to be asked and responded to in such section
> would have been _which_ alternate namespaces have been considered and
> _why_ no other existing namespace would fulfill the needs/requirements.
>
> For instance, you want to let IANA manage the new URN namespace.
> But IANA already manages a specific URN namespace for IETF protocol
> parameters -- see RFC 2648 for URN:IETF and RFC 3553 for the
> sub-namespace URN:IETF:PARAMS .  Thus, it immediately came to my
> mind upon reading the initial sections of the I-D that, e.g.,
> urn:ietf:params:alert  might likely be a proper home for the
> intended usage.
> If the draft contained the aforementioned sections (per RFC 3406),
> it would have had to explain there why a new URN Namespace is needed
> and the alert information cannot be placed into a sub-namespace of
> URN:IETF:PARAMS (or maybe of URN:IETF, or any other potentially
> suitable existing namespace).
>
> Have such alternatives been considered?
>
> Note that, if you'd switch to using URN:IETF:PARAMS, you would avoid
> the urn-nid Expert Review process entirely and would not need the
> RFC 3406 template, but only the much more simple template per
> RFC 3553, Section 4, which IMHO would be very suitable in this case.
>
>
> If you can show me that such considerations have taken place and
> are documented, the arguments need to be put into the draft;
> otherwise, I think this topic would need to be brought to your WG.
>
> Please give me an indication so I can customize my review comments.
>
>
>
>>
>>> b)  Did you consider the ongoing work of URNbis?
>>
>> No, it started work well after Salud was going.
>
> Well, maybe looking into the rfc3406bis draft and the related
> discussion might have helped to better understand RFC 3406
> requirements for URN Namespace registration documents.   :-(
>
>>
>> Dale [chair of Salud]
>>
>
> Kind regards,
>  Alfred.
> [co-chair of URNbis]
>
> --
>
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
> +------------------------+--------------------------------------------+
>

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 29 Jun 2012 11:29:17 +0200 (MESZ)

Once more my apologies for the delay in responding ...

On Jun 5, 2012, Laura Liess wrote:

> discuss the issue in detail.   ...

Granted, of course!

>                       ... As you recommended, we went through the

If that's an argument, you somehow need to spell it out.
But beware that actually IANA Expert review processes
are intended to be performed before such things happen
(or at least the related discussion list contacted informally
before proceeding to non-experimental implementation[s]),
and some folks might not appreciate such perceived "coercion".

> This specification proposes URN namespace 'alert' for global and
> particular rendering of an 'alert' URN depends then of context in
> the SIP Alert-Info header, the new 'alert' URN identifiers can be used
> Unlike most other currently registered URN namespaces, the 'alert' URN
> Identifiers for devices [RFC4122]. Also the 'alert' URN is not

I don't thing you need to list all registered URN Namespaces here.
You should focus on the "obvious" candidates to hosting the salud
identifiers, and maybe refer to cases that you deem "similar" (in
some sense).  So the bulk of the second paragraph above is not needed.

I still haven't seen a striking argument spelled out against my
strong impression that  urn:ietf:params:  looks like a canonical
home for the 'salud' identifiers.  That's what you need most to
actually argue against, if you want to defeat the argument.
Do you think usage of urn:ietf in non-IETF protocols is not possible?
Why?  If so, please say so.  But then, why isn't "salud" (with "s" for
"SIP") regarded as offending to other SDOs as well?
In off-list conversation, you said short length of the identifiers is
regarded as very important.  Given the present verbosity of SIP, can
you quantify this argument?  (I thought there wouldn't be many 'salud'
identifiers per SIP message.)  How does that relate to the REQ-xx's
in the draft?

Again, I perhaps should emphasize that this is my personal point
of view.  Eventually, you will have to defend the aim of establishing
a new URN Namespace in the public IANA Expert review process on the
[email-masked]  mailing list, according to RFC 3406, before you can
request publication of your draft with your AD.

BTW:
Please use the precise terminology "SIP Alert-Info header *field*".
According to generic networking protocol layering parlance, each
protocol (sub-)layer can add a single "header" (and maybe a "trailer"
as well) to its payload(s).
Fields within such header are header fields, aren't they?
Nobody ever talks about such thing like the "IPv4 TTL header",
so why are HTTP and SIP folks so frequently using sloppy language?
SIP header fields (as Email and HTTP header fields) do not constitute
"headers"; most of these fields can appear in any order -- that is
a very strong indication of belonging to a single protocol layer
and hence not qualifying as distinct "header"s.
SIP is modelled after the Internet Message Format;
RFC 5322 (top of page 7) says:
!  A message consists of header fields (collectively called "the header
!  section of the message") followed, optionally, by a body.  The header
!  section is a sequence of lines of characters with special syntax as
!  defined in this specification.  The body is simply a sequence of
!  characters that follows the header section and is separated from the
!  header section by an empty line (i.e., a line with nothing preceding
!  the CRLF).
The MIME layering of the message body introduces one MIME header per
MIME body part, equally consisting of header fields (cf. RFC 2045).

Kind regards,
  Alfred.

--