Re: Review of IETF netann Draft

At 12:50 04/02/19 -0500, Eric Burger wrote:

>The IETF Internet Draft Basic Network Media Services with SIP, 
>http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-08.txt, 
>amongst other things establishes a URI convention for addressing named 
>resources at an automaton (in this case, a media server).
>
>Input is solicited on the use and applicability of a URI convention in the 
>sip: and sips: URI scheme.

Do you mean the convention to pick out some user names and use them
to denote something else than users?

In general, such conventions are considered a bad idea
(the less of it the better), but I don't understand enough
of SIP to assess this particular case.

In addition to the arguments you give in section 6, proliferation
should also be looked at. With postmaster@example.org, there is
only one such address used up, and everybody in the email community
knows this rather well.

Your draft already has three or four, and there might be more
in the future. People won't necessarily know what they all mean,
and may not suspect that they stand for something special.

One solution to this problem may be to change
     sip:annc@example.net....
to
     sip:special-annc@example.net
(choose whatever appropriate for the 'special' prefix).


Another issue I think is the use of URIs within URIs.
You use examples with quotes:
       sip:annc@ms2.example.net; \
           play="http://audio.example.net/allcircuitsbusy.g711"
and examples without quotes:
         sip:annc@ms.example.net; \
             play=file://fs.example.net/clips/my-intro.dvi; \
             content-type=video/mpeg%3bencode%d3314M-25/625-50

My general observation of practice in many different places is to
1) not use quotes or anything similar, and 2) to only escape
what needs to be escaped (although more escaping is often
done because implementations of escaping try not to be
context-dependent).


As an aside, the 'locale' production also has problems,
because it limits languages to those that have two-letter
codes (see RFC 3066).


Hope this helps,     Martin.

Received on Friday, 20 February 2004 18:09:15 UTC