Subject: [Ecrit] Review of draft-ietf-ecrit-service-urn-02

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 May 2006 00:12:54 +0200

Hi Henning,

I took a quick look at the draft-ietf-ecrit-service-urn-02 draft.
The document looks good!

I only have a few editorial comments.

* Abstract:
    The content of many communication services depend on the context,
                                               ^^^^^^^ depends

* Introduction
    opportunities (211 in some regions of the United States),telephone
                                                            ^^ blank

* Introduction

    We discuss alternative approaches, and why they are unsatisfactory,
    in Appendix A.

[hannes] reading throught the introduction you might want to say "We 
discuss alternative approaches for creating service identifiers...." 
since otherwise one might get the impression that you are talking about 
the previous section, i.e., about mapping protocols.

* Missing terminology section.

[hannes] You should add a terminology section here and point to the 
requirements draft.

* Formatting issue:

[hannes] If you put a <vspace blankLine="1"/> after each item when you 
make the text easier to read. If you put a <vspace blankLine="1"/> after 
the <t hangText=".."> then it even looks better.

This is also useful for Section 4.3.

* Section 2:

    Relevant ancillary documentation: None
    Community considerations: The service URN is believe to be relevant
                                                 ^^^^^^^ believed

* Section 2:

particular service in the user's current context, e.g., at his
                                                            ^^^
                                                            its

* Section 2:

   For example, a traveler will be able to use his
                                               ^^^^ its

* Section 2:

       the local emergency number.
           ^^^^^^^^^^^^^^^^^^^^^^
[hannes] If I recall it correctly then we use the term visited emergency 
dial string in this context.

* Section 4.3: sos Service Types

We have discussed the usage of the term 'sos Service Types' terminology. 
  It depends on Roger how to best align this document with the 
requirements draft.

As you recall from the location types draft we got asked where the 
definitions come from. Where do the definitions in this document come from?

* IDN

Since the identifiers used in this document might also presented to the 
user do we have to mention IDN considerations somewhere. I bet we will 
get such a question.

Maybe a short text could go into a 'Internationalization Considerations' 
section.

* Appendix A

You might want to restructure / reformat this section slightly to 
improve readability.

You can either put each alternative as a subsection or you use the <list 
style="hanging">
           <t hangText="..."><vspace blankLine="1"/>text

Before listing all approaches (starting with '"sos" SIP URI' to 'Special 
domain:') you might want to write something like:
"During the work on this document we considered a number of alternative 
approaches."

Ciao
Hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 May 2006 23:14:26 -0400

Hannes,

>   For example, a traveler will be able to use his

At least according to the style guides I have looked at, using "its"  
as the gender-neutral pronoun is frowned upon; if we want to be  
politically correct, it would have to be "he or she" or the plural.  
You can read http://en.wikipedia.org/wiki/Gender-neutral_pronoun for  
the finer points. I have rewritten the sentences to avoid gender bias.

> [hannes] If I recall it correctly then we use the term visited  
> emergency dial string in this context.

As a side note, the term is probably not particularly fortuitous.  
After all, we're not visiting the emergency dial string.

> We have discussed the usage of the term 'sos Service Types'  
> terminology.  It depends on Roger how to best align this document  
> with the requirements draft.

In keeping with the grammar of the URN, sos sub-services is probably  
most precise.

> definitions come from. Where do the definitions in this document  

Mostly made up, with some inspiration from Merriam-Webster and  
Wikipedia. If somebody has a more authoritative source, I'd  
appreciate if they could send a pointer.

>
> * IDN
>
> Since the identifiers used in this document might also presented to  
> the user do we have to mention IDN considerations somewhere. I bet  
> we will get such a question.
>
> Maybe a short text could go into a 'Internationalization  
> Considerations' section.

I'm not so sure about that; currently, the section reads

The service labels are protocol elements and not normally seen by
users.  Thus, the character set for these elements is restricted, as
described in <xref target="registration"/>.

I was hoping that LoST could provide a language-appropriate  
description if a listing of sub-services is supported.

> You might want to restructure / reformat this section slightly to  

Yes, that section is a cut-and-paste mess.

I've updated the document and will submit it shortly. See http:// 
www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service- 
urn-03.html for a preview version.

Henning